Elixir, enfin une syntaxe agréable pour Erlang ?

Posté par Bruno Michel (site web personnel) le 26 mars 2011 à 08:13. Édité par Benoît Sibaud. Modéré par Florent Zara. Licence CC By‑SA.

Étiquettes :

mar.

2011

Elixir est un langage de programmation qui s’appuie sur Erlang et sous licence MIT. Il propose une syntaxe agréable, inspirée de celle de Ruby, et un modèle objet à base de prototypes.

Erlang est un langage fonctionnel avec un typage dynamique, une évaluation stricte et une assignation unique. Il convient bien pour des applications distribuées, résistantes aux erreurs et sans arrêt grâce au mécanisme de rechargement à chaud. Mais c’est également un langage qui peut sembler difficile à apprendre et dont la syntaxe peut rebuter. Elixir propose une manière élégante de profiter des avantages d’Erlang. Il est notamment possible d’appeler des modules Erlang sans conversion des types de données, et donc sans impact sur les performances.

Elixir est encore très jeune et recherche des contributeurs pour aider au développement de sa bibliothèque standard. Pour installer Elixir, vous aurez besoin d’Erlang R14B01, et je vous invite à parcourir le README pour découvrir ce langage. Mais voici un avant-goût sous la forme d’un très classique « Hello World » :

module World
  def say_hello
    IO.puts "Hello World!"
  end
end

World.say_hello

Aller plus loin

Elixir sur github (224 clics)
Un screencast de présentation d’Elixir (190 clics)
Pourquoi les rubyistes devraient essayer Elixir ? (222 clics)
DLFP : Reia, un autre langage au‑dessus d’Erlang (235 clics)

# Dommage pour les variables de motifs

Posté par gasche le 26 mars 2011 à 11:22. Évalué à 3.

Reia corrigeait ce qui est à mes yeux un des plus gros problèmes de syntaxe de Erlang, l'impossibilité d'avoir des variables toujours liantes dans les motifs (cf. cette discussion). Elixir ne fait rien à ce niveau, ce que je trouve dommage.
- [^] # Re: Dommage pour les variables de motifs
  
  Posté par gasche le 27 mars 2011 à 15:42. Évalué à 2.
  
  Réponse à soi-même : la situation pourrait changer puisque l'auteur a l'air d'accord pour changer les choses à ce niveau.
# Ruby ?

Posté par gUI (Mastodon) le 26 mars 2011 à 13:27. Évalué à -1.

C'est moi ou la syntaxe est calquée sur le Ruby ? Notez que aimant bcp le Ruby c'est pas fait pour me déranger...

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
- [^] # Re: Ruby ?
  
  Posté par Bruno Michel (site web personnel) le 26 mars 2011 à 13:41. Évalué à 5.
  
  Oui, la syntaxe est fortement inspirée de Ruby. C'est d'ailleurs marqué au début de la dépêche :
  
  Il propose une syntaxe agréable, inspirée de celle de Ruby
  
  Et ce n'est pas étonnant, José Valim, le créateur d'Elixir, est un membre de la core team de Ruby on Rails.
  - [^] # Re: Ruby ?
    
    Posté par Firwen (site web personnel) le 26 mars 2011 à 14:19. Évalué à 2.
    
    associer la syntaxe de Ruby à la puissance de la prog par prototype de Self/Lua, ça parait appétissant.
# Pour ceux qui ne sauraient pas ...

Posté par lasher le 26 mars 2011 à 21:13. Évalué à 3.

