anaseto a écrit 2229 commentaires

Merci de ne pas falsifier mes propos.

Désolé, ce n'était pas mon intention. Je voulais juste dire que c'est facile d'en venir à être trop optimiste avec le libre quand on voit que ça peut marcher (je suis le premier à trouver cela génial et d'apprécier les tentatives dans ce sens), mais que le fait que ça puisse marcher avec le logiciel n'implique pas que ce soit possible avec tous les arts, a priori (peut-être qu'il existe des arts pour lesquels il y a des problèmes techniques insurmontables pour que ça marche aussi bien qu'avec le logiciel).

Je suis très d'accord que c'est rarement facile, et pour ceux qui réussissent, visiblement comme Zenitram, c'est facile de croire que leur cas se généralise sans problèmes. Par contre, suivant l'art en question, des fois libre ou pas libre, ça n'influe pas forcément sur la difficulté (mais j'imagine bien que des fois ce doit être le cas, bien sûr).

Eh bien, je ne sais pas quelles sont les raisons de Nokto pour avoir choisi ce moteur de forum :)

Ceci dit, personnellement je ne suis pas convaincu que le « flat design » des deux exemples que tu donnes soit adapté dans ce cas. En gros, j'ai l'impression que c'est plus utile si les fils de discussion sont de courte durée, puis s'oublient au bout de quelques jours/semaines, alors qu'avec un forum classique, des fils vieux de plusieurs années continuent souvent à être utilisés. Et puis, plus subjectivement : j'aime bien quand un site marche au moins à 90% sans activer javascript.

Ailleurs que sur quelques forums.

Et bien je te conseille de (re)lire ce message de Nokto, et tu verras que les usages peuvent être largement plus variés si on veut.

Ceci dit, chacun en fait l'usage qu'il veut : personnellement, je n'aime pas beaucoup voyager, donc je l'utilise effectivement surtout pour lire sur des forums ou autre, mais aussi pour rencontrer des espérantistes locaux et/ou venus d'ailleurs. Plus des raisons plus subjectives comme le fait que l'idée de l'espéranto me plaît, tout comme la langue en soi, que je trouve très agréable et facile à utiliser (par exemple, j'ai fait de la traduction de roman vers de l'espéranto, mais je ne me lancerais pas dans de la traduction vers l'anglais [ni le français probablement], car je sais que je ne manierai jamais ces deux langues suffisamment bien à moins de m'y consacrer professionnellement pendant des années).

Par contre, c'est loin d'être utilisable n'importe ou autant que l'anglais.

Personne n'a dit le contraire, mais beaucoup d'autres outils ne sont pas utilisables « n'importe où » et sont pourtant très utiles quand la bonne occasion se présente (ce qui dépend beaucoup de la vie de chacun). C'est comme pour les langages de programmation : ce n'est pas parce qu'un langage n'est pas populaire au point que personne ne fait l'impasse dessus qu'il ne va pas être utile en pratique pour un certain public.

C'est quoi la vraie vie ?

