Enjolras a écrit 295 commentaires

Ah ouai, c'est sûr que pacman -S ne permet pas de sélectionner les paquet de manière fine et pratique…

Euh, bof. Télécharger le dépôt [core] et le copier sur une clé usb, je suis pas sûr que ça soit plus long que télécharger une iso core…

Ça ne pose aucun problème, puisqu'il n'y a pas de perte de fonctionnalités.

Vas dire ça à ton product manager :>

Bah, oui, les fonctions récursives en python sont lentes. Donc ce code est lent. C'est pas la peine de faire un discours général sur le fait que python est pas lent…

Là tu racontes des choses qui n'ont rien à voir. On ne parle pas de rendu graphique ou de bibliothèque, on parle de l'exemple, qui n'en utilise pas.
je sais bien qu'ils y a d'autres implémentations de pythons, mais, il n'empêche que le code en lui même n'est même pas récursif terminal. On peut toujours espérer que le compilateur le fera, mais c'est pas garanti, même avec Cython.

Sans compter que dépendre d'une implémentation pour le fonctionnement du programme, c'est pas bien :>.

Donc au final, tu es en train de me dire que python est un bon langage en réponse à ma remarque sur le fait que l'exemple est un mauvais code. Je n'ai jamais dit le contraire. Tu appris mon "les fonctions récursives en python sont lentes" par un "python est lent", tu extrapoles un peu je trouve.

Tu sais je suis entièrement d'accord avec toi. J'ai juste dit que les gens le trouvaient lourds. J'y suis pour rien…

Si tu es motivé pour maintenir un framework en bash, et si la notion même de framework en bash ne te fait pas vomir, vas y.

Quand plus personne ne veut développer un programme, il ne se développe pas tout seul. Les développeurs ne sont pas au service des utilisateurs. Ils font ça parce que ça leur plait. Quand ça leur plait plus, ils arrêtent. C'est si compliqué de comprendre ça ?

Il y a une différence entre "optimisation qui fait gagner 1%" et "optimisation qui permet de renvoyer un résultat". La fonction n'est pas Récursive terminale, et de toute manière, python n'optimise pas les appels récursifs terminaux.

J'admets que la factorielle est pas un bon exemple, à cause d'int overflow, mais mettons que ça soit des big int ou que tu veuilles la factorielle modulo MAX_INT.

Ce code ne fonctionnera pas pour n assez grand. Stack overflow. Moi j'appelle pas ça une optimisation, mais du debug.

En quoi ça un rapport avec la lisibilité ? Bah un code lisible qui ne marche pas, je n'en vois pas trop l'intérêt.

Parce que… Ca existe déjà ?

Tu prends un exemple queje trouve tout aussi abhérant : firefox. Pour moi, il ne devrait pas y avoir de gestionnaire d'extension à firefox. Firefox, c'est un navigateur, pas un gestionnaire de paquet. L'idéal serait un gestionnaire d'extension global, qui gére les modules firefox, mais aussi gnome-shell, ou les plugins nautilus, ou les plugins vim, etc etc.

Pour moi, le gestionnaire de news et le gestionnaire de paquet doivent être séparés. Donc autant laisser les gensfaire leur propres wrapper s'ils veulent avoir les deux grouper. D'ailleurs, ça existe. Personne n'a pris le temps d'en faire un réellement reconnu et chacun fait ça à sa sauce, c'est peut être un défaut. L'avantage, aussi c'est qu'on est pas dépendant d'une technologie. Si quelqu'un a l'idée de puscher les news via XMPP pubsub (qui serait pas une mauvaise idée d'ailleurs), c'est trés simple à mettre en œuvre, car la gestion de news est externe : il suffit de changer d'outil, et les quelques lignes du wrapper.

D'ailleurs, c'est le fonctionnement de pacman, qui par exemple utilise un outil externe pour télécharger les paquets.

POur ce qui est de "j'ai pas fait de maj depuis longtemps", sur arch, ça n'a pas trop de sens, à moins que tu l'utilises en mode déconnecté. Parce qu'il n'y a pas de maj de sécurité, il n'y a que des majs majeures, et je ne sais pas si tu aimes utiliser des trucs vieux de 6 moins sans les backports de stabilité/sécurité, mais mois non. En régle générale, je trouve qu'au moins 2 majs par mois c'est largement raisonnable. Voire plus.

Donc, la gestion des news n'est pas lourde. D'ailleurs, si tu regardes l'historique, elles ne touchent que des paquets de base, comme filesystem, glibc, pacman, etc. On n'est pas floodé par les infos.

POur résumer, on a des lecteurs RSS, qui gérent les news, et qui tentent de le faire bien. On a Pacman qui gére les paquets, et qui tente de le faire bien. En aggrégant les deux, on a un systéme flexible, facilement maintenanble, et qui fait les choses bien.

Trop bien, une fonction récursive en python ! T'as pas plus lent ?

Une fonction shell pacmanews, qui rafraichis ton flux RSS, affiche les nouveaux messages, et appelle pacman avec les arguments que tu as passé ça suffit pas ?

Bien sûr que si. Maintenant, si tu veux un gestionnaire de paquet qui fait tout pour toin bah, tu utilises pas pacman, on est d'accord. Mais, dans le bug tracker, le dépôt, et les ML, les devs répètent sans cesse que pacman ne gère pas tout. Si une fonction est complexe à implémenter et qu'elle n'est utile que dans 10% des cas, alors, elle n'est pas implémenté en priorité.

Après, on peut être en désaccord avec le principe. Mais dans ce cas, ce n'est plus de pacman dont on parle.

C'est sûr que pour une news par mois, tu as besoin que ton lecteur filtre les informations pertinentes pour toi. Tu ne peux pas le faire toi, il faut ajouter 300 lignes de codes pour le faire.

