gasche a écrit 1151 commentaires

Pourquoi les gens de LinuxFR utilisent-ils un site/outil propriétaire pour héberger le code source libre de leur site sur le libre ? Il existe gitorious qui est une alternative libre très raisonnable.

J'édite pour rajouter qu'on en a parlé dans le suivi et que visiblement c'est facile techniquement mais que, bon, les gens ne sont pas trop motivés. Donc je râle.

Afficher les diffs dans l'espace de rédaction c'est bien, mais il n'est même pas possible d'éditer un commentaire ! Je regrette cruellement l'absence de cette fonctionnalité, qui rend la participation à DLFP une expérience frustrante et désagréable (oh oui ma belle faute d'orthographe, je te vois bien mais je ne peux rien y faire).

seL4 a été "vérifié" ce que ne sera jamais Linux, je ne dis pas que c'est la panacée
mais s'il est utilisé ce sera intéressant de voir si cela se traduit par un bénéfice en
pratique.

Ça pourrait être intéressant si le code source de la vérification était disponible... ce qui n'est pas le cas.

Ce n'est pas du tout une critique de ton commentaire (très respectable bien qu'à mon avis faux historiquement, Java a été le fruit d'un véritable design, tu confonds peut-être avec l'histoire de Javascript), mais le troll sur la conception de Java j'ai déjà donné et je ne souhaite pas m'y remettre pour l'instant; je ne répondrai donc pas aux prochains commentaires à ce sujet.

Ce que je voulais dire dans mon message initial c'est que quand on présente un nouveau langage il faut un regard critique qui cherche à la fois les avantages et les inconvénients. Si on n'a pas des deux, ou si on ne mentionne pas les alternatives existantes (Related work, Related work, Related work), on a une dépêche pas équilibrée, non neutre, et donc nettement moins intéressante.

La réponse de ddevito allait dans mon sens puisqu'il compare Xtend aux alternatives et c'est intéressant, mais j'ai l'impression qu'elle est quand même passée à côté de ce que je voulais dire : c'était un commentaire général sur les dépêches de ce genre, et pas sur Xtend en particulier (sur lequel je n'ai pas grand chose à dire à part "marrant, des développeurs d'IDE qui conçoivent un langage").

Compiler, c'est transformer un programme écrit dans langage de départ en un autre programme dans un langage d'arrivée, qui a le même sens que le programme de départ. Il n'y a pas tellement de définition plus raisonnable (souvent on veut aussi que le langage d'arrivée soit plus "bas niveau" que le langage de départ, mais de nos jours on compile vers Javascript...) et l'utilisation ici est donc acceptable.

Un bon design fait la chose courante et sûre par défaut, et permet les choses surprenantes, rarement utiles et plus avancées en les demandant explicitement (mais sans les rendre plus difficiles que nécessaire). Il faut que le choix le plus facile soit aussi le plus correct (parce que c'est celui qui sera fait naturellement).

Le fallthrough n'est pas le bon choix par défaut pour les utilisations usuelles de switch. Est-ce que tu peux montrer un bon exemple en Groovy où le fallthrough est utile ? En C, la classe d'exemple principale est le fait de chaîner plusieurs alternatives à la suite, chacune ayant un code vide sauf la dernière; mais on peut faire ça avec les listes de tests en Groovy.

Le fallthrough par défaut est la source de nombreuses erreurs dans les programmes. Il est courant d'oublier un break (beaucoup plus que d'en rajouter sans faire exprès) et cela change le comportement du programme d'une façon difficile voire impossible à repérer statiquement (contrairement par exemple à une typo dans le nom d'une variable ou l'oubli d'un paramètre à une fonction, erreurs plus courantes encore mais généralement faciles à détecter automatiquement).

Go n'a pas de fallthrough par défaut, mais le permet avec un mot-clé explicite fallthrough (documentation). C'est le bon choix pour une construction switch.
Le choix de Groovy est objectivement mauvais; et le fait qu'ils ne soient pas les seuls à se tromper n'est qu'une maigre consolation.

