Discussion :

[limestrael]

...ou quand programmer est une question d'esthétique (ce qui tout le temps le cas)

Quels sont pour vous les langages qui ont la plus belle syntaxe (après, à chacun sa définition de "beauté") ? (Je poste ça dans les langages fonctionnels vu que quasiment tous les langages impératifs que je connais ont une syntaxe laide voire horrible, et qu'en général, les gens qui connaissent du fonctionnel connaissent aussi de l'impératif/objet, l'inverse étant malheureusement faux)
Pour moi, il y en a 2 : Python (*) et Haskell. C'est pas pour rien: ils se basent tous les deux sur l'indentation pour définir le bloc, du coup ça allège la syntaxe (et la sobriété, c'est beau)

(*) J'ai dit "quasiment" tous les langages impératifs

[davcha]

Le lambda-calcul pur.


edit: en fait non, j'hésite entre ça, brainfuck et whitespace.

[Jedai]

Haskell, Smalltalk, Factor, Scheme... Pour moi la beauté d'une syntaxe tient principalement dans la facilité avec laquelle elle exprime les concepts sous-jacent au langage.

Néanmoins la beauté d'une syntaxe n'est pas mon premier critère quand il s'agit de choisir un langage...

--
Jedaï

[Mac LAK]

...ou quand programmer est une question d'esthétique (ce qui tout le temps le cas)

Heu... Et on te paie pour ça ?
Non, programmer, c'est avant tout réaliser un but dans un cadre précis... Le cadre pouvant aller aussi bien du "temps de dév minimal" qu'aux "perfs maximales", en passant par "en utilisant tel langage" : on s'en fiche, chacun ses contraintes, et ça n'a en fait aucune importance en dehors des personnes concernés.
L'esthétisme, c'est quand tu as du temps de rab, ce qui est rarissime en milieu professionnel : ça bouffe les marges, et donc la participation aux bénéfices...

Faudrait pas oublier quand même que le forum s'adresse aux professionnels d'abord (cf. le nom, "Club des professionnels de l'informatique"), et donc la contrainte du monde "réel", celui qui fait bouillir la marmite, est quand même un peu non-négociable...

Néanmoins la beauté d'une syntaxe n'est pas mon premier critère quand il s'agit de choisir un langage...

Pour une fois que l'on est d'accord sur un point... N'importe quel langage peut être rendu illisible, ou au contraire parfaitement lisible et agréable. Tout est une question de rigueur dans l'écriture du code, qu'il soit haut ou bas niveau, fonctionnel ou impératif, compilé ou interprété.

Pour moi, la beauté d'une syntaxe, c'est quand l'erreur de frappe ne peut JAMAIS passer l'étape de la compilation pour donner une erreur à l'exécution... J'ai beau programmer énormément en C, j'ai toujours trouvé sa syntaxe totalement débile (surtout sur un clavier AZERTY !), notamment lorsqu'on la compare à celle du Pascal ou de l'Ada...
En C, mettre "=" à la place de "==", ou de "!=", c'est (hélas) trop facile, et cela peut souvent ne pas être détecté à la compilation vu le nombre de gorets qui ne tiennent pas compte des warnings du compilateur... Encore pire avec "&" et "&&" !!
En Pascal, "=" à la place de ":=", c'est erreur de compilation directe. Et pour confondre "<>" avec "=", il faut plus qu'être dyslexique. Quant aux opérations binaires et logiques, le typage fort des booléens interdit la moindre confusion.

Dans tous les cas, je choisis un langage parce qu'il est parmi les meilleurs dans le domaine que je dois traiter ET qu'il offre le meilleur compromis financier (former des gens, ça coûte très cher, surtout si c'est pour gagner peu par rapport à un système déjà connu et légèrement moins performant).
A titre personnel, pour mon plaisir strict, c'est du Delphi (Pascal) qui remporte la palme, pour la clarté de sa syntaxe.

[limestrael]

Heu... Et on te paie pour ça ?

Non, car c'était ironique...

[LLB]

Pour ma part, je penche pour Haskell et F#.

C'est pas pour rien: ils se basent tous les deux sur l'indentation pour définir le bloc, du coup ça allège la syntaxe

Note que cette fonctionnalité est bien plus restreinte en Python qu'en Haskell/F#. Essaie d'écrire une expression un peu complexe et tu te retrouves à devoir mettre des backslashs en fin de ligne (ce qui, soit dit en passant, empêche de pouvoir mettre un commentaire). Essaie de faire une fonction anonyme et tu verras à quel point la syntaxe de Python te limite. Essaie de faire un if/then/else sur une ligne et tu te feras jeter (heureusement, il y a maintenant l'opérateur ternaire - qu'on a attendu pendant 15 ans).

Pour moi, la beauté d'une syntaxe, c'est quand l'erreur de frappe ne peut JAMAIS passer l'étape de la compilation pour donner une erreur à l'exécution...

C'est utopique. Une faute de frappe dans une chaîne de caractères ou dans un identifiant peut conduire à ce problème, le compilateur ne peut pas toujours le signaler. Pour le cas général, je suis assez d'accord avec toi... mais cela élimine d'office tous les langages dynamiques.

[Mac LAK]

C'est utopique. Une faute de frappe dans une chaîne de caractères ou dans un identifiant peut conduire à ce problème, le compilateur ne peut pas toujours le signaler. Pour le cas général, je suis assez d'accord avec toi... mais cela élimine d'office tous les langages dynamiques.

Utopique ? Pas dans tous les langages, heureusement... Je suis totalement d'accord avec toi en C/C++, mais bon : ce ne sont pas des "modèles" à ce sujet, au contraire.
Avec des règles de nommage un minimum correctes, et dans un langage un peu évolué à ce sujet (j'ai cité notamment Pascal et Ada), il est quasiment impossible de ne pas voir ceci à la compilation.

Quant aux langages interprétés... Je dirais que c'est également possible s'ils ont une syntaxe propre (=pas celle du C, par exemple), et qu'ils sont plus ou moins compilés (ou mis en équivalent bytecode) avant exécution au lieu d'être interprétés "bêtement".
Ce qui est loin d'être impossible à faire, au moins sur une passe "élémentaire", et ceci quel que soit le langage interprété. Mais je ne pense pas que ce soit systématiquement le cas par défaut pour tous ces langages...

[Heziva]

Sans aucun doute :
Piet ! Je ne crois pas qu'il y ait de critère d'utilité dans ce topic ;-)

Ah oui, le Shakespeare est bien aussi dans son genre !

[gasche]

Plutôt que des critères relatifs d' "esthétique", je serais intéressé par une évaluation des syntaxes de langages de programmation sur des critères objectifs.

Il y a des choix syntaxiques qui :
- sont de bonnes/mauvaises idées dans l'absolu
- sont de bonnes/mauvaises idées en raison des autres choix syntaxiques
- sont de bonnes/mauvaises idées en raison de la sémantique et du style de programmation privilégié du langage

On peut les évaluer objectivement.

Par exemple, je pense que le choix d'avoir une récursion implicite est toujours mauvais : dans certains cas ont veut pouvoir réutiliser dans une définition le sens précédemment assigné au même nom (puisque dans la plupart des langages à portée lexicale un binding peut en "cacher" un autre pré-existant), et la récursion implicite empêche cela. Cela pose des problèmes concrets et rend certaines choses plus délicates à programmer.

Par exemple, Haskell utilise de la récursion implicite pour ses valeurs, mais OCaml utilise de la récursion implicite pour ses types ce qui n'est pas bien non plus (mais gênant moins souvent). Dans les deux cas il est objectivement préférable d'avoir une récursion explicite, pour permettre les idiomes où on cache d'anciennes déclarations.
Cependant, la syntaxe Haskell décourage l'emploi de mots clés, il serait donc assez délicat d'y trouver une bonne syntaxe pour la récursion explicite.

Exemples de code qui utilise la possibilité de rebinding :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let f x =
  let x = sanitize x in
  ..

let f x = sanitize (f x)

let parse i =
  let (token, i) = parse_token i in
  let (op, i) = parse_op i in
  let (token, i) = parse_token i in
  (Op (token, op, token), i)

module Sql = struct
  type int = < t : int; nullable : false_t; numeric : true_t > (* ne marche pas en OCaml *)
end

Critique des types implicitement récursifs en OCaml : http://ocaml.janestreet.com/?q=node/25

Exemples de code Haskell qui exhibent le problème de la récursion implicite :
- ici
- là


Un autre langage qui a des problèmes de taille liés à la syntaxe est Erlang : en Erlang la signification d'un pattern dépend du contexte : si les variables sont déjà bindées, elles agissent comme un test d'égalité, sinon ce sont des binders. Cela rend les patterns non composables (car dépendant fortement du contexte), alors qu'une notation explicite pour les patterns-unificateurs (comme veut le faire Reia) aurait résolu le problème.
Un autre problème de la syntaxe Erlang est qu'il est impossible d'y déclarer des fonctions locales. On peut en général s'en passer en bindant des lambda-expressions à des variables, mais ça ne marche pas pour des fonctions récursives.


Ce sont des critères syntaxiques objectifs qui sont à mon avis plus instructifs que des considérations sur "bouh les accolades ça me fait vomir" : si demain on a besoin de créer une nouvelle syntaxe pour un langage de programmation, il vaut mieux la faire reposer sur des arguments concrets que des discussions sur la couleur de la nappe.

Je pense qu'avec un peu d'efforts on pourrait transformer le critère de Mac LAK en un critère objectif : on doit pouvoir mesurer la "résistance au bruit" des langages, c'est à dire la probabilité qu'une petite erreur dans le texte du programme passe inaperçue à la phase de parsing/compilation. Avec une définition plus précise d'une "petite erreur" ou "faute de frappe" (je ne suis pas sûr que muter un seul caractère au hasard soit la meilleure méthode, mais ça peut suffire pour des premières mesures) on doit pouvoir obtenir des résultats intéressants sur les langages existants.

Il est aussi possible de mesurer la complexité des grammaires des langages de programmation, et on peut supposer qu'une grammaire complexe est "moins bonne" qu'une grammaire simple, mais on peut décrire de plusieurs façons différentes la grammaire d'un langage de programmation. Des résultats expérimentaux sont exposés dans l'article Metrication of SDF Grammars (pdf, 29 pages), on peut par exemple y observer (page 20) que les grammaires de C++ sont systématiquement plus compliquées que les grammaires de Java.

[LLB]

Par exemple, je pense que le choix d'avoir une récursion implicite est toujours mauvais

Évidemment, je n'ai pas le même avis. Ce que je retiens de tes arguments, c'est que l'on a besoin de différencier le cas récursif du cas non-récursif. C'est un poil différent de ta conclusion.

Neuf fois sur dix, une fonction et un type utilisent une récursion, plutôt qu'une réutilisation. Alors, à choisir, je préfèrais avoir une syntaxe plus verbeuse pour le cas de la réutilisation.

Par exemple, ton code donnerait (je défends une idée, plutôt que la syntaxe elle-même) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let f x with f' = sanitize (f' x)

où f' désignerait l'ancienne valeur de f (le "with <ident>" étant optionnel).

Pour ma part, je trouve le mot-clé "rec" de Caml lourd et peu agréable, surtout pour un langage où la récursion est assez fréquente.

Il est aussi possible de mesurer la complexité des grammaires des langages de programmation, et on peut supposer qu'une grammaire complexe est "moins bonne" qu'une grammaire simple, mais on peut décrire de plusieurs façons différentes la grammaire d'un langage de programmation.

Si l'on veut une grammaire simple, robuste ("résistante au bruit"), qui n'utilise pas des symboles douteux, qui n'est pas le problème d'Haskell ("il serait donc assez délicat d'y trouver une bonne syntaxe pour la récursion explicite")... on pourrait se diriger vers du Lisp. Ce qui ne serait pas forcément une mauvaise idée, d'autant plus que ça simplifie la métaprogrammation.

[gasche]

Tu as tout à fait raison : pour résoudre le problème que je décris il suffit d'avoir une méthode syntaxique pour différencier les déclarations récursives des non-récursivies; on peut donc ajouter plutôt un marqueur syntaxique pour la non-récursivité.
C'est d'ailleurs une possibilité que j'ai considérée pour conserver la compatibilité avec les langages existants. On pourrait imaginer par exemple une nouvelle syntaxe "type nonrec ..." en OCaml (par contre il n'est pas raisonnable de l'implémenter avec Camlp4 parce que la traduction sémantique passe par l'introduction silencieuse d'alias de types, qui peuvent ensuite apparaître dans les messages d'erreur montrés à l'utilisateur, ce qui fait plutôt mauvais genre).

Il s'agit ensuite de faire un choix, en fonction de la sémantique du langage (par exemple en Haskell, on a tendance à se dire que tout est codata, donc il pourraît être cohérent d'avoir la récursivité par défaut) ou du style qu'il encourage.

Je préfère marquer explicitement la récursion parce que le processus cognitif correspondant à la lecture d'une déclaration récursive est "plus compliqué". C'est un mode de pensée différent qui requiert un effort supplémentaire, et selon mon expérience personelle la présence d'un petit marqueur syntaxique "attention, il faut que tu lises cette déclaration avec la récursivité en tête" ne peut qu'aider à la compréhension.
Le mot-clé "rec" entre donc dans le cadre d'une 'documentation' de la fonction, et je ne trouve pas qu'il alourdisse tellement les déclarations : pas plus je pense que les déclarations de type par exemple qui sont pratiquées dans tous les langages sans inférence, et pour les termes toplevel en Haskell (par habitude plutôt que par nécessité en général).
Bien sûr, on peut avoir le même avantage (sur le fait de fixer le lecteur sur le mode de lecture à utiliser pour une déclaration) avec un marqueur explicite de la non-récursion. Il peut alors se produire le cas d'une déclaration non-récursive qui est laissée comme récursive (parce ça ne change pas la signification du programme), ce qui fausse un peu la précision de cette différentiation, mais je ne pense pas que ça gênerait à la compréhension : si on ne rencontre par le mot-clé en cours de définition dans la définition, il n'y a pas (d'apès mes observations) d'effort supplémentaire lié à la récursion.

On est d'accord, cette partie de l'argument (marqueur explicite pour la récursivité ou la non-récursivité) est moins objective, et on pourrait dire qu'elle retombe dans le "bleu ou rouge mon gidon ?" des considérations syntaxiques habituelles. Tant qu'il y a un moyen syntaxique de marquer cette différence, moi je ne me plains pas.



Pour ce qui est de la grammaire Lisp, je ne pense pas que ce soit la voie à suivre. Une grammaire Lisp n'a aucune structure notable, toutes les constructions sont absolument uniforme, au contraire d'une grammaire plus structurée (la plupart des langages non-lisp) qui a une grammaire hétérogène avec différentes syntaxes pour représenter différentes constructions sémantiques.
Je pense que l'hétérogénéité a aussi ses mérites, parce qu'elle rend plus d'information sémantique accessible à travers la syntaxe. Concrètement ça se traduit par le fait que les débutants trouvent en général la syntaxe Lisp plus difficile à lire (bien sûr c'est souvent aussi qu'ils sont pollués par les autres syntaxes qu'il connaît, et tous les langages qui ne singent pas la syntaxe du C ont ce problème, mais Lisp est le seul langage dont ils reviennent en disant "g rien compris, ya des parenthèses partout" et pas un simple "c'est trop moche lol").

La question de la méta-programmation est un peu plus compliquée : oui, avec une grammaire complètement homogène il est particulièrement simple d'envisager des macros, d'où leur existence en Lisp, Liskell, etc. Mais on peut aussi avoir des quotations/antiquotations sur des langages à la grammaire plus structurée, ça passe juste par un AST un peu plus compliqué. Je pense que dans l'absolu ça ne rend pas plus difficile ou moins efficace la métaprogrammation syntaxique (celle qui est basée sur le parsing ou la production de terme de la grammaire du langage), et je pense que Camlp4 (à part ses choix syntaxiques assez lourdingues) en est une bonne preuve/réalisation.

Par ailleurs je pense que la question hétérogénéité/homogénéité est indépendante de la résistance au bruit du langage : je ne vois pas pourquoi à priori une syntaxe lisp serait plus résistante aux modifications, et j'ai plutôt l'impression qu'au contraire, moins de modifications deviendraient des erreurs syntaxiques et il faudrait se reposer plus sur la sémantique du langage.

Par ailleurs je n'ai pas dit que les trois critères que j'étais donné étaient les seuls à prendre en compte. Ce n'est clairement pas le cas, et il existe sans doute aussi des critères qui peuvent être en contradiction avec ces premiers. Par exemple il est possible (mais ça reste à prouver) que la concision d'une syntaxe soit contradictoire avec sa résistance au bruit. Il ne s'agirait alors plus de maximiser les deux facteurs mais de trouver un compromis acceptable. Par exemple une grammaire simplifiée (sans toutes les extensions domaine-spécifique) de COBOL respecte très bien ces critères (très résistante au bruit, pas de symboles douteux, facile de rajouter un mot clé sans faire tache), et pourtant il semble y avoir un consensus sur le fait que ce n'est pas la syntaxe la plus agréable à utiliser pour des habitués de la programmation (la question de la lisibilité de la syntaxe pour des non-spécialistes est un peu différente).

[gorgonite]

j'ai un peu l'impression qu'on vient de "sombrer" vers un débat "comment faire le plus beau langage fonctionnel ?"

[gasche]

Non, le débat n'est pas limité aux langages fonctionnels. La question de faire des choix syntaxiques est présente pour tous les langages, et les langages impératifs ou objets ont eux aussi des choix syntaxico-sémantiques à faire. Après, si les "professionnels" sont trop occupés à faire bouillir la marmite, c'est pas de notre faute.

Exemples de questions à se poser pour le design d'un langage impératif :
- faut-il séparer expressions et statements ?
- quelle syntaxe pour les boucles ?
- faut-il mettre une instruction goto ? Si oui, avec quelles restrictions ?
- le concept de "bloc d'instructions" a-t-il un intérêt ?

Après il y a aussi des questions plus subjectives, qui n'ont sans doute pas de "bonne(s) réponse(s)" :
- comment représenter le type d'une fonction (je pense qu'on peut faire plus lisible que ce qui se fait en C) ?
- faut-il utiliser des séparateurs de blocs homogènes (accolades partout par exemple) ou spécialisés (endfor, endif, fi, od, ...) ?