Faudrait un jour comprendre que Arch n'as pas le même but que ubuntu ou debian, ou gentoo. Et que si Arch se mettait à faire pareil, alors, pouquoi avoir plusieurs projets ?

Parce qu'il y a déjà des lecteurs de flux RSS qui font ça mieux qu'un gestionnaire de paquet ?
Et parce qu'un gestionnaire de paquet n'est pas un lecteur de flux RSS.

Demande à Mozilla.
J'imagine que c'est historique, et qu'ils ont pas envie d'introduire des nouvelles dépendances sans vraie raison.

D'ailleurs, tu noteras que j'ai fait la même supposition pour le code ocaml. Si tu l'appelles avec 0, tu pars en récursivité infinie.

Et les versions de spider-mario demandent n > 1 si je ne m'abuse.

Oui en effet, j'avais imaginé qu'on devait pas calculer factoriel de 0, mais bon sémantiquement c'est autorisé, ça fait 1.

Pour les versions de perl6/haskell je dis juste que c'est pas une bonne manière de comparer la lisibilité de la syntaxe, parce que ça utilise des fonctions de lib standards. Après, on peut arguer du fait que la lib standard joue dans la lisibilité… Mais ton argument sur les bugs évités n'a pas de sens.

Bien sûr qu'utiliser une fonction testée de la lib standard est plus safe… Mais ça n'augmente pas la lisibilité de la syntaxe.

tu risque de faire rapidement un stackoverflow. Enfin, tu n'as pas tout à fait tort dans ce cas, parce que dans le cas de la factorielle, la profondeur d'appel est pas énorme, on tombe d'abord sur un int overflow, du coup le fait d'être récursif terminal n'est pas forcément primordial.

J'ai oublié de parler de LWT.

Lwt peut répondre à beaucoup de problématiques en effet, mais ce qu'il ne faut pas oublier, c'est que le navigateur veut tirer partie de tout les cœurs. La tendance actuelle des choses est de tout mettre dans des threads, la compilation JavaScript, la composition, le rendu, la compression/décompression des images et des sources,… Force est de constater que ça améliore les performance. Maintenant, la question qui se pose est "est ce que des coroutines ne suffiraient pas ?". Vu que C++ n'en a pas, personne n'a testé. (Non, boost n'est pas une option)

Le multi process n'est pas magique non plus. Ca veut juste dire que tu laisses faire le message passing à l'OS via les IPC. Et comme chaque OS a différents IPC c'est pas si simple. Dans l'état actuel des choses, ça alourdit considérablement.

LLVM n'est pas magique, mais il évite de coder le lowering. Ce qui et pas mal d'optimisations comme le LICM, etc. Il fournit quand même beaucoup d'outils qui facilitent grandement l'écriture du compilateur, la grande majorité du travail ayant lieu sur le frontend.

Il assure bien, et même si on veut bien donner une quelconque crédibilité aux benchs, on peut prétendre que c'est le meilleur.

Il n'empêche que les gens le trouvent toujours lourd.

Il n'y a pas besoin d'être expert en compilateur pour écrire un compilateur en 2012. Il y a des outils performant qui fournissent des backends déjà fait, il suffit d'écrire le frontend, ce qui revient souvent à définir la sémantique du langage. Exemple d'outil : LLVM.

De plus, dire que Mozilla n'a pas d'expert en navigateurs, c'est un peu exagéré, parce qu'ils ont écrit déjà au moins 3 compilateurs javascripts, dont le dernier, ionMonkey, est un vrai navigateur avec frontend/backend et MIR/LIR.

En outre, Rust ne se compare avec aucun langage sus-cité, parce qu'il emprunte un peu de chaque. Et c'est l'idée. Avoir un langage avec des contraintes de types fortes, des pointeurs avec une sémantique forte, qui permet plusieurs paradigmes de programmation, tout en n'affectant pas les performances, et permettant une sorte de cargo programming pour que les gens qui n'ont jamais fait que du C ne tombent pas sur Haskell et ne rehjettent le langage.

Donc :
- haskell ? → performances non prédictibles, trop complexe pour la conversion de la code-base
- ocaml ? → ocaml utilise un GC avec biglock, et ne permet pas de gérér la mémoire, je vois mal comment on peut écrire un GC javscript en Ocaml ni même un navigateur multithreadé.
- C/C++ → pas assez de contraintes sur les types et les pointeurs, C++11 fournit vaguement des routines légéres, mais, ça existait pas au début de rust.
- scala → JVM. Je ne pense pas que Mozilla veuille dépendre techniquement de la JVM, a fortiori pour des raisons philosophie. Puis, la JVM est connue pour consommer de la mémoire, Déjà que les gens trouvent firefox lourd…

Parce que la fondation Mozilla est assez intelligente pour préparer l'avenir… On critique souvent à Mozilla de ne pas innover, c'est faux.

Ils ont bien compris que les nouveaux navigateurs devaient être hautement paralèles, et qu'il ya de grosses problèmatiques de gestion de la mémoire et du passage de mémoire. Actuellement, ils utilisent des threads et XPCOM pour passer des messages. Ce n'est pas satisfaisant. Rust est un projet d'avenir à long terme, qui ne mobilise pas énormément de ressources, et il est couplé avec un prototype de moteur.

Il faut voir ça comme le département Recherche/Innovation de Mozilla. Ça n'a pas d'intérêt dans les mois qui viennent, mais ça pourrait s'avérer crucial dans 7 ou 8 ans.

Ouai, la tu compares surtout les lib standards. Tout le monde sait que Haskell sait tout faire, mais product, c'est déjà factorielle.