Java existe depuis 20 ans, pas 10, mais l'inférence de type existait déjà à l'époque. Ce ne sont pas "ceux qui écrivent des compilateurs" qui ont progressé, ils étaient déjà au niveau (sur l'inférence de type en tout cas, en 1990 l'état de l'art était très satisfaisant), ce sont les programmeurs "mainstream" qui sont un peu moins ignares qu'avant, et donc les décideurs qui conçoivent des langages pour leur plaire qui ont fait des efforts.

Ce n'est pas de ta faute, mais c'est un peu agaçant cette tendance à ré-écrire l'histoire en imaginant que les choses se sont déroulées comme les ont perçues la majorité, souvent sous-informée. À en croire certains, l'inférence de types a été inventée par Scala, la compilation JIT par Javascript, la métaprogrammation par Ruby, et la pizza par les américains.

Switch supports the following kinds of comparisons

• Class case values matches if the switchValue is an instanceof the class
• Regular expression case value matches if the string of the switchValue matches the regex
• Collection case value matches if the switchValue is contained in the collection. This also includes ranges too (since they are Lists)
• if none of the above are used then the case value matches if the case value equals the switch value

Et comment je teste si la valeur que je teste est égale à [1,2] ? Je mets la collection [[1,2]] ?

Encore un truc mal fichu; sans parler du breaktrough qui, non, ne se défend pas, c'est juste une mauvaise idée, surtout quand on a une syntaxe pour tester plusieurs cas d'un coup.

La news est précise, technique et sobre, c'est bien; par contre j'aurais bien aimé un poil plus de regard critique, on ne cite que des points positifs. Il existe de nombreuses alternatives à Xtend; je ne parle pas des langages JVM "avancés" comme Scala ou Clojure, mais des "Java-like en mieux" qui se veulent simples, incrémentaux et pas trop innovants,
Ceylon de RedHat. Kotlin de JetBrains.

Quand on présente un nouveau langage je pense qu'il serait intéressant de ne pas citer que des points positifs, mais aussi des points négatifs (il y en a toujours). Au moins, citer les alternatives me semble indispensable.

Je pense que les projets actuellement du BerliOS migreront vers des sites type Bitbucket, Github. L'impact pour nous est minime voire nul.

Pour moi ces deux phrases consécutives sont une contradiction. On a une tradition relativement solide de forges libres et riches en fonctionnalité, mais fracturées (chacun sa forge), lourdes et évoluant lentement. Depuis quelques années apparaissent des solutions plus légères, qui proposent un hébergement global, et majoritairement propriétaires.

Concrètement, dans la communauté du logiciel libre, les forges sont en train de mourir. Dire que les utilisateurs de BerliOS vont migrer vers des solutions d'hébergement propriétaires, ça n'a pas "un impact minime" sur les forges : c'est un clou de plus dans leur cercueil.

Je remarque par ailleurs que cette dépêche a cité github un grand nombre de fois (8 à la louche), sans même mentionner gitorious, une alternative libre raisonnable (même si moins riche en fonctionnalités).
Je trouve dommage ce monopole de github et bitbucket; on dirait que les développeurs de logiciels libres, qui font des efforts pour utiliser des outils libres sur leur machine, ne se posent pas la question pour les outils disponibles en ligne. On a en plus un effet réseau bien entretenu par le fait que tout le monde ne parle que d'eux. Résultat, quand un développeur se cherche un hébergeur (au hasard, Linus Torvalds), il va choisir un hébergeur propriétaire parce que "c'est le nom qu'il a retenu parce qu'on le voit partout".

C'est très confus tout ça, et ça n'a pas l'air lié du tout ni à Java, ni à la thèse de Gosling (ou plutôt, comme on ne sait rien de son travail de thèse, il est impossible de dire si ça a un rapport ou pas). Le mot "algèbre" est utilisé pour dire beaucoup de choses et deux domaines informatiques qui s'y réfèrent n'ont pas nécessairement de lien. J'aurais aimé retrouver quelque part le mot d'ordre "code as algebra" que Gosling a l'air de trouver si important et suggestif, mais rien de s'y réfère.

Dans ton premier lien on trouve beaucoup de preuve, un peu de "spécification", et des "process algebra", bref des calculs formels utilisés en concurrence par exemple.

La question de XQery est encore différente, si je comprends bien (je ne connais pas XQuery) il s'agit plus d'algèbre au sens de d'un ensemble d'opération ayant une sémantique bien définie qui permet de construire des objets (requêtes). Sur les BDD classiques on parle de "relational algebra".

Enfin, la partie sur la Dataflow analysis me semble ne pas avoir spécialement grand chose avec de l'algèbre (enfin on peut trouver de l'algèbre partout, et modéliser beaucoup de chose comme des structures algébriques).
(Par ailleurs le fait de manipuler un AST ou, même, une forme intermédiaire utilisée dans un compilateur, n'indique en rien qu'on s'intéresse au lambda-calcul, au typage, et aux modèles théoriques de celui-ci.)

Il y a d'autres courants de l'informatique théorique qui se réclament de l'algèbre ou y sont lié sans faire du bruit à ce sujet. Les questions de résolution de contrainte ont effectivement souvent une saveur un peu algébrique (il s'agit de manipulation formelle d'expressions syntaxiques qui ont un modèle sémantique). On parle aussi d'une algebra of programming au sujet des gens qui isolent des combinateurs expressifs pour la programmation fonctionelle : Squiggol, Lenses&Bananas, etc. Troisième exemple tiré du chapeau, on dit que Tony Hoare retravaille sur les sémantiques par pré-postcondition avec une approche plus algébrique.

Rien de tout cela, cependant, ne semble lié à la conception de Java.

Merci pour la référence. Si ça t'intéresse j'ai trouvé les slides ici. Sur les slides, nulle mention du typage effectivement (à part implicitement dans le fait qu'Algol et Simula étaient statiquement typés), donc rien de concluant d'un point de vue "théorie du typage¹" (sans parler du lambda-calcul).

Par ailleurs, j'ai essayé de trouver ce qu'il entend par "code as algebra", sans succès (chercher ça sur Google ne donne que des liens vers des retranscriptions de cette présentation), à croire que sa thèse et son idée clé ont complètement disparu de la surface du web.

¹: pour une perspective historique : Algol 68 avait des conversions implicites entre type très (trop) élaborées, et Simula a introduit la notion d'héritage et de sous-typage (mais les tableaux étaient, semble-t-il, invariants). Algol était extrêmement novateur dans le sens où c'est un des premiers, voire le premier, langage(s) avec un système de typage fort et clairement défini. La théorie est cependant venue après, au début des années 70, avec les travaux de Scott en particulier; les langages inspirés d'Algol (Algol 68, Pascal) n'ont pas respecté cette idée formelle du typage (ce n'est pas ce qui intéressait leurs créateurs, je pense), et Simula était à nouveau basé sur une idée informelle du typage, sans théorie bien précise derrière (ce n'est pas vraiment une critique, une grande partie des nouvelles constructions de langages de programmation ont été introduites d'abord, et bien typées seulement dans un second temps). Pour une présentation détaillée des fondements théoriques et de l'influence du langage Algol, cf. l'introduction de "Algol-like languages", un livre sur l'aspect théorique par des chercheurs en langages de programmation.

A moins que lorsque tu parles "d'incorrect", tu ne veuille dire "laisse passer des comportements incorrects", auquel cas, oui, pourquoi pas, mais c'est connu

C'est connu... depuis quand ? J'ai l'impression que c'est une erreur de conception qui leur a échappé, et dont ils ne se sont rendu compte qu'ensuite (par exemple dans l'intervalle de temps entre la spécification du langage Oak et l'écriture de la spécification de Java).

le lambda calcul n'est pas oblige d’être cantonne a une évaluation statique. Je me trompe ?

Non, tu ne te trompes pas; d'ailleurs c'est ce que fait l'article sur la "traduction de Java vers un lambda-calcul typé" dont tu parlais, il rajoute des tests dynamiques pour compenser la sémantique cassée du système de typage statique (et ses difficultés à modéliser la récursion ouverte en conservant le sous-typage, qu'on sait maintenant résoudre).

Cependant, une idée de base du typage est de refléter la sémantique du langage. Une relation de sous-typage était que si S est sous-type de T, alors toute valeur de type S peut être considérée comme une valeur de type T. Dans la théorie, c'est l'idée sémantique derrière le sous-typage, donc très important. Dans la pratique, c'est le principe de substitution de Liskov (LSP), énoncé en 1987 (donc avant la conception du langage Java) et donc connu, on l'espère, des concepteurs de Java. Or, la relation de sous-typage qui est présente dans Java viole ce principe de substitution, puisque S[] peut être sous-type de T[] sans qu'un tableau de type S[] puisse être utilisé de la même façon qu'un tableau de type T. C'est bête, et ça ressemble assez à une erreur de conception, non ?

Si ce test qui tue les performances et qui contrarie tout le monde est là, c'est sans doute parce que les gens n'ont pas vu le problème au départ et ont cru que c'était correct, parce qu'ils ne connaissaient pas le modèle théorique derrière. C'est une hypothèse (que j'ai déjà formulée dans mon post qui s'est fait descendre en flamme) crédible puisque le problème n'est pas mentionné dans les premières spécifications du langage.

Le rasoir d'Ockham me suggère que cette explication est plus plausible que l'hypothèse selon laquelle James Gosling, qui est en fait un gro pgm des systèmes de types qui cache bien son jeu, s'est amusé à cacher les failles sémantiques dans son système pendant plusieurs années (jusqu'à qu'un chercheur indépendant les pointes du doigt), à définir une relation de typage non-standard violant le LSP, pour le plaisir de rajouter un test de typage dynamique à chaque accès dans un tableau et de donner l'opportunité aux chercheurs en typage de se torturer pour trouver une manière raisonnable d'étendre le langage de façon sensée par la suite (... ce qu'ils n'ont pas tout à fait réussi, si on en croit les avis sur les génériques Java).

Encore une fois, je serais très intéressé par toute source confirmant que les concepteurs de Java ont pensé au modèle théorique de leur système de typage pendant la conception du langage (c'est à dire entre grosso-modo 1991, premières mentions de Oak, et 1994, arrivée de Guy Steele à Sun pour bosser sur la spec. du langage déjà conçu).

Regarde le modèle objet de OCaML, là c'est simple, c'est invariant. L'héritage est réduit à sa plus simple expression de ne pas recopier le code, mais lorsqu'il s'agit de mettre B là où il attend A, même si B hérite de A, le compilateur te jette tout de suite !

Non, c'est faux, on peut utiliser une forme de convertibilité en OCaml (et les types paramétrés peuvent porter une indication de variance sur chacun de leurs paramètres, qui est inférée selon leur définition quand c'est possible). La théorie est un peu différente, et surtout il faut demander la coercion vers A explicitement (on écrit (foo :> ty) ou (foo : t1 :> t2)), mais c'est tout à fait possible.

type t = < data : int >
let (li : t list) = []
let obj = object
    method data = 4
    method foo = ()
end
(* val obj : < data : int; foo : unit > *)
let test = (obj :> t) :: li
(* val test : t list = [<obj>] *)

type empty = < >
let test2 = (test :> empty list)
(* val test2 : empty list *)

Le terme "type-safe" peut désigner plusieurs choses. Un langage comme Python est "type-safe" dans le sens où avant chaque opération, on effectue un test dynamique pour vérifier que l'opérande a bien la forme attendue. Ça évite les erreurs de langages moins méfiants comme C qui segfault rapidement si les types ne correspondent pas (ce que le système de typage, en plus, ne sait pas vérifier, en raison entre autres de l'habitude de transporter tout ce qui doit être générique dans un void *).

Bien que le système de typage statique de Java soit incorrect, le langage est dynamiquement type-safe grâce au test dynamique qui est effectué à chaque écriture dans un tableau.

Comme je l'ai déjà dit, je doute que les concepteurs de Java se soient posé la question de la sûreté du typage statique, sinon ils auraient repéré ce problème et, à défaut de le corriger (ce qui n'est pas évident), l'auraient mentionné clairement dans les premières spécifications du langage. Ce n'est pourtant pas le cas dans la "Oak language specification" (version 0.2, la seule que j'ai trouvé facilement sur Internet). Il faut attendre 96, la première "Java language specification", écrite en grande par Guy Steele qui n'a pas participé au design de Java. Cette spécification discute le problème de l'assignement non statiquement sûr dans un tableau en détail, mais elle dit en même temps:

The following conversions are called the widening reference conversions:
[...]
From any array type SC[] to any array type TC[], provided that SC and TC
are reference types and there is a widening conversion from SC to TC .
[...]
Such conversions never require a special action at run time and therefore never
throw an exception at run time. They consist simply in regarding a reference as
having some other type in a manner that can be proved correct at compile time.

La spécification dit que la covariance des tableaux est "prouvée correcte statiquement". Au mieux c'est une formation ambiguë (ils veulent dire "on sait que c'est faux mais, sachant qu'il y a le test dynamique, plus tard, c'est quand même pas trop grave") qu'une personne attentive à l'aspect théorique de la chose aurait évitée, au pire c'est une erreur.

Après on pourrait dire qu'ils ont effectivement fait une étude théorique et juste laissé passer une erreur dans une preuve. Ça arrive. Mais ça ne colle pas avec la réalité historique qui est que les chercheurs en langages de programmation connaissaient à l'époque déjà très bien le problème. La question du sous-typage est apparue au milieu des années 80, est devenu un sujet chaud et a été très étudiée jusqu'au début des années 90. Le langage Quest de Cardelli contient des types paramétriques (donc sensiblement plus avancé que Java à l'époque), du sous-typage, et des variables modifiables; il discute clairement des problèmes liés à la mutabilité et précise explicitement que les tableaux sont invariants. La spécification de Quest a été publiée en 1994, mais la recherche sur laquelle elle se base date des années 80 (tous les articles cités ont été publiés avant 1990). Si les concepteurs de Java étaient au courant, comme tu le prétends, de la recherche théorique dans le domaine qui les concerne directement, ils auraient certainement été au courant et il me semble fort curieux qu'ils n'en aient donné aucun signe.

