gasche a écrit 1151 commentaires

De toute évidence, c'est parce que tu as l'habitude de la programmation impérative, et pas l'habitude des autres styles. Cf. ce que je disais sur la différence entre lisible parce que "proche de ce qu'on connaît" ("facile"), et "conceptuellement simple" ("simple").

Si tu veux découvrir une nouvelle façon de programmer (ce qui est toujours une bonne façon de s'améliorer), je t'invite à faire l'effort de comprendre ces exemples (il suffit d'exécuter fib 3 ou fac 3 à la main, sur un papier brouillon, en dépliant les appels pour les remplacer par leur définition), tu en seras éclairé.

Si le fait de découvrir quelque chose de nouveau et d'intéressant ne te tente pas, c'est peut-être un signe de bassesse du front effectivement (malheureusement c'est le cas de beaucoup de programmeurs dans l'industrie, mais statistiquemenet pas des gens sur LinuxFR, d'où le "ou" qui va suivre) ou simplement que tu as d'autres priorités que la programmation et c'est tant mieux pour toi.

Ce que tu oublies dans cette belle histoire c'est que les GCs peuvent parfois être justifiés pour des raisons de performance. Concrètement entre un système à GC et un système à reference counting, les GCs (bien codés) sont plus performants en général pour les workflows où tu alloues pas mal, car les incrémentations/décrémentations du refcounting coûtent beaucoup. Donc une des raisons d'utiliser un GC plutôt que du refcounting (automatisé ou manuel) est d'avoir un meilleur throughput.

Alors oui, quand tu veux un GC sans pauses (ou une solution de gestion de mémoire sans pauses), tu utilises des algorithmes différents, qui font des compromis différents, et qui rendent les applications moins performantes globalement (qu'un GC qui s'autorise des pauses dans certains cas). Il faut choisir ce qu'on veut optimiser, et je comprends très bien que dans certains domaines applicatifs ce soit un meilleur compromis; typiquement tout ce qui est interface utilisateur, où la réactivité importe plus que la rapidité dans l'absolu.

Mais là tu veux le beurre et l'argent du beurre. Tu me dis "on ne peut pas avoir de pauses donc on fait du refcounting", et ensuite "on est vachement limité sur le temps de calcul donc on ne peut pas se permettre un GC". C'est beau d'être en symbiose avec une couche technologique comme tu l'es, mais il ne faut pas que ça te masque la réalité : tous les choix ont leurs avantages et inconvénients, et si de nombreux langages choisissent d'utiliser un GC plutôt que du refcounting, c'est parce que c'est une meilleure approche dans de nombreux cas; ARC n'est pas une technologie magique qui résoud tous les problèmes.

Pas besoin de la fonction intermédiaire..

Tant mieux, mais toi tu as besoin d'une variable mutable intermédiaire (donc d'un concept supplémentaire, l'assignation) et d'une boucle for (encore un concept supplémentaire). Pas clair que ta version soit "plus simple", et elle n'est certainement pas "beaucoup plus lisible" (même quand on sait qu'il faut 4 espaces devant chaque ligne pour représenter du code en Markdown).

Et puis j'aurais dû parler de Fibonacci

Pas de soucis:

fib n = fib' 0 1 n
fib' a b 0 = a
fib' a b n = fib' b (a + b) (n - 1)

Mais pas forcément aussi performant: il faut un compilateur assez compliqué je pense pour optimiser ça..

Oui et non. La complexité en temps est la même dans tous les cas (linéaire); dans un langage paresseux (si ta liste est construite à la demande), la complexité mémoire est la même. Après la question est de savoir si le compilateur sait optimiser la construction de liste; en pratique GHC sait le faire (donc produira du code équivalent si on le lui demande gentiment), mais je n'aime pas trop abuser de ces optimisations et je me contenterai de dire que c'est la version la plus "lisible", et donc intéressante à donner en premier si les performances ne sont pas critiques, du moment qu'elle a la bonne complexité.

fac n = fac' 1 n
fac' accu 0 = accu
fac' accu n = fac' (accu * n) (n - 1)

