Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.
OK mais tout ceci n'est pas à strictement parler un problème de syntaxe. Cela tient plutôt à la manière dont ces deux langages gèrent le polymorphisme, le typage, etc. Ce n'est pas quelque chose qui peut s'améliorer en changeant uniquement la syntaxe (ie. la représentation en chaîne de caractères du programme), ça a aussi à voir avec toute la sémantique du langage.
Effectivement, si OCaml avait des type classes comme Haskell, cela permettrait une syntaxe plus légère. Mais il ne faut pas se focaliser sur la syntaxe actuelle comme si les concepteurs l'avait voulue exactement ainsi, qu'ils se fichent des aspects pratiques, etc. Les aspects problèmatiques de la syntaxe sont surtout des conséquences d'autres limitations du langage plutôt que erreurs de conception. (AMHA)
- il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité.
mais ... c'est comme ça dans tous les langages. C'est comme si tu nous faisait un vélo parce qu'en C, pour parser les expression arithmétiques genre 2 + 4 * 5 parfois il faut des parenthèses et parfois on peut les omettre. Les différentes règles de la grammaire ont des priorités, si ça ne correspond pas à ce que tu veux, il faut rajouter les parenthèses ... c'est tout.
Par exemple, l'opérateur produit pour les types * à une priorité plus faible que l'application, du coup string * string list est parsé comme string * (string list) ; si tu veux une liste de paires de string, il faut l'écrire (string * string) list. C'est le même principe que pour les expressions arithmétiques : tu retiens les priorités des opérateurs les plus courants et sinon tu mets des parenthèses. Je vois pas trop ce qu'on peut reprocher à OCaml sur ce point.
Autre exemple: l'expression if/then/else. Quand on écrit if e1 then e2 ; e3, l'expression e3 n'est pas dans la branche then, elle est au même niveau que le if ; il faut mettre des parenthèses (ou un begin/end) si on veut obtenir la séquence e2 ; e3 dans le then. Mais c'est à peu près le même comportement qu'en C avec if (cond) i1; i2;: il faut des {} pour regrouper i1 et i2.
Je n'ai pas pour but de démolir OCaml.
... et je ne prétends pas que OCaml soit sans défaut. Comme souvent c'est une question de compromis : la syntaxe n'est sans doute pas la meilleure qui soit mais les autres atouts du langage en valent largement la peine.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par Vivi . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 1.
OK mais tout ceci n'est pas à strictement parler un problème de syntaxe. Cela tient plutôt à la manière dont ces deux langages gèrent le polymorphisme, le typage, etc. Ce n'est pas quelque chose qui peut s'améliorer en changeant uniquement la syntaxe (ie. la représentation en chaîne de caractères du programme), ça a aussi à voir avec toute la sémantique du langage.
Effectivement, si OCaml avait des type classes comme Haskell, cela permettrait une syntaxe plus légère. Mais il ne faut pas se focaliser sur la syntaxe actuelle comme si les concepteurs l'avait voulue exactement ainsi, qu'ils se fichent des aspects pratiques, etc. Les aspects problèmatiques de la syntaxe sont surtout des conséquences d'autres limitations du langage plutôt que erreurs de conception. (AMHA)
mais ... c'est comme ça dans tous les langages. C'est comme si tu nous faisait un vélo parce qu'en C, pour parser les expression arithmétiques genre 2 + 4 * 5 parfois il faut des parenthèses et parfois on peut les omettre. Les différentes règles de la grammaire ont des priorités, si ça ne correspond pas à ce que tu veux, il faut rajouter les parenthèses ... c'est tout.
Par exemple, l'opérateur produit pour les types * à une priorité plus faible que l'application, du coup string * string list est parsé comme string * (string list) ; si tu veux une liste de paires de string, il faut l'écrire (string * string) list. C'est le même principe que pour les expressions arithmétiques : tu retiens les priorités des opérateurs les plus courants et sinon tu mets des parenthèses. Je vois pas trop ce qu'on peut reprocher à OCaml sur ce point.
Autre exemple: l'expression if/then/else. Quand on écrit if e1 then e2 ; e3, l'expression e3 n'est pas dans la branche then, elle est au même niveau que le if ; il faut mettre des parenthèses (ou un begin/end) si on veut obtenir la séquence e2 ; e3 dans le then. Mais c'est à peu près le même comportement qu'en C avec if (cond) i1; i2;: il faut des {} pour regrouper i1 et i2.
... et je ne prétends pas que OCaml soit sans défaut. Comme souvent c'est une question de compromis : la syntaxe n'est sans doute pas la meilleure qui soit mais les autres atouts du langage en valent largement la peine.