Bien sûr, il est difficile pour moi de prouver que James Gosling ne connaissait pas telle ou telle chose, puisque le fait qu'il n'en parle pas ne nous permet pas de savoir s'il le connaissait ou pas. Puisque tu sembles persuadé que Java a été conçu dès le départ avec un modèle théorique "rempli de lambda-calcul", peut-être as-tu eu accès à des documents sur l'histoire de Java qui en parlent ? Je serais très intéressé par ces sources qui, comme je l'ai dit, iraient à l'encontre de mon intuition propre. Le fait qu'il ait écrit une thèse dans un domaine qui à priori n'a rien à voir avec les langages de programmation¹ ne signifie pas grand chose (et par ailleurs si tu as pu mettre la main sur le manuscript de la thèse, je suis intéressé, parce que moi je n'ai rien trouvé).

¹: même s'il faut faire attention : son directeur de thèse faisait de l'IA et l'IA, au moins à ses débuts, était très liée à la conception de langages de programmation. Les gens qui faisaient de l'IA s'intéressaient cependant beaucoup plus aux aspects dynamiques des langages (programmation logique, backtracking, systèmes multi-agents, modèles d'acteurs...) qu'aux aspect statique (lambda-calcul typé). Lisp est clairement un produit de la recherche en IA, mais Fortran vient des calculs scientifiques, C de la programmation système et ML des assistants à la preuve formelle.