(je sais, ça a l'air philosophique comme question, mais je me pose sincèrement la question)

Lire "Espéranto" et "succès" dans le même paragraphe, ça fait quand même bizarre.

Comme tu le dis, c'est relatif. Ça reste un succès si on le compare à d'autres langues planifiées, et si on considère le peu d'approbation qu'il a eu de la part des dirigeants et même une opposition claire (poursuites pendant la deuxième guerre mondiale, poursuites staliniennes, des gens comme De Gaulle qui s'en moquaient ouvertement [ce qui au passage montre qu'à l'époque au moins ils savaient que ça existait], etc.). Pendant la guerre civile espagnole, beaucoup d'échanges se faisaient en espéranto. C'est même surprenant qu'il ait plutôt bien survécu, malgré un massacre assez important de ses locuteurs à une époque.

les cultures je les rencontre plus en parlant Anglais qu'Espéranto pour le moment

Étant donné que visiblement tu ne parles pas l'espéranto, le contraire serait pour le moins étonnant :)

Blague à part, c'est très relatif : en anglais j'ai tendance à parler uniquement avec un public très lié à mon domaine, et je tombe en tous cas rarement sur des conversations dédiées à échanger sur sa culture. Ce qui se passe avec l'espéranto, c'est que les personnes qui le parlent sont souvent justement contentes de partager leur culture dans cette langue neutre, donc c'est un bon public pour ce genre de découvertes.

L'espéranto n'utilise pas exactement l'alphabet latin (il y a quelques lettres nouvelles: ĉ, ŝ, ĥ, ĝ, ĵ, ŭ), mais ne vise pas non plus à être « universel » de ce point de vue là (je ne suis même pas sûr de quel sens on peut donner à ça précisément). L'espéranto est une langue relativement pragmatique, avec juste la diversité niveau vocabulaire qu'il faut pour que tout le monde soit conscient qu'il s'agit d'une langue internationale, mais c'est sa grammaire et sa façon de générer du nouveau lexique à partir de suffixes et/ou d'autres mots qui font sa force (tout comme une garantie de bonne rétro-compatibilité et sens pratique qui a plutôt bien marché, et l'a distingué d'autres langues planifiées).

A-t-elle des prononciations différentes selon la langue maternelle du locuteur ou y a-t-il une prononciation officielle ?

Suivant les locuteurs, il y a des petites variations. Par exemple, le « r » est censé être prononcé plus à l'italienne, mais les français le prononcent d'habitude comme un « r » français. En pratique, ce n'est pas un problème du moment qu'il n'y a pas d'ambiguités, et comme la prononciation de l'espéranto est relativement simple, surtout au niveau des voyelles, ça n'arrive pas trop.

La section francophone de lernu me semble plus dédiée à de la discussion purement en français pour se renseigner sur l'espéranto (même s'il y a aussi parfois des messages en espéranto), et ne comporte pas de sections thématiques (toutes les entrées sont les unes à la suite des autres), donc le panorama d'usages est potentiellement plus limité, je dirais.

Je n'en suis pas si sûr. En tous cas, il manque au moins ceux qui n'en ont rien à faire du développement durable et de la paix dans le monde, qui en sont bien conscients et qui ne le cachent même pas :)

Mais à la fin, c'est quoi un "petit-bourgeois-beauf" ?

Allez, j'aime bien les petits jeux, je me lance pour une définition :)

Définition : un petit bourgeois beauf est une personne qui, suite aux hasards de la vie, mène une existence au-dessus de la moyenne, incompatible avec le développement durable et la paix dans le monde, dont il est parfois en même temps un ardent défenseur. Au fond, il a quand même un peu conscience que tout ne colle pas, mais ne veut pas le savoir, car il le vaut bien.

Pareil, c'est mon journal qui dénonce grave préféré depuis des années, je crois, digne des meilleures diatribes critiques sur burbuja.info :) + 1000 je dirais. Bon, dommage qu'ayant désactivé le css des notes je peux même pas faire +1, mais c'est l'intention qui compte. Mais bravo pour cet excellent travail. Au passage, ça fait un bon résumé des journaux critiqués, dont j'avais lu juste un 1% en diagonale, et visiblement j'avais raté de jolies perles.

Ce n'est pas évident. Il n'y a pas eu de grand projet nucléaire en France entre les années 80 et l'EPR, à ma connaissance. L'EPR est une tête de série. Si on continue, les exemplaires suivants devraient poser largement moins de problème (et donc coûter moins cher à construire).

