qetdem a écrit 1 commentaire

  • # L'avis d'un ignorant de Ruby

    Posté par  . En réponse à la dépêche Elixir, enfin une syntaxe agréable pour Erlang ?. Évalué à 2.

    Bonjour,
    Je me permet de laisser mon avis sur le sujet, en précisant que je ne connais rien au Ruby qui aurait inspiré cet Elixir :o)

    Avant d'utiliser Erlang, j'ai programmé avec quelques vieux langages - Fortran, C, C++, Java. Je me suis intéressé à Erlang pour sa capacité à gérer le multiprocess et surtout le multicpu.
    J'ai bien sur été un peu dérouté par les concepts amenés par ce langage, et je suis tombé sur les 2 sujets que j'ai relevé dans cette discussion:
    + Assignation/pattern matching/test + non récursivité d'un fun

    Pour le premier point, je pense qu'il faut considérer que tous ces cas sont identiques: Erlang fait du pattern matching. Et en cas de succès, il assigne les variables non encore définies. La seule différence est le comportement en cas d'échec (erreur ou passage au test suivant). Pour ma par je trouve très pratique et très lisible l'affectation de variable à l'intérieur d'un test (pour le décodage de trame par exemple).

    Le second point ne m'a gêné que parce qu'il impose des limites dans le shell. J'aimerais parfois, pour faciliter le test d'une fonction, pouvoir générer une donnée à partir d'une fonction récursive. Ce n'est pas possible. Par contre je n'ai pas été gêné par cette contrainte dans l'écriture du code. J'utilise le code récursif dans 2 cas principalement: + créer un process rémanent, à proscrire dans une déclaration fun, je crois d'ailleurs que ce point à lui seul justifie le choix d'implémentation. + parcourir une structure de donnée (module lists, gb_trees, mon_module ...) et le lists:reverse(L) est légal dans une déclaration fun.

    Tout ça pour dire que la syntaxe d'Elang ne me gêne plus du tout, je la trouve très performante, même si elle demande un effort certain d'apprentissage. J'apprécie particulièrement: + le nombre de mots clés réduit, + le nombre de constructions réduit, + la quasi obligation d'écrire des fonctions courtes + le pattern matching avec affectation + et bien sur le fait que le langage soit fonctionnel, avec très peu d'effet de bord.

    Si on combine cela à la structure des applications "imposées" par l'OTP, à l'utilisation de modèle comportementaux, à l'utilisation de plus en plus fréquente des "spec", à la philosophie du let it crash, je trouve la plupart des modules et applications Erlang très lisibles.

    Il y a certainement un intérêt à apporté un modèle objet s'appuyant sur Erlang et sa VM. Pour certains problèmes la représentation en objet est devenu naturelle; le portage en Erlang de vxWidgets en est un exemple, même si la syntaxe est restée de l'Erlang, on y retrouve la faune d'origine. Alors pourquoi pas une véritable syntaxe objet capable de généré du code fonctionnel lui assurant de la robustesse et de la flexibilité?