Je trouve ça lisible, personnellement. Tu as un code impératif équivalent "beaucoup plus lisible" sous la main ?

Par ailleurs, je remarque que let fac n = product [1..n] est aussi un code fonctionnel pur, et plus lisible que les deux versions que tu proposes.

Ton commentaire ne sert un peu à rien, il faut le dire (enfin je ne savais pas quoi répondre à part "euh... bof" donc pourquoi pas), mais il nous permet d'admirer ton nouvel avatar. Tu essaies de faire de l'effet ! Continue...

Personne n'a dit que c'était à toi (toi utilisateur ou toi développeur) de gérer ça. Mais la mémoire étant finie, il faut bien que les logiciels évitent d'en abuser. Le fait qu'un logiciel utilise un GC ou gère la mémoire à la main ne change rien : il y a une limite à la quantité de mémoire, fixée par le développeur et/ou un intégrateur de distribution et/ou l'utilisateur, et ultimement par la limite physique du système, et si le logiciel abuse, ça pose problème.

Mon commentaire avait pour seul but de dire qu'isoler des cas particuliers pour dire "dans ce cas là on n'a pas besoin de GC et on ne veut pas de pauses donc on évite le GC" n'est pas forcément pertinent quand ces cas particuliers (logiciel à courte durée d'exécution), justement, sont tout aussi bien gérés par le GC pour éviter les pauses.

Je suis sûr qu'il y a des cas spécifiques où on ne peut se permettre aucune forme d'allocation dynamique -- GC, ou malloc d'ailleurs -- par exemple dans certains systèmes embarqués temps-réel à fortes contraintes. Mais dans ce cas l'argument va plus loin que "le logiciel ne dure pas longtemps donc je n'ai pas besoin de libérer de la mémoire".

"lisible" est un qualificatif bien peu précis. On a souvent tendance à confondre ce qui est "facile", car proche de ce qu'on connaît déjà, et ce qui est véritablement "simple" conceptuellement. Je ne sais pas à quels exemples tu penses mais je doute que, pour un lecteur n'ayant aucune connaissance préalable, ni en impératif ni en fonctionnel, il y ait une différence si importante.
Après la popularité, c'est autre chose, et c'est compliqué.

Je préférerais une discussion avec plus de faits, d'exemples concrets, d'arguments objectifs, que des arguments du style "c'est moins populaire", "c'est plus lisible", etc.

Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème.

J'entends souvent cet argument mais il ne coïncide pas avec mon expérience personnelle de développement, soit dans des langages statiques soit dans des langages dynamiques. Dans un langage statique, le typeur repère très souvent des erreurs dans mon code, et dans un langage dynamique je passe parfois du temps à comprendre et corriger qui auraient été repérées par un système de types -- dernier exemple en date, manipuler dans RoR une donnée que je pensais correspondre à un modèle, mais dont certains champs n'avaient pas été chargés par une couche intermédiaire, et qui n'avait donc, moralement, pas le type attendu.

Il y a de temps en temps des expériences où on lance des outils d'analyse statique (~typage) sur des programmes écrits dans un langage dynamique (ou au système de typage faiblard, genre C), et on trouve pas mal de bugs. Dans le cas de Dialyzer que j'ai cité plus haut (pour Erlang), il y a par exemple cet article où les développeurs de l'outil l'ont lancé sur une codebase et trouvé plein d'erreurs subtiles, et de cas où les invariants mis dans les commentaires étaient devenu incorrects/périmés avec l'évolution du logiciel :
Gradual Typing of Erlang Programs: A Wrangler Experience (pdf), Konstantinos Sagonas et Daniel Luna, 2008.