Peut-être bien, ou peut-être pas, on verra. Mais ce dont je doute, c'est qu'ils réussissent à vendre ça facilement en dehors de la France (en dehors éventuellement de futurs projets fiasco avec des magouilles locales dans d'autres pays). Et je doute même qu'ils en mettent plein en France, parce que ça restera des gros projets dans tous les cas, auxquels s'ajoutent les pressions extérieures de pays pas trop favorables, et d'autres conflits d'intérêt locaux aussi : ça fait pas mal d'obstacles.

Il faut savoir que la majorité de la population française n'est nullement opposée à l'électricité nucléaire.

Ah, mais tout à fait. Mais je ne pense pas que ce que pense la population française va influer sur le reste du monde. D'ailleurs, le contraire me semblerait plus probable : c'est-à-dire que des intérêts étrangers réussissent à changer les avis en France à coup de propagande insidieuse (mais c'est pas gagné pour eux non plus, car les intérêts locaux sont importants aussi, et ont déjà une longueur d'avance). Mais tout ceci est assez accessoire, ce que nous pensons les populations sur ce genre de sujets techniques/économiques a rarement de l'importance en pratique.

Des propositions ?

Ce n'était pas le but de mon message. J'ai juste fait part de mon impression sur l'avenir du marché du nucléaire suite à ce que j'ai pu en observer dernièrement, mais elle peut être erronée. Ça m'a semblé plus intéressant que de donner mon opinion sur si c'est bien ou mal le nucléaire (pas mal de monde se démène déjà sur cet angle du sujet, auquel je n'ai rien de nouveau à apporter).

Faut quand même comparer avec le reste du monde et là, force est de constater qu’en France la situation est meilleure que dans bien d’autres endroits.

D'un point de vue légal et de censure directe, je ne sais pas trop. Il y a bien un certain nombre de propos illégaux, je ne connais pas trop les détails, je n'ai pas le temps de lire les lois, alors j'évite juste au flair avec ma connaissance de la culture française quand je parle politique (ce qui arrive de moins en moins souvent). Dans d'autres pays je suppose que ça doit ressembler (en Espagne on ne peut pas dire du mal du roi en théorie, par exemple). Ceci dit, hors des détails législatifs, un phénomène que j'ai remarqué dans les conversations que je vois entre français par rapport aux conversations que je vois entre espagnols, c'est, qu'avec ces derniers, hormis si on touche au thème de la guerre civile (et encore), c'est beaucoup moins souvent que des propos débouchent sur des ambiances défensives ou condescendantes (d'un côté comme de l'autre), et c'est souvent plus chaotique (il y a bien des gens qui s'engueulent n'importe comment, mais les gens se prennent moins au sérieux en moyenne, et on a moins souvent l'impression qu'il y a deux camps).

En 2016, l'électricité d'origine nucléaire représente 80% de l'électricité produite en France mais tout peut changer, ce n'est qu'une question de volonté politique:

Mon flair me dit que le nucléaire n'a plus d'avenir depuis un certain temps déjà (la dette d'Areva qu'avale EDF sort pas de nulle part). À part quelques projets qui finiront probablement en fiasco jamais rentabilisé, tout semble tendre au gel dans ce secteur, qui ne semble pas attirer des masses dans le monde en dehors de ceux qui font des bénéfices avec leur construction, et qui s'accrochent comme ils peuvent à leur trésor. Ceci dit, les centrales qui existent vont pas disparaître en trois jours, donc elles feront partie de notre avenir en un certain sens quand même, ne serait-ce que par le travail que va demander leur démantèlement.

un programme Coq qui compile est garanti sans bug

Encore faut-il que les propriétés écrites qui sont prouvées soient les bonnes :) Donc dans le cas d'un compilo, principalement que la sémantique du langage initial soit écrite correctement (les rares bugs trouvés l'ont été à ce niveau pour CompCert). Ceci dit, un programme Coq qui compile, même sans preuves, apporte au moins la terminaison.

comme le compilateur CompCert (le seul à ma connaissance)

Le seul (que je sache) qui ait une chaîne complète (à quelques petits bouts près au début et à la fin), oui. Sinon il y a aussi eu quelques efforts pour formaliser l'IR de LLVM et quelques optims, par exemple.