Enfin, le fond du trou de la discussion syntaxique, qui n'apporte en général pas grand chose de neuf ou d'intéressant :
- indentation signifiante ?
- quelle syntaxe pour l'assignation et l'égalité ?
- symboles (accolades, parenthèses..) ou mots-clés (then, begin/end..) ?
- nommage des identifiants (fooBar, foo-bar, foo_bar, `foo bar`...) ?

[gorgonite]

on peut supposer qu'une grammaire complexe est "moins bonne" qu'une grammaire simple, mais on peut décrire de plusieurs façons différentes la grammaire d'un langage de programmation.

donc selon toi, Pascal est-il le langage ultime du fait de sa grammaire LL(1) ?

Non, le débat n'est pas limité aux langages fonctionnels. La question de faire des choix syntaxiques est présente pour tous les langages, et les langages impératifs ou objets ont eux aussi des choix syntaxico-sémantiques à faire. Après, si les "professionnels" sont trop occupés à faire bouillir la marmite, c'est pas de notre faute.

je me doute bien que le problème ne porte pas que sur les langages fonctionnels, et que chacun préfère parler de ce qu'il connait le mieux pour montrer ce qu'il y voit d'intéressant... mais si l'on veut rester sur un débat plus ouvert, peu faut-il tenter de ne pas assommer les gens avec camlp4 "brut de fonderie" et expliquer un peu... pas sûr que 80% de nos lecteurs comprennent bien le sens de cette phrase par exemple