Après je suis bien conscient que ça dépend des développeurs (par exemple Daniel J. Bernstein a des méthodes secrètes de ninja pour écrire du code juste à la première publication), et des domaines applicatifs (la remarque de BB ci-dessous sur le fait que le code numérique se prête moins au typage est très juste). Est-ce que tu as un lien vers un répertoire versionné d'un de tes logiciels écrits dans un langage non statiquement typé, qui permettrait de vérifier ton idée sur un projet réel. L'idée est de regarder les bugfixes et de voir dans quel cas un système de types plus puissant aurait repéré l'erreur; bien sûr ça ne rend pas compte des erreurs pendant la phase de développement entre deux commits, qui jouent pourtant un rôle important dans le temps total de programmation -- je pense qu'une erreur détectée tout de suite par le typeur est en général plus facile, ou en tout cas plus rapide, à corriger qu'une erreur détectée par un test qui échoue, ne serait-ce que parce qu'il indique précisément la position du problème, plus que même des tests unitaires.

• Une surcharge possible des opérateurs pour pouvoir utiliser +, -, *... sur des BigInt par exemple

Note que tu peux définir tes propres opérateurs infixes, et donc utiliser localement (+),(-),( * ) etc. sur des Bigint, ou alors (plus raisonnable) redéfinir (+.),(-.), etc. sur les bigint pour pouvoir toujours mélanger avec les entiers facilement.

La bibliothèque standard ne le fait pas (... pour l'instant en tout cas), mais tu peux te faire ta propre lib ou utiliser des bibliothèques (c'est fait, de façon imparfaite pour l'instant, dans Batteries par exemple).

Parce qu’au final se reposer sur un système de typage statique n’est pas viable non plus sur un gros projet, car bien souvent ce n’est pas d’un entier ou d’un flottant qu’on a besoin, mais d’un entier entre 1 et 3, d’un flottant positif, d’un vecteur normalisé, etc.

Un système de typage statique réaliste ne capturera pas tous les invariants de ton programme, mais ce n'est pas une raison pour les rejeter en bloc, s'il peut déjà capturer les invariants "faciles" et te laisser raisonner sans aide, ou vérifier dynamiquement, les autres, c'est déjà ça.

Du coup je préfère largement ne pas avoir à taper une liste de déclarations longue comme le bras

Manque d'inférence des types ?

La doc c'est bien joli mais comme ce n'est pas pris en compte par le langage, ça n'aide pas beaucoup pour repérer où est-ce que quelque chose a foiré. En pratique tu veux soit ajouter des outils d'analyse statique qui lisent cette doc et raisonnes statique sur ton programme (cf. Dialyzer pour Erlang), ce qui revient à avoir un système de typage, soit tu veux ajouter des tests/assertions dynamiques pour vérifier que ce qui se passe est cohérent avec ce que tu as documenté; et là sans aide du système tu te retrouves à nouveau à écrire des trucs longs comme le bras, la différence étant qu'ils ont un coût élevé à l'exécution.

Il me semble que la situation intermédiaire où le langage vérifie statiquement ce qu'il peut, et tu testes dynamiquement le reste (avec un bonus si tu peux spécifier ces deux aspects au même endroit) est préférable à ce que tu décris.

Je reste mitigé quant au mixe des deux approches, impératives et fonctionnelles, parce qu'elles sont disjointes ; ce sont deux modes de pensée différentes au delà des simples constructions. En fonctionnel, il est plus naturel de penser top-down et de ce que l'on veut faire (pas comment faire) et le résultat est la composition de fonctions qui décrit les relations déclaratives (et sémantiques) entre les fonctions d'un programme.

Je n'accroche pas à cette argumentation. De la façon dont tu le dis, on pense à deux espèces extra-terrestres qui essaient de communiquer sans avoir aucun socle cognitif commun. En pratique on peut très bien mélanger programmation fonctionnelle et impérative, par exemple en OCaml ou en Haskell, et c'est un style tout à fait raisonnable (pas plus complexe en tout cas que la programmation orientée objet avec des effets de bord).

Je n'accroche pas non plus à l'idée que la programmation fonctionnelle est "déclarative". Certains styles de programmation fonctionnelle, dans certains modes d'usages locaux, peuvent être appelés "déclaratifs", par exemple ce qui repose sur "code is data" (construire une structure de donnée et écrire une fonction d'évaluation pour lui donner un sens), mais c'est l'exception plutôt que la norme, ou alors tu as une vision très, très large de ce que signifie "déclaratif" qui ne veut plus dire grand chose.
Ce qui est vrai c'est que les programmes fonctionnels tendent à décrire leurs résultats comme la composition d'opérations (plutôt qu'un séquençage d'instructions), mais la vision opérationnelle de ce que l'ordinateur va calculer reste très présente (même dans les langages paresseux par défaut où elle continue à importer pour des raisons de performances). En fait dès que tu veux contrôler les performances du programme, il faut programmer ("dire comment") et plus seulement spécifier ("dire quoi").