Dans un langage de programmation, avoir une « évaluation stricte » signifie qu'on évalue les arguments d'une fonction sous forme de recherche en profondeur et de gauche à droite dans l'arbre d'appel des fonctions. C'est-à-dire: les arguments d'une fonction sont toujours évalués de gauche à droite, récursivement jusqu'à avoir évalué tous les arguments de toutes les fonctions nécessaires à l'appel de la fonction initiale.
- [^] # Re: Pour ceux qui ne sauraient pas ...
  
  Posté par MrLapinot (site web personnel) le 28 mars 2011 à 00:22. Évalué à 3.
  
  Non, évaluation stricte veut juste dire que les arguments sont évalués avant l'appel de la fonction. L'ordre n'a rien à voir.
  
  Par exemple, OCaml a une évaluation stricte de droite à gauche (sauf pour && et ||).
  - [^] # Re: Pour ceux qui ne sauraient pas ...
    
    Posté par lasher le 28 mars 2011 à 03:38. Évalué à 3.
    
    Oups, tu as raison, d'après Wikipedia:
    
    Applicative order (or leftmost innermost) evaluation refers to an evaluation strategy in which the arguments of a function are evaluated from left to right in a post-order traversal of reducible expressions (redexes). Unlike call-by-value, applicative order evaluation reduces terms within a function body as much as possible before the function is applied.
    
    Donc « strict » : qui évalue l'intégralité des paramètres avant d'exécuter la fonction; « ordre applicatif » (traduction pifométrique): qui évalue de gauche à droite.
    
    En fait je crois que j'ai confondu avec certains qui parlent de « fully strict » pour parler de « applicative order ».
    - [^] # Re: Pour ceux qui ne sauraient pas ...
      
      Posté par gasche le 28 mars 2011 à 09:54. Évalué à 1.
      Il y a une différence très importante entre les stratégies qui évaluent sous les lambdas/fonctions et celles qui ne le font pas. Les langages de programmation ne le font, dans l'écrasante majorité des cas, pas. Donc quand on dit "strict de gauche à droite" on veut dire qu'on évalue la fonction jusqu'à un lambda, mais pas en dessous, et ensuite les arguments de gauche à droite. Ce n'est pas la même chose que "applicative order" (qui réduit sous les lambdas). Je ne connais pas la terminologie "fully strict".
      
      Par exemple, le programme OCaml suivant :
      
      let make_counter () = let count = ref (-1) in fun () -> (incr count; !count)
      
      N'a aucun sens en "applicative order", puisqu'il renvoie toujours 0.
# Si surcouche de langage nécessaire, changer de langage ?

Posté par Ludo le 27 mars 2011 à 11:02. Évalué à 3.

Y'a que moi que ça dérange qu'on parle d'une surcouche pour un langage, car trop difficile à apprendre?

Déjà que je trouve que l'API de PHP est une catastrophe, ce qui est confirmé par les nombreuses surcouches que doivent faire les différents frameworks (ZF, Drupal...), mais là, c'est carrément la syntaxe même du langage.