Je parle là de l'exécution "normale" d'un programme, pas du debugger. Je doute que "remonter le temps" soit possible sans un gros surcoût. Par contre, le programmeur peut mettre en place lui-même des "points de sauvegarde" en capturant des continuations aux endroits où il veut pouvoir revenir.

Ben Java est type-safe, et ça passe par du lambda calcul si tu veux le faire correctement. Tu peux avoir toutes les impressions que tu veux, ça reste vrai.

Qu'est-ce que tu veux dire au juste ? En tout cas ce qu'on essaie de prouver d'habitude sur les lambda-calculs typés, à savoir que la réduction / le calcul préserve le typage, est faux pour Java. En effet, les tableaux sont covariants (un tableau de Foo peut être considéré comme un tableau de Object par exemple) ce qui casse la sûreté du typage.

C'est aussi le cas dans Dart, mais dans Dart les gens disent "on sait que c'est cassé". Dans Java, il n'y a rien dans les spécifications des premières versions du langage qui permette de penser qu'ils le savaient.

L'erreur a été rapidement pointée du doigt par les chercheurs qui font des systèmes de typage, cf. ce vieil article, section "Java Arrays".

J'ai du mal à croire que Java "était plein de lambda-calcul pour faire les preuves"; si preuves il y a eu, elles étaient fausses.