Mais on peut aussi avoir des quotations/antiquotations sur des langages à la grammaire plus structurée, ça passe juste par un AST un peu plus compliqué. Je pense que dans l'absolu ça ne rend pas plus difficile ou moins efficace la métaprogrammation syntaxique (celle qui est basée sur le parsing ou la production de terme de la grammaire du langage), et je pense que Camlp4 (à part ses choix syntaxiques assez lourdingues) en est une bonne preuve/réalisation.

[gasche]

mais si l'on veut rester sur un débat plus ouvert, peu faut-il tenter de ne pas assommer les gens avec camlp4 "brut de fonderie" et expliquer un peu...

Le concept d'(anti)quotation est présent dans Lisp/Scheme, qui (au contraire effectivement de camlp4) fait quand même partie de la culture commune en langages de programmation.

Je pense que si des gens intéressés avaient eu des problèmes de compréhension, ils auraient posé la question; en l'absence d'évidence de gens à la fois intéressés et non renseignés, je n'ai pas élaboré, mais si tu penses que c'est utile c'est avec plaisir : dans les langages de programmation ou bibliothèques logicielles qui permettent de manipuler des "bouts de programme" sous forme d'arbres de syntaxe abstraite (les données correspondant à la représentation graphique concrète d'un bout de programme), un concept très présent car très pratique est la quotation : on écrit un bout de programme entre des délimiteurs spécifiques (les ou la "quote"), et l'ensemble désigne non pas le bout de programme effectif, mais l'AST correspondant à ce bout de programme. Par exemple si (print x) est le bout de programme qui affiche x, (quote(print x)) sera une représentation de la syntaxe abstraite correspondant à (print x), quelque chose comme (statement "print" (var "x")). La quotation permet donc de décrire des bouts de l'arbre syntaxique en utilisant la syntaxe concrète du langage.

L'opération inverse, l'antiquotation, sert à insérer des bouts de code à l'intérieur d'une quotation. Si par exemple j'ai une variable (x_var) qui désigne le bout d'AST représentant une variable (par exemple (var "x") ou (var "foo")), je veux écrire le bout d'ast (statement "print" x_var), je ne peux pas utiliser (quote(print x_var)) car "x_var" est 'quoté' et je récupèrerait donc (statement "print" (var "x_var")), qui n'est pas ce que je veux. Si mon langage propose une primitive (antiquote x ) qui prend un bout d'AST et lui empêche d'être "quoté", je peux alors écrire (quote(print (antiquote x_var))).

Ce n'est sans doute pas très clair si vous n'avez jamais vu ça, mais c'est normal : ce sont des notions pas triviales qui demandent un peu de pratique pour être bien assimilées. Et on peut sans doute expliquer mieux.

donc selon toi, Pascal est-il le langage ultime du fait de sa grammaire LL(1) ?

Quand je parle de la "complexité" d'une grammaire, je ne parle pas de la classe de complexité de l'algorithme de parsing utilisé. Je parle plus généralement du nombre de concepts de la grammaire, de sa régularité, de la présence ou non d'ambiquités, d'exceptions aux règles globales, etc. C'est un concept informel beaucoup plus général que la question de LL/LALR/etc, et dont je ne prétends pas pouvoir donner une définition précise, je ne suis pas un spécialiste du domaine (qui recoupe sans doute de la programmation, de la psychologie, de l'interface homme-machine, des sciences de l'apprentissage, de la linguistique, etc.).

Après, il y a certainement un rapport entre la facilité pour un ordinateur à parser une grammaire, et sa compréhensibilité pour le lecteur humain. Si une grammaire est très simple à parser, elle est sans doute aussi simple à assimiler pour un humain qui peut appliquer essentiellement les mêmes règles que l'ordinateur. La syntaxe LISP par exemple est facile à parser, et facile à expliquer à un débutant, et c'est lié. L'aspect LL peut aussi entrer en jeu.

Cependant, je crois que les algorithmes classiques de parsing peuvent aussi constituer des obstacles à la clarté d'une syntaxe. On a en fait beaucoup progressé depuis l'époque du LL(1) et on a maintenant des outils pour décrire des grammaires nettement plus riches (sur la question des ambiguités par exemples) : dpygen, le framework SDF, etc. On peut donc dans une certaine mesure se libérer des contraintes qui sont dans le fond des contraintes dues à l'implémentation de nos parseurs, et se recentrer sur l'utilisateur humain.

Nous ne raisonnons pas comme des ordinateurs (en tout cas pas en première approche), donc je pense qu'il y a aussi d'autres aspects à prendre en compte. J'ai parlé de la question de l'hétérogénéité des constructions syntaxiques, je pense que, si on n'en abuse pas, elle peut accélérer la lecture et compréhension d'un programme pour un lecteur humain en lui fournissant des "points de repère", alors qu'elle diminue l'uniformité donc rend un peu plus long le programme de parsing (on ajoute des cas). Bien sûr c'est une idée personelle et je n'ai pas fait d'étude empirique objective de la question, mais il me semble très clair qu'il y a des informations de nature visuelle et linguistique [1] que nous pouvons exploiter pour clarifier la syntaxe.

[1] Certains programmeurs prétendent que l'aspect "proche des langues naturelles" de certaines constructions de certains langages de script ("my $x = ...", "10.times do { .. }", "do() if something"...) les rendent plus faciles à comprendre.

Après, la facilité d'une syntaxe à être manipulée par des programmes restent importante, car un langage de programmation a crucialement besoin d'outils sachant analyser et produire du code source (compilateurs, outils d'analyse statique, IDE, préprocesseurs, logiciels de gestion de version...). Le langage C++ par exemple est très souvent critiqué pour avoir une syntaxe extrêment difficile à parser correctement, alors que ce sont des ambiguités qui ne gêneront pas forcément le lecteur humain.


En résumé, je pense qu'on ne peut pas se contenter de comparer les classes de complexité des grammaires pour estimer leur compréhensibilité par un humain. Par contre, j'ai déjà eu l'occasion de constater que quand il y a une ambiguité syntaxique résolue par une convention arbitraire (comme les conflits du type shift/reduce), les débutants n'ont aucune idée de la convention avant de se tromper (pour reprendre un exemple en caml, un débutant sur deux environ se trompera sur la signification de "if a then if b then c else d"). Les langages à indentation signifiante peuvent aider dans ce domaine, en éliminant une partie des ambiguités sans rajouter de symboles visuels alourdissant le programme, mais il y existe sans doute d'autres solutions.



Il n'y a à ma connaissance pas de recherche à proprement parler sur ces questions (ou alors je ne l'ai simplement pas trouvée), et je trouve cela bien dommage parce que ça reste un des rares domaines de la conception des langages de programmation où on en reste réduit à "faire de la bidouille" en suivant son humeur.

[Mac LAK]

Je pense qu'avec un peu d'efforts on pourrait transformer le critère de Mac LAK en un critère objectif : on doit pouvoir mesurer la "résistance au bruit" des langages, c'est à dire la probabilité qu'une petite erreur dans le texte du programme passe inaperçue à la phase de parsing/compilation. Avec une définition plus précise d'une "petite erreur" ou "faute de frappe" (je ne suis pas sûr que muter un seul caractère au hasard soit la meilleure méthode, mais ça peut suffire pour des premières mesures) on doit pouvoir obtenir des résultats intéressants sur les langages existants.

Cela existe déjà... Tu as déjà la distance de Levenshtein, voire la distance de Hamming, qui permettent de mesurer objectivement la "distance" entre chaque élément d'un langage.
Tu peux même y inclure en partie la théorie de séparabilité des éléments lexicaux, un peu dans le style de la séparabilité des codes de Huffman, afin qu'aucun élément lexical ne soit le préfixe d'un autre élément lexical différent.

donc selon toi, Pascal est-il le langage ultime du fait de sa grammaire LL(1)

En tout cas, ça fait des compilateurs ultra-rapides : Delphi est apparemment toujours le compilateur le plus rapide du monde...
(Pour mémoire, BP7, à l'époque, bouffait déjà 85.000 (quatre vingt cinq mille) lignes par SECONDE, et sous DOS...)

[gasche]

Non mais justement la distance de levenshtein n'est pas forcément un bon indicateur, parce qu'elle suppose que toutes les modifications se valent. En pratique il est assez probable que certaines modifications soient plus importantes que d'autres, du point de vue de la sensibilité à l'erreur : par exemple une modification au sein d'un commentaire n'a pas grand intérêt. Il est possible que ce modèle simple donne tout de même de bons résultat, mais on pourrait aussi avoir besoin de quelque chose de plus fin pour obtenir des résultats significatifs.

On pourrait partir sur des idées plus compliquées comme "la distance de levensthein moyenne entre deux productions de la grammaire", mais ça devient carrément plus difficile à mettre en place.

Je ne pense pas non plus que les préfixes soient très pertinents ici. On a par exemple "else" et "elsif/elif", "and" et "andthen", "for" et "foreach", et il me semble que ça ne nuit pas à la lisibilité, ni n'augmente la probabilité d'erreurs d'innatention.

[Mac LAK]

Il est possible que ce modèle simple donne tout de même de bons résultat, mais on pourrait aussi avoir besoin de quelque chose de plus fin pour obtenir des résultats significatifs.

Heu... Cela ne s'applique qu'aux éléments du langage lui-même, pas au contenu d'un fichier source !
Donc, pas de distance à calculer sur les commentaires, les noms de variables/fonctions définies par le programmeur (s'il est assez con pour appeler ses variables "I10OlII" ou "aaaaaaaa", faut le piquer direct, et non pas modifier le langage...), mais bien uniquement sur les éléments syntaxiques eux-mêmes.

Ensuite, ce n'est qu'un indicateur : si deux mots-clés ont une distance de 1, déjà, c'est mauvais en soi... Si en plus tu rapproches les modifications correspondantes par rapport à la disposition des signes sur le clavier (distance "euclidienne", sur les touches), tu arrives à déterminer les éléments réellement "dangereux" des éléments "inoffensifs". Par exemple, la distance entre "Or" et "Xor" est de 1, mais le "X" est très éloigné du "O" sur le clavier.

Pour moi, les distances très courtes devraient être limitées à des signes, du genre affectation / comparaison, et de préférence en utilisant des caractères "éloignés" les uns des autres sur un clavier... Bien sûr, il se pose la question des différents claviers existants, qui peut devenir un vrai casse-tête.

On pourrait partir sur des idées plus compliquées comme "la distance de levensthein moyenne entre deux productions de la grammaire", mais ça devient carrément plus difficile à mettre en place.

D'un autre côté, ça n'arrive que lorsque l'on crée la grammaire du langage... Opération qui n'arrive pas non plus toutes les dix minutes.

Je ne pense pas non plus que les préfixes soient très pertinents ici. On a par exemple "else" et "elsif/elif", "and" et "andthen", "for" et "foreach", et il me semble que ça ne nuit pas à la lisibilité, ni n'augmente la probabilité d'erreurs d'innatention.

Les suites de "elsif/elif" sont immondes à lire : c'est vraiment "comment faire un "switch" encore plus hideux ?"... Franchement, ce genre de trucs, c'est tout sauf lisible, je préfère avoir un "switch" plus bourrin (et éventuellement traduit lourdement si on le fait sur des structures complexes) que des "elsif/elif". Bien sûr, cela demande un support natif des comparaisons de chaînes / structures, mais ça reste possible... Quitte à devoir surcharger un opérateur pour utiliser un type complexe dans un "switch" !
Idem pour le "And" / "AndThen" : trop facile de "louper" le "Then" sur une expression longue, or c'est justement dans ce genre de cas que l'on utilise un "AndThen"...

Reste le "For"/"ForEach" : c'est "moins pire", car ce n'est pas perdu au milieu d'une ligne (c'est en général au début si l'on ne fait pas du boulot de porc), mais ça reste douteux. Remplacer le "ForEach" par un "Iterate" (même nombre de caractères, en plus) me semblerait déjà bien mieux.

Il ne faut pas oublier que nombre d'IDE permette la complétion semi-automatique : avoir des mots-clés avec le même préfixe, c'est potentiellement une erreur lors de la complétion, et parfois pénible à retrouver...

[nicolofontana12]

La beauté, la coordonnance de la syntaxe! ca me rappelle de mon vieux professeur de C++