Un cas d'école dans la désillusion de la programmation déclarative est Prolog: c'est un langage qui se veut déclaratif mais qui est en fait sans doute le plus opérationnel des langages que je connaisse: si tu n'as pas précisément conscience de comment le langage va évaluer ton code, tu es mort. Il paraît que d'autres langages logiques font mieux, et c'est bien, mais moi le langage de programmation généraliste déclaratif je n'y crois plus vraiment (comme aux idées selon laquelle l'optimisation serait du ressort du compilateur, jamais du programmeur). Déclaratif sur un domaine spécifique où on peut se le permettre (SQL.. les bons jours), ou pour faire de la preuve, d'accord, mais pour la programmation générale bof.

Dans ce cas précis, le code de la correction du TP en tout cas a une mauvaise complexité (insertion en temps linéaire par exemple), mais c'est sans doute fait exprès pour que les élèves y arrivent. Il ne serait pas très difficile de transformer ça en un code efficace, en utilisant de meilleures structures de données, sans changer la structure du code, et tu aurais quelque chose de raisonnable (même par rapport à un code en C; deux fois plus lent qu'un code C bien fait est une bonne cible).

Dans le monde mobile, les applis tournent tellement peu longtemps que le gc n'apporte rien du tout et va te tuer sur les pauses.

Tu peux, dans une certaine mesure, choisir où se trouvent les pauses. En OCaml par exemple tu as un GC générationnel, avec un tas mineur (petit et rapide à collecter, pas de problème de pause) et un tas majeur pour les vieux objets, plus gros, et collecté incrémentalement. Il n'y a une pause (tas majeur complet et compaction) que dans les situations critiques où il n'y plus assez de mémoire pour continuer à allouer. Le critère de "trop de mémoire" (ou trop de fragmentation) est configurable, tu peux dire "je veux une pause quand j'arrive aux 3/4 de ma mémoire occupée".

Si ton application ne tourne pas longtemps et n'est pas trop gourmande en mémoire, tu ne vas donc pas avoir de pause. Par contre si ton application est mal codée, même si elle dure peu de temps, elle va finir par manger trop de mémoire. Dans ce cas là, est-ce que tu préfères que cette application subisse une pause, ou que tout ton système se retrouve dans la merde à cause d'un manque de mémoire disponible (OOM killer, etc.)?

Bref, il me semble que dans le cas des applications à faible durée de vie, la présence d'un GC (bien conçu) ne change pas grand chose; soit elles sont raisonnables en mémoire et il n'y a pas de pause, soit elles ne le sont pas et tu as un problème de toute façon, la pause n'étant pas forcément la pire des solutions.

On me dit que "la recherche mondiale pourrait économiser 1.6 milliards d'euros par ans" en abandonnant Elsevier. La question que je me pose c'est : quelle différence cela ferait-il ? Pour ça j'ai besoin de comparer avec d'autres grandeurs sur l'argent dépensé par la recherche mondiale : le volume des salaires des chercheurs, le volume des billets pour aller aux conférences, n'importe quoi, mais qui soit homogène par rapport aux paiements mondiaux à Elsevier. Comparer les dépenses globales en édition avec les salaires individuels, ça ne m'aide pas.