Remarque : j'ai oublié le "i" de "important" mais je peux pas éditer. Et j'ai pas fait exprès.

Je suis à fond pour cette possibilité et je pense que la peur des abus n'est pas justifiée (au moins tant qu'on ne l'a pas activée pour tester et qu'on n'en a pas constaté dans la réalité, au lieu de les imaginer).

L'absence de cette fonctionnalité est vraiment quelque chose qui me gêne beaucoup dans mon utilisation de LinuxFR. Si en plus c'est facile à activer parce que déjà mis en place dans une autre partie du site, je ne vois pas pourquoi on hésite.

Non, je ne pense pas que Java ait été conçu avec un modèle théorique en tête. Je ne sais pas à quoi tu fais référence en disant qu'il est "rempli de lambda-calcul". L'impression que j'ai est plutôt que les ingénieurs qui ont conçu Java n'étaient pas forcément très au courant de la recherche dans le domaine, mais ont surtout retiré les fonctionnalités les plus complexes de C++ pour faire un langage simplifié.

Ensuite, dans les versions récentes de Java, l'importance pratique du langage a motivé des spécialistes de la théorie des types à se pencher sur la question des génériques notamment. C'est là que sont apparus des modèles formels de sous-ensembles de Java, basés sur la recherche faite indépendamment sur la théorie des langages objets. Mais ça ne veut pas dire que Java dans son ensemble ait été conçu par des gens connaissant la théorie.