Par exemple le compilateur actuel remplace systématiquement les appels à ma fonction iff par if b then e1 else e2 (comme si c'était une macro en Common Lisp)

Je n'ai pas testé encore flambda, mais sauf surprise il inline juste la fonction, mais sans changer la sémantique d'évaluation, ce qui veut dire que les arguments sont évalués avant. Par exemple : let () = iff true (print_int 4) (print_int 2) va afficher 42. Le if fait à partir de cond en Common Lisp sera lui un vrai if (même si comme l'a remarqué ylsul en vrai c'est l'inverse, et if n'est pas une vraie macro, plutôt une macro built-in on pourrait dire).

le pattern matching qui est une version généralisée de ta macro cond

Mais en Lisp tu peux, uniquement à l'aide de macros, définir un pattern matching à la OCaml (il y a plusieurs packages qui font ça dans différents dialectes). En fait, c'est même possible de créer un système de types statique uniquement à l'aide de macros (comme c'est fait dans une extension de Racket). Ou créer un langage de documentation comme scribble pour Racket, qui est en fait un programme Racket valide (pas un langage spécial à part avec des commentaires ou quelque chose comme ça, je trouve ça plutôt sympa). Bref, les possibilités offertes par les macros Lisp sont assez difficiles à égaler, et OCaml va difficilement gagner sur ce terrain. Après, c'est loin d'être un critère ultime, la plupart des cas où les macros permettent une solution élégante ont des alternatives tout à fait acceptables, parfois intégrées au langage de façon ad hoc ou à l'aide d'un outil externe (souvent plus léger).

(dans ce cas l'évaluation est-elle paresseuse, i.e évalué une seule fois à la première utilisation du terme, ou recalculer à chaque usage du terme ?)

Une occurrence d'une macro est développée une seule fois à la compilation (donc en particulier si elle apparaît à l'intérieur d'une fonction ou d'une boucle, son expansion n'est calculée qu'une seule fois).

Cela étant en Comme Lisp if est une macro ou une fonction ?

Une macro (en Common Lisp les fonctions sont évaluées strictement comme en OCaml).

Et soit dit en passant, écrire f∘g∘h a b reproduit relativement explicitement un « AST »…

