Je suis d'accord sur le principe mais dans le cas d'Erlang, c'est en fait justifié : la syntaxe d'Erlang est *vraiment* mauvaise.
La syntaxe d'Erlang est, pour des raisons historiques, inspirée de la syntaxe de Prolog. Le problème c'est que la sémantique de l'Erlang moderne ne correspond pas du tout à celle de Prolog, et que des choses qui étaient donc très bien pour Prolog sont des problèmes pour Erlang.
D'habitude les critiques qu'on peut faire sur une syntaxe sont... purement syntaxiques (il y a une ambiguïté à tel niveau, etc..), donc fondamentalement peu importantes. Mais dans le cas d'Erlang il y a de vrais problèmes sémantiques bêtement liés à la syntaxe, comme par exemple :
- impossibilité de définir des fonctions locales récursives
- impossibilité d'avoir des patterns linéaires. L'interprétation de la clause de filtrage "X => ..." dépend donc complètement de l'environnement : si X est défini, c'est un test d'égalité, sinon c'est un motif universel. Ça rend tout raisonnement équationnel (et donc la plupart des manipulations de code) difficile.
Le deuxième point est par ailleurs corrigé par Reia, qui propose (ou proposait la dernière fois que j'ai regardé) deux syntaxes pour les patterns, une linéaire (une variable est toujours un motif universel) et une non-linéaire.
[^] # Re: Erlang
Posté par gasche . En réponse à la dépêche Apprendre un langage de programmation par an. Évalué à 8.
La syntaxe d'Erlang est, pour des raisons historiques, inspirée de la syntaxe de Prolog. Le problème c'est que la sémantique de l'Erlang moderne ne correspond pas du tout à celle de Prolog, et que des choses qui étaient donc très bien pour Prolog sont des problèmes pour Erlang.
D'habitude les critiques qu'on peut faire sur une syntaxe sont... purement syntaxiques (il y a une ambiguïté à tel niveau, etc..), donc fondamentalement peu importantes. Mais dans le cas d'Erlang il y a de vrais problèmes sémantiques bêtement liés à la syntaxe, comme par exemple :
- impossibilité de définir des fonctions locales récursives
- impossibilité d'avoir des patterns linéaires. L'interprétation de la clause de filtrage "X => ..." dépend donc complètement de l'environnement : si X est défini, c'est un test d'égalité, sinon c'est un motif universel. Ça rend tout raisonnement équationnel (et donc la plupart des manipulations de code) difficile.
Le deuxième point est par ailleurs corrigé par Reia, qui propose (ou proposait la dernière fois que j'ai regardé) deux syntaxes pour les patterns, une linéaire (une variable est toujours un motif universel) et une non-linéaire.