Quelqu'un peut m'expliquer pourquoi ils n'ont pas fait une syntaxe simple directement? Je pensais que la manière de fonctionner d'Erlang imposait cette logique?
- [^] # Re: Si surcouche de langage nécessaire, changer de langage ?
  
  Posté par gasche le 27 mars 2011 à 11:19. Évalué à 7.
  
  La syntaxe de Erlang a quelques défauts qu'on peut expliquer par son évolution historique en partant de celle de Prolog. Cependant, les gens qui disent "la syntaxe Erlang est trop difficile à apprendre" sont des flemmard-e-s qui n'ont pas essayé de coder en Erlang plus de quelques heures d'affilée.
  
  Si on s'intéresse au langage Erlang, la syntaxe ne pose absolument pas problème, et le langage n'est pas spécialement difficile à apprendre (d'ailleurs il existe cet excellent livre de Joe Armstrong, dont la première partie (PDF) est disponible en ligne).
  
  Le coup de la syntaxe facile c'est un argument marketing pour faire plaisir aux rubyistes, pas une raison de fond. La réalité c'est juste que c'est le projet "for fun" d'un gars qui connaît très bien Ruby et un peu Erlang, et qui avait envie de voir ce que ça donnait, un mélange des deux. Il n'y a pas à chercher plus loin.
- [^] # Re: Si surcouche de langage nécessaire, changer de langage ?
  
  Posté par reno le 27 mars 2011 à 12:22. Évalué à 5.
  
  Bah, tu pars d'un présupposé faux alors forcément ta question n'a pas grand intérêt..
  
  Personne n'a dit que la syntaxe d'Erlang était trop difficile à apprendre, par contre qu'elle soit ne soit pas très agréable à utiliser/lire, ça oui..
  
  Saisis-tu la différence?
  
  Quelqu'un peut m'expliquer pourquoi ils n'ont pas fait une syntaxe simple directement?
  
  Probablement qu'ils se sont focalisés sur la sémantique plutôt que la syntaxe, et puis Erlang est un langage très vieux: les goûts des programmeurs ont évolués depuis..
  - [^] # Re: Si surcouche de langage nécessaire, changer de langage ?
    
    Posté par gasche le 27 mars 2011 à 15:35. Évalué à 2.
    
    Je ne comprends pas en quoi la syntaxe Erlang serait moins agréable à utiliser que la syntaxe Ruby. Elles sont différentes, et clairement une personne habituée à l'une des deux va la préférer par familiarité, mais je ne vois rien qui ne puisse devenir "agréable" après un moment d'acclimatation. Est-ce qu'il y a des points objectifs qui te font dire que la syntaxe de Ruby est "plus agréable" (il faut justifier en quoi) que la syntaxe Erlang ?
    
    Les deux défauts que j'ai cité dans mon premier message sont en fait des soucis au niveau de la syntaxe abstraite : il y a des choses qu'on ne peut simplement pas écrire, sous la forme Erlang tout comme sous la forme Ruby; je n'ai aucun jugement particulier sur la syntaxe concrète (choix des signes de ponctuation, des conventions lexicales, des mots-clés, etc.).
    - [^] # Re: Si surcouche de langage nécessaire, changer de langage ?
      
      Posté par cho7 (site web personnel) le 28 mars 2011 à 15:46. Évalué à 2.
      tout pareil. ce qui pourrait me rebuter le plus dans Erlang, c'est que c'est du fonctionnel. Autrement, je ne le trouve pas spécialement compliqué ce langage, bien au contraire.
      
      En quelques lignes de code on peut par exemple implémenter un serveur et son client, je ne sais pas ce qu'il vous faut !
      
      coté client:
      serveur ! {hello, self()}.
      
      coté serveur:
      receive
      
      {hello, From} -> From ! {ok, hello}; Other -> From ! {ko, unknown_command}
      
      end.
      
      Sérieux, c'est compliqué ? Moi je trouve ça super sexy en fait :)
    - [^] # Re: Si surcouche de langage nécessaire, changer de langage ?
      
      Posté par reno le 28 mars 2011 à 23:21. Évalué à 4.
      Est-ce qu'il y a des points objectifs qui te font dire que la syntaxe de Ruby est "plus agréable" (il faut justifier en quoi) que la syntaxe Erlang ?
      
      Non, c'est juste un problème de familiarité.
      Mais je pense que cela peut suffire pour rebuter des utilisateurs potentiel d'Erlang.
      
      Est-ce que tu te rends compte qu'il y a des améliorations objectives des langages qui ne sont pas utilisés pour des raisons de familiarité?
      Exemples:
      
      l'indentation "a la Python" est un progrès objectif sur l'indentation "a la C": un professeur a enseigné a plusieurs classes un langage en changeant juste l'indentation: il a trouvé que les élèves apprenaient plus facilement le langage dans sa variante "indentation a la Python", elle est pourtant peu utilisée..
      
      CamelCase vs mots_séparer_par_des_souligner: on pourrait mesurer le temps de lecture et la compréhension d'un texte en CamelCase et en souligner, je veux bien parier que les souligner gagneraient, mais c'est pourtant le CamelCase qui est utilisé.
      
      Donc avoir une syntaxe agréable/familière, c'est important! Pour faire de la programmation concurrente, je pense que la syntaxe peut faire pencher la balance en faveur de Scala (par exemple) par rapport a Erlang..
      - [^] # Re: Si surcouche de langage nécessaire, changer de langage ?
        
        Posté par gasche le 29 mars 2011 à 01:03. Évalué à 0.
        
        Honnêtement, je l'ai déjà dit mais je pense que n'importe quelle syntaxe pensée pour être vaguement utilisable peut être apprise en quelques heures/jours de pratique. Alors oui, une syntaxe familière ça fait baisser un peu la barrière d'adoption, mais les gens qui ont deux sous de jugeote devraient savoir passer outre et faire un effort, si le langage derrière en vaut la chandelle.
# Erlang, c'est facile

Posté par Rémi Birot-Delrue le 28 mars 2011 à 17:47. Évalué à 1.

Tu dis :

Mais c’est également un langage qui peut sembler difficile à apprendre et dont la syntaxe peut rebuter.

Donc je veux juste appuyer sur le fait que même si Erlang peut /sembler/ difficile à apprendre, ce n'est pas du tout le cas. Voilà >o/
# L'avis d'un ignorant de Ruby

Posté par qetdem le 28 mars 2011 à 17:59. É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é?
- [^] # Re: L'avis d'un ignorant de Ruby
  
  Posté par MrLapinot (site web personnel) le 28 mars 2011 à 18:43. Évalué à 4.
  Le problème, ce n'est pas l'assignation de variable au cours d'un pattern-matching (c'est ce qu'on en attend couramment), c'est au contraire la « non-assignation » quand la variable existe déjà.
  
  Dans les autres langages avec pattern-matching, on utilise des gardes :
```
match x with
| Some y when x = y -> ...
| _ -> ...
```
  par exemple en OCaml.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.