La différence c'est qu'en OCaml tu ne peux pas écrire une fonction qui prend une telle expression quotée en argument et la manipule comme un « AST », c'est à dire, avant d'évaluer quoi que ce soit, fait des trucs avec f, g et h, et au final calcule hogof ou n'importe quoi d'autre. Il faut aller chercher les ppx et l'AST pour ce genre de choses (et encore, je ne connais pas trop les limitations), voire définir soi-même une sorte d'AST avec des types (mais qui ne serait pas l'AST OCaml) pour représenter ce genre d'objets.

Pour ce qui est de "défigurer" la syntaxe : en Lisp c'est facile, il n'y a "pas de syntaxe", juste les AST. C'est-à-dire qu'il n'y a rien à défigurer.

Je suis d'accord que « défigurer » n'est pas du tout l'image qui correspond, et qu'au contraire, les extensions au langage en Lisp sont naturelles (peut-être même trop pour l'œil humain). Ceci dit, par contre, j'appelle syntaxe tout élément dont l'évaluation n'est pas prévisible, et les macros en font partie (contrairement aux fonctions dont la logique d'évaluation est connue). Le fait que l'apparence soit homogène en Lisp est utile pour faire des macros de façon intuitive et naturelle, mais ne change rien au fait que chaque macros apporte de la syntaxe. On peut avoir une syntaxe très folklorique (genre Perl), et pourtant que la syntaxe en soi ne soit pas très complexe (c'est plus le lexeur qui est compliqué), comme avoir une syntaxe plus homogène mais plus complexe. Et d'ailleurs, si pas au niveau de Lisp encore, OCaml n'a pas une syntaxe particulièrement simple non plus, il y a pas mal de choses dans ce langage, et de plus en plus. Et autant cela peut apporter du pouvoir d'expression et plein de trucs utiles, autant ça rend le langage moins accessible aussi (et pas qu'aux débutants, je pense).

Dans un langage comme Java ça ne marche pas parce que les expressions e1 et e2 seraient évaluées systématiquement avant d'être passées en paramètre à la fonction iff.

C'est le cas aussi en OCaml, c'est un langage strict, contrairement à Haskell qui est paresseux, par exemple. Le iff est ici juste une fonction. En OCaml la seule façon d'étendre la syntaxe et de contrôler l'évaluation, et créer une nouvelle structure de contrôle, est d'utiliser camlp4/5 ou maintenant les ppx. Je suppose qu'avec la directive lazy pour évaluer paresseusement on pourrait faire un iff à peu près raisonnable, mais pas totalement naturel à utiliser.

OCaml, du fait de son typage statique poussé et des garanties qui vont avec se heurte à pas mal de difficultés pour faire du méta-programming. Utiliser les ppx c'est clairement moins facile pour un programmeur OCaml lambda (perso, il me faudrait potasser l'AST un moment) que faire une macro en Common Lisp (tout programmeur connait l'AST). Quels que soient les progrès, faire du méta-programming ne sera probablement jamais aussi facile qu'en Lisp.

L'approche c'est plutôt : le méta-programming n'est pas quelque chose dont a vraiment besoin un programmeur quotidiennement, donc on se contente d'une approche moins accessible et plus limitée, mais compatible avec le système de types pointu d'OCaml. Du coup, on ne fait pas une extension dès qu'une petite factorisation potentielle se présente. Par exemple, des fois avec un match sur un type somme avec beaucoup de cas, on s'aperçoit qu'on fait syntaxiquement plusieurs fois une chose quasiment identique, et parfois pas moyen de raccourcir, mais ça n'arrive pas très souvent : il semble improbable que ça représente une proportion significative du code. Personnellement, je trouve le compromis plutôt intéressant en pratique : un langage avec suffisamment de syntaxe au départ pour traiter les cas courants n'a pas tous les jours besoin d'une extension, même s'il arrive toujours un moment où sans cela on écrit du code plus verbeux.

Et c'est vrai qu'il vaut mieux faire attention à ne pas écrire des macros pour tout et n'importe quoi, mais la contrepartie est qu'il est possible d'atteindre des niveaux d'abstraction plus élevées que dans d'autres langages.

Oui, la théorie est simple.

La plupart des langages généralistes essaient d'identifier les éléments de syntaxe qui leur semblent les plus importants pour leurs objectifs. Ils favorisent certaines constructions, rendent plus faciles certains motifs et un peu plus verbeux d'autres. Certains langages sont plus ou moins conservateurs avec l'ajout de nouvelles syntaxes qui seront utilisées peu souvent, mais l'idée reste quand même d'identifier l'important, encourager des idioms et définir une syntaxe qui sera concise pour la plupart des usages de prédilection du langage, tout en essayant d'étudier les usages moins fréquents pour s'assurer que ça ne devient pas trop verbeux non plus, même si pas totalement naturel ou optimal.

Lisp de son côté, partant du principe qu'il est impossible de savoir à l'avance ce qui sera vraiment important pour tous les utilisateurs, plutôt que de prendre parti et décider si telle ou telle syntaxe sera plus demandée qu'une autre, met tout sur un même niveau, et propose un potentiel d'adaptabilité impressionnant. Le prix (d'un point de vue langage, mettant de côté les conséquences sur la complexité du compilo), c'est que tout se ressemble, le simple et le compliqué sont difficiles à distinguer, la syntaxe n'encourage pas certaines approches par rapport à d'autres, et les idioms ont tendance à être moins prévisibles.

Il y a sûrement des programmes où ce degré d'adaptabilité fait vraiment la différence, où il n'est pas possible de prévoir un langage généraliste suffisamment adapté à l'avance, sinon des livres comme le « On Lisp » de Graham n'existerait pas, je suppose, mais je ne suis pas convaincu que le gain soit déterminant aussi souvent que le laissent penser les introductions philosophiques à ce langage.

Et pour les macros on peut afficher le code qu'elles génèrent, si on veut voir les détails :) .

Bien sûr, avec un bon éditeur de texte (je dirais emacs en général pour du Lisp), il y a moyen, avec de l'entraînement, de démêler la syntaxe, mais c'est quand même une étape de plus par rapport à une syntaxe qui se voit et fait partie du langage de base: il faut vraiment une factorisation significative pour que ce soit rentable (et qu'il n'existe pas d'alternative sans macros qui factorise presque autant, quitte à être moins élégante, ce qui néanmoins l'avantage de signaler qu'effectivement c'est un point délicat du programme). Et analyser du Lisp avec un outil externe statiquement semble peu évident.

Une bonne partie de la force (et probablement faiblesse) de Lisp réside dans une idée un peu analogue: tout programme Lisp suffisamment compliqué n'est pas écrit en Lisp, mais dans un dialecte de Lisp. L'apparence homogène d'un programme Common Lisp cache trompeusement qu'il s'agit probablement du langage avec le plus de syntaxe (en compétition avec Racket) déjà dans la spécification, et que cette syntaxe est étendue par tout programme utilisant des macros, donc au final il faut un peu apprendre un langage par programme, et je pense que tout ça y est pour quelque chose dans l'enthousiasme inégal qu'il produit (ce n'est pas uniquement la faute aux parenthèses :) ). L'approche génération de code externe, puis après on regarde le code est moins élégante et expressive, mais l'avantage c'est que le résultat est dans le même langage (donc analysable immédiatement par n'importe qui et par des outils aussi), et plus simple d'un point de vue compilation.

Je suis sur Go en ce moment. J'aime beaucoup sa simplicité, les variables typées, la compilation statique et la cross compilation.

Je me suis mis à apprendre Go il n'y a pas longtemps, et je dois dire que j'ai été très agréablement surpris par ce langage. C'est peut-être le premier langage généraliste que j'apprends où au bout de trois ou quatre jours j'ai l'impression que je peux comprendre à peu près n'importe quel bout de code écrit dans le langage, sans devoir démêler des astuces tordues ou des abstractions complexes (un fichier au hasard d'un programme complexe comme le compilo lui-même a de bonnes chances d'être assez accessible).

Et si le langage est simple, il n'est pas pour autant simpliste : même s'il ne permet pas une concision extrême, il est relativement concis sur plein de cas courants, et a fait quelques choix pragmatiques qui me semblent plutôt bons, comme le fait d'avoir des tableaux dynamiques (slices) et des maps de base, utilisables avec une syntaxe pratique, ce qui le rapproche des langages de script, mais avec des avantages du typage statique.
Et j'aime la qualité des divers outils (gofmt, godef, etc.), qui permettent à un éditeur de texte de fournir de bons plugins pour le langage ; qualité qui doit beaucoup à la simplicité du langage, je pense.

D'un point de vue concision et puissance du système de types il y a du coup quelques sacrifices qui sont faits (pas de généricité, pas de types algébriques, pas de classes avec héritage, etc.), mais le mécanisme fournit pour réutilisation de code (les interfaces) offre quand même beaucoup pour pas cher (moins compliqué pour l'implémentation, et moins à apprendre pour l'utilisateur), et les fonctions du langage pour les types de base comme les maps et les slices sont polymorphes, donc en pratique ces manques ne doivent pas souvent être très gênants. Bref, c'est un langage où tout est balance et compromis entre divers critères (parfois philosophiques même), mais le résultat est intéressant.

Globalement d'accord avec toi (à part que je trouve pas le langage SQL horrible :) ).

Ma Debian n'a du coup rien à voir avec une Debian par défaut…

Je n'en doute pas, mais il y a des chances qu'il te reste pas mal de « bloat » : des programmes de base (ls, find, cp, awk, etc.) pleins d'options que tu n'utiliseras jamais, peut-être même un systemd tout puissant, un méga shell (bash, zsh ? À moins que tu n'utilises que dash)… :) Blague à part, c'est une des raisons pour lesquelles j'utilise OpenBSD : tous les programmes de base ont moins d'options (mais le fait que celles qui sont là sont mieux documentées a plus joué probablement que le fait qu'il y en ai peu en soi). Mais malgré tout, je ne me sens pas trop mal lorsque je dois installer tout Qt et que sais-je d'autre pour utiliser un logiciel intéressant. J'essaie juste d'éviter au maximum les dépendances pour mon serveur (qui n'utilise que le système de base [qui a sqlite :)] et quelques modules Perl), mais pour le reste, je ne me pose pas autant de questions.