Mon commentaire sur la différence entre salaire et coût total d'un labo, c'est que le salaire peut varier pas mal entre les pays, mais, en Europe en tout cas, reste relativement comparable entre les disciplines. Au contraire entre un labo de physique expérimentale et un labo de littérature classique tu vas avoir un rapport de 1 à 1000 (au hasard) sur les coûts de fonctionnement, donc si tu me dis "moi dans mon domaine les investissements mondiaux en matériel sont de ...", ça ne m'aide pas à comparer les dépenses en édition avec d'autres coûts dans un autre domaine .

Ça n'aide que partiellement : j'avais une bonne idée du salaire moyen des gens de la recherche (tu parles de la différence des coûts d'entretien/matériel selon les domaines, c'est justement pour ça que j'ai parlé des salaires), mais pas par contre du nombre de chercheurs.

Ça ne me semble pas être une interface modale comme Vim: dans une interface modale, le mode est un état global du logiciel qui conditionne la façon dont il interprète les entrées de l'utilisateur. Ici on lance une commande pour afficher la fenêtre du "HUD" et y taper une commande, comme un terminal drop-down ou une barre d'URL. On parle parfois d'interface "quasi-modale" dans ces contextes, mais je trouve que globalement ton analogie ne tient pas (par exemple les raccourcis claviers ne sont pas un mode à part).

Ce principe a déjà été expérimenté par de nombreux projets, les plus connu étant peut-être Enso de chez Humanized, et le projet Ubiquity qui a suivi chez Mozilla.

Ben non, justement, ça ne me permet pas de voir si la quantité d'argent est énorme parce que je n'ai rien pour comparer. 2 milliards pour la recherche mondiale, ce n'est peut-être pas tan que ça ? Ça fait combien par chercheur qui publie chez cet éditeur, par exemple ? Par rapport au salaire moyen des chercheurs ?

Mais à quoi penses-tu en particulier ? Je ne vois pas où quelqu'un a confondu les deux dans la présente discussion. Dans tous les cas je trouverais dommage de ne pas écouter quelqu'un seulement parce qu'il fait une erreur de la sorte, même des gens intéressants peuvent se tromper. Enfin bon si c'est ton dada, tant mieux, mais il me semble normal d'accepter que ça n'intéresse pas tout le monde (et je pense que quelqu'un qui n'est pas sur ça peut tout de même apporter quelque chose à Mozilla ou à toute organisation).

je suppose que la sémantique du C/C++ est tellement imprimé chez eux qu'ils n'envisagent même pas d'avoir un autre comportement..

Surprise, les développeurs de Rust ne sont pas les vieux beaufs que tu nous décris, ils ont en fait pensé au problème et regardé ce que la littérature de recherche dit à ce sujet, comme le montre la discussion mailing-list suivante que tu aurais pu trouver très facilement en faisant une recherche:
Patrick Walton: Integer overflow checking

Je n'ai pas spécialement d'avis sur Rust, ni en bien ni en mal (même si j'en attends plus que de Go), mais je suis un peu agacé par le mépris que l'on peut lire dans vos réponses. Rust n'a pas la maturité d'Ada, c'est clair, mais il s'intéresse aussi à d'autres points non traités par Ada, qui n'est d'ailleurs pas le seul langage pensé pour être sûr.

Je ne comprends pas ton commentaire dans ce contexte. Quel est le lien entre Rust, Internet et le web, et Firefox ?

Je trouve que tu vas un peu loin; Benoît Jacob fait un commentaire sur son domaine spécique, WebGL, qui est assez jeune et où les pratiques de sécurité sont naissances et les failles inattendues (franchement la timing attack sur les rendus de pixel, personne ne l'avait vue venir...). Il reconnaît bien volontiers ne pas être un expert (moi aussi d'ailleurs), mais tes propos peuvent quand même être blessants.

Je ne vois rien de "puérile" dans sa réaction et je ne pense pas que ça ait de sens de lui faire un procès d'intention en parlant de "réaction de Mozilla" alors qu'il s'agit de son avis personnel; il a un positionnement affectif vis-à-vis de son entreprise et réagit en prenant à cœur des critiques qu'il ne juge pas méritées, je pense qu'on peut comprendre ça sans tirer sur le messager.

Au contraire, je pense que son effort pour donner son ressenti de la situation est louable, et que c'est une bonne idée d'apporter ce genre de contenus à LinuxFR. C'est très bien qu'il y ait un débat, mais c'est encore mieux s'il se fait de façon détendue et qu'il motive les vocations d'autre gens voulant porter leur avis ici.

Sans sortir du sandbox, l'attaquant a deja acces a mes donnees privees sur les sites ou j'ai une session ouverte, genre compte en banque et email, c'est deja assez enorme pour que je ne voie pas comment ca pourrait etre pire.

Encore une fois, non, ça ne doit pas être possible et, si c'est le cas, ça veut dire que la granularité de la compartementalisation n'est pas assez fine. Si j'ai deux onglets ouverts, l'un sur le site de ma banque et l'autre sur un site louche, je veux avoir la garantie qu'une exécution de code arbitraire (ou lecture/écriture arbitraire en mémoire) sur la partie qui traite le site louche ne puisse pas avoir accès à mes données bancaires. C'est une garantie possible dans l'absolu, mais cela demande une architecture bien pensée du côté du navigateur -- et un système hôte efficace pour que les coûts ne soient pas trop élevés.

C'est la magie des notes, il ne faut pas y faire trop attention. En tout cas je n'ai pas mal pris ton commentaire du tout.

(J'en profite pour placer un commentaire que j'aurais pu mettre ailleurs.)

Tu parles de la "randomization" des adresses mémoires (ASLR) pour empêcher l'exploitation des buffer overflow, mais je voulais insister sur le fait que c'est une technique défensive qui ne se fait pas au même niveau que le sandboxing. La logique de l'ASLR c'est "j'ai un bug, comment rendre difficile de l'exploiter comme une faille de sécurité". Si tout se passe bien le bug n'est pas exploitable, et dans les mauvais cas (ou si l'attaquant est trop malin, genre toboggan et compagnie) on a une exécution de code arbitraire. C'est donc une protection du style "tomber dans le pire cas moins souvent". Au contraire le sandboxing consiste à réduire au maximum les privilèges du processus, de façon à ce qu'en cas d'exploitant (indépendamment de la fréquence de tels événements) les conséquences néfastes soient limitées : c'est une protection du style "faire que le pire cas soit moins grave". Donc pour moi les deux sont complémentaires, mais je pense que la compartementalisation est une technique plus fondamentale et plus efficace, qui devrait être une brique de base de tout système bien conçu, alors que l'ASLR est plutôt un détail d'implémentation efficace en pratique mais ne donnant aucune garantie réelle dans l'absolu.

il y a des gens qui bossent a temps plein avec des outils d'analyse statique pour decouvrir ces bugs dans Firefox (et dans tous les autres navigateurs). Certains payes par Mozilla, certains non. Et il y a aussi des gens qui en font autant avec des fuzzers. La encore, certains sont payes par Mozilla, d'autres non.

J'étais déjà au courant pour l'analyse statique par exemple, mais j'ai souvent l'impression que ce sont des efforts qui restent très internes, et on n'en entend pas beaucoup parler. Qu'est-ce que les gens de Mozilla ont publié comme résultats concrets, réutilisables par l'extérieur, de leur travail sur ces outils ?

C'est très intéressant, et c'est précisément ça que tu devrais répondre, à mon avis, aux arguments que tu trouves "marketing". Des points techniques concrets sur les méthodes de sécurité employées sur Mozilla et leur impact sur l'industrie en général. Par exemple, j'invente : "voilà, on a expérimenté les outils de Clang d'analyse statique pour notre refcounting, et voilà ce qu'on a pu faire et ce qu'on propose aux gens qui voudraient faire pareil".

Je suis bien conscient que ton domaine spécifique, WebGL, est une plaie parce que vous vous prenez dans les dents tous les défauts des couches graphiques et du manque d'isolation à ce niveau là, sur lesquels vous n'avez quasiment aucun contrôle. C'est un autre vrai argument de fond.