la plupart des types qui s'amusent à faire un langage n'y connaissent pas grand chose [...] Dart en est un exemple vivant !

Ce que tu dis est à la fois incorrect et irrespectueux. Il suffit de lire la documentation sur Dart pour se rendre compte qu'une partie au moins de ses concepteurs connaît la théorie des langages de programmation, en particulier la théorie des types. Par exemple, ils mentionnent que Dart supporte la F-bounded quantification, qui est une fonctionnalité des systèmes de types objets avec abstraction de type et sous-typage.

Le fait d'avoir choisi, ensuite, de ne pas suivre les conseils de cette approche théorie et de mettre en place un système non statiquement sûr intentionnellement est une autre question. Je pense qu'ils ont tort, mais ça ne justifie pas de les prendre de haut.

Une solution qui marche plutôt bien, mentionnée par Ontologia, est d'utiliser un type somme comme l'ont entre autres OCaml, SML, Haskell, Typed Racket, et comme on peut vaguement encoder dans un langage objet (mais c'est bof agréable, sauf en Scala), c'est-à-dire un type dont les valeurs peuvent être de plusieurs formes selon les cas:

  type 'a option =
    | None
    | Some of 'a

Pour tout type 'a, une valeur de type 'a option est soit None, soit Some v où v est de type 'a. Par exemple None et Some 3 sont de type int option. C'est un type, en gros, qui "ajoute une valeur par défaut" à n'importe quel type. Tu peux donc représenter une variable de type t qui peut être observée initialisée comme une référence mutable vers du t option : elle est mise à None au départ, et quand tu l'initialises tu mets Some truc. Toute partie du programme qui veut accéder à cette variable doit distinguer les deux cas possibles:

   match !la_variable with
   | None -> do_something "damn, pas encore initialisée !"
   | Some valeur -> do_something_else valeur

Pour être agréable à utiliser, il faut une bibliothèque standard qui sait bien gérer les types options (Maybe en Haskell, Option en Scala il me semble). Les monades sont une abstraction qui permet de s'en servir en cachant la possibilité d'erreur (en gros on s'en sert comme si tout était défini, et si un des trucs n'est pas défini, le résultat du calcul est rendu indéfini).

Bref, il faut un langage un peu riche pour que cette méthode soit vraiment agréable, mais c'est une bonne façon de sortir l'aspect "contient une valeur par défaut" des types de base : on a des types de base bien définis sans valeur par défaut, et seulement là où on en a besoin on utilise des valeurs de type option; en plus l'optionnalité est précisée dans les types donc on ne peut pas l'oublier (comme on oublie que quelque chose peut être NULL).

Attention, je parle de la définition de variable locale, et non pas de variable toplevel comme le discute ta citation.

Un exemple : voici un bout de code Javascript utilisant let (donc pas portable mais passons, je choisis juste let pour avoir une portée classique, ici var marche aussi)

   [...]
   if (x > y) {  
     let z = 12.7 * x + y;
     do_something(z);  
   }
   [...]

Je peux placer ce bout de code à n'importe quel endroit de mon code qui connaît x, y et do_something, sans me soucier du reste, et ça va marcher exactement comme je l'entends.

Maintenant si j'essaie de faire pareil en Coffeescript

   [...]
   if (x > y)
       z = 12.7 * x + y;
       do_something(z);
   [...]

Ce code ne fait la même chose que si z n'existe pas déjà dans le contexte.

En effet, si mon contexte est :

  z = "foo"
  # le bloc ici
  bar(z)

Ça casse:

   z = "foo"
   if (x > y)
       z = 12.7 * x + y;
       do_something(z)
   bar(z) # z ne vaut plus "foo" !

Je n'ai pas moyen de dire (à part en encapsulant dans une fonction, ce qui est exactement ce que Coffeescript fait pour éviter les soucis de syntaxe de JavaScript; donc il faudrait refaire ça par dessus pour avoir une portée correcte) que je veux choisir un nouveau z qui n'affecte pas ce qui existe déjà.

Ça veut dire que si je veux déplacer un bout de code qui fait ça, et que je veux le mettre là, il faut que je renomme dans ce bout de code toutes les occurences de z vers un autre truc genre z1. Ça augmente l'effort de maintenance et c'est un bug qui ne demande qu'à arriver : on oublie de renommer l'un des z et on est mort... Bref, l'impossibilité de "masquer" des noms existants en déclarant une nouvelle variable locale est très gênante (d'ailleurs Erlang a aussi ce défaut, mais c'est un autre débat).

La réponse des auteurs de CoffeeScript est "oui mais ça pose problème que si tu as plusieurs niveaux de variables locales, donc plusieurs blocs imbriqués, et les blocs imbriqués c'est mal de toute façon". Je pense pour ma part que si un langage ne se comporte pas bien au niveau des définitions de variable locale, ça posera forcément problème à un moment où à un autre, même si les concepteurs aimeraient bien que tout le monde programme de la façon qui les arrange. Je n'ai pas envie d'utiliser un langage qui n'apporte pas cette garantie de base : ça fait des années qu'on sait comment gérer les variables locales de façon robuste (portée lexicale avec lieurs explicites), mais les concepteurs de langages continuent à ignorer ça et faire n'importe quoi.

Attention, je parle de la définition de variable locale, et non pas de variable toplevel comme le discute ta citation.

Un exemple : voici un bout de code Javascript utilisant let (donc pas portable mais passons, je choisis juste let pour avoir une portée classique)

[...]
if (x > y) {  
  let z = 12.7 * x + y;
  do_something(z);  
}
[...]

Je peux placer ce bout de code à n'importe quel endroit de mon code qui connaît x, y et do_something, sans me soucier du reste, et ça va marcher exactement comme je l'entends.

Maintenant si j'essaie de faire pareil en Coffeescript

[...]
if (x > y)
z = 12.7 * x + y;
do_something(z);
[...]

Ce code ne fait la même chose que si z n'existe pas déjà.

En effet

z = "foo"
if (x > y)
z = 12.7 * x + y;
do_something(z)
# z ne vaut plus "foo" !

Je n'ai pas moyen de dire (à part en encapsulant dans une fonction, ce qui est exactement ce que Coffeescript fait pour éviter les soucis de syntaxe de JavaScript; donc il faudrait refaire ça par dessus pour avoir une portée correcte) que je veux choisir un nouveau z qui n'affecte pas ce qui existe déjà.

Ça veut dire que si je veux déplacer un bout de code qui fait ça, et que je veux le mettre là, il faut que je renomme dans ce bout de code toutes les occurences de z vers un autre truc genre z1. Ça augmente l'effort de maintenance et c'est un bug qui ne demande qu'à arriver : on oublie de renommer l'un des z et on est mort... Bref, l'impossibilité de "masquer" des noms existants en déclarant une nouvelle variable locale est très gênante (d'ailleurs Erlang a aussi ce défaut, mais c'est un autre débat).

La réponse des auteurs de CoffeeScript est "oui mais ça pose problème que si tu as plusieurs niveaux de variables locales, donc plusieurs blocs imbriqués, et les blocs imbriqués c'est mal de toute façon". Je pense pour ma part que si un langage ne se comporte pas bien au niveau des définitions de variable locale, ça posera forcément problème à un moment où à un autre, même si les concepteurs aimeraient bien que tout le monde programme de la façon qui les arrange. Je n'ai pas envie d'utiliser un langage qui n'apporte pas cette garantie de base : ça fait des années qu'on sait comment gérer les variables locales de façon robuste (portée lexicale avec lieurs explicites), mais les concepteurs de langages continuent à ignorer ça et faire n'importe quoi.