Découvrons un nouveau langage : Elm. Celui-ci vise à rendre accessible la programmation fonctionnelle pour les développeurs Web. JavaScript a ses qualités et ses défauts ; il est parfois intéressant d'aller voir ailleurs pour mieux les comprendre. Même si vous ne comptez pas utiliser Elm plus tard, cela reste intéressant car il vous permettra de découvrir de nouvelles façons de faire et vous permettra de devenir un meilleur développeur. D'ailleurs, on peut noter que de nombreuses bibliothèques JavaScript, comme Redux, annoncent clairement s'être inspirées d'Elm.
Elm a été créé dans le but d'apporter fiabilité et maintenance simplifiée aux applications JavaScript dans les navigateurs. Son créateur, Evan Czaplicki s'est donc naturellement inspiré des langages fonctionnels, qui sont conçus justement pour avoir ces caractéristiques. En utilisant la bibliothèque JavaScript virtual-dom, il s'est également assuré que les performances soient au niveau des principaux frameworks.
Why Elm is awesome! - Garrett Rivera
Personnellement, je code sous vim avec le plugin Elm-vim et j'utilise Elm-format pour que mon code soit formaté d'une manière gracieuse. Mais pour essayer Elm tout au long de cet article, je vous conseille l'éditeur en ligne.
Commençons par un Hello World :
import Html exposing (text)
main =
text "Hello, World!"Dans l'éditeur en ligne, "Hello, World!" devrait s'afficher tout de suite. Ailleurs, il va falloir convertir le code Elm en code JavaScript, puis exécuter celui-ci.
La première ligne importe le module Html et expose la fonction text. Celle-ci pourra être appelée directement, sans avoir besoin de préciser le namespace d'où elle vient. Ensuite, on déclare la fonction main. Cette fonction ne prend pas de paramètre et renvoie un élément Html, en l'occurrence le texte "Hello, World!".
Elm est un langage fortement typé. Il est recommandé de déclarer le type des méthodes pour détecter plus facilement les erreurs. Mais, pour le moment, nous allons nous reposer sur l'inférence de type d'Elm et laisser ça pour plus tard. Voyons plutôt comment utiliser notre code en dehors de l'éditeur en ligne.
Pour ça, il nous faut tout d'abord installer le paquet Html et ses dépendances. Lançons elm-package pour faire ça :
$ elm-package install evancz/elm-html
To install evancz/elm-html I would like to add the following
dependency to elm-package.json:
"evancz/elm-html": "4.0.2 <= v < 5.0.0"
May I add that to elm-package.json for you? (y/n) y
Some new packages are needed. Here is the upgrade plan.
Install:
elm-lang/core 3.0.0
evancz/elm-html 4.0.2
evancz/virtual-dom 2.1.0
Do you approve of this plan? (y/n) y
Downloading elm-lang/core
Downloading evancz/elm-html
Downloading evancz/virtual-dom
Packages configured successfully!Les outils pour Elm expliquent bien ce qu'ils font et ont des comportements par défaut qui sont pratiques. Cela les rend agréables à utiliser. Si seulement les développeurs JS d'outils comme Babel pouvaient s'en inspirer !
On peut ensuite compiler son fichier elm en fichier html, avec elm-make :
$ elm-make main.elm
Success! Compiled 37 modules.
Successfully generated index.htmlOn peut aussi générer un fichier JavaScript et écrire soi-même le fichier HTML :
$ elm-make main.elm --output main.js
Success! Compiled 1 modules.
Successfully generated main.jsLa compilation est plus rapide la deuxième fois car les modules, et notamment core, ont été mis en cache. Cela explique aussi pourquoi le nombre de modules compilés est plus faible.
Voyons maintenant un autre exemple, un peu plus compliqué :
import Graphics.Element exposing (show)
length : List a -> Int
length list =
case list of
[] ->
0
first :: rest ->
1 + length rest
main =
show (length [1..9])Ici, la fonction main génère une liste avec 9 éléments, de 1 à 9, puis calcule la longueur de cette liste et l'affiche sous forme de texte brut. Ce qui est intéressant dans cet exemple est la définition de la fonction length. Cette définition commence avec la déclaration de la signature de la fonction :
length : List a -> IntLa signature est la partie après les :. Elle indique que la fonction prend un paramètre, qui est une liste, et retourne un entier (Int). Le a de List a indique que la liste peut être de n'importe quel type. On peut alors réutiliser a pour indiquer le même type dans la signature. Par exemple, la fonction reverse, qui inverse une liste a pour signature :
reverse : List a -> List aLes éléments de la liste en paramètre de reverse et ceux de la liste retournée sont du même type.
Ensuite, l'implémentation de la fonction length considère plusieurs cas, grâce au mot-clé case of. Le premier cas est celui d'une liste vide. On retourne alors 0. Le deuxième cas fait appel à la récurrence. On prend le premier élément de la liste (first) et le reste (rest) et on dit que la longueur de la liste est un de plus que la longueur de la liste sans le premier élément.
Ainsi, les types peuvent servir à deux choses : détecter des erreurs, mais aussi aider à les corriger. En effet, le compilateur a été pensé pour être un assistant. Ces messages d’erreur ne sont pas juste là pour dire que quelque chose ne va pas, ils vont plus loin. Si vous faites une typo et inversez deux caractères, le compilateur va souvent vous suggérer la bonne version.
Il est même possible d'apprendre de nouvelles choses sur le langage via le compilateur. Par exemple, si vous écrivez ce bout de code :
type alias Repository =
{ version : String
, name : String
}
showVersion : Repository -> String
showVersion repository =
"Version: " + repository.versionLe compilateur va dire que l'on ne peut pas utiliser + pour concaténer des chaînes de caractères, mais que ++ permet de faire ça. Et il donne un lien pour en savoir plus :
-- TYPE MISMATCH ------------------------------------------------ Repository.elm
The left argument of (+) is causing a type mismatch.
12│ "Version: " + repository.version
^^^^^^^^^^^
(+) is expecting the left argument to be a:
number
But the left argument is:
String
Hint: To append strings in Elm, you need to use the (++) operator, not (+).
<http://package.elm-lang.org/packages/elm-lang/core/latest/Basics#++>
Detected errors in 1 module.Un autre exemple intéressant est la manipulation d'arbres binaires :
type Tree a
= Empty
| Node a (Tree a) (Tree a)
empty : Tree a
empty =
Empty
singleton : a -> Tree a
singleton v =
Node v Empty Empty
insert : comparable -> Tree comparable -> Tree comparable
insert x tree =
case tree of
Empty ->
singleton x
Node y left right ->
if x > y then
Node y left (insert x right)
else if x < y then
Node y (insert x left) right
else
tree
fromList : List comparable -> Tree comparable
fromList xs =
List.foldl insert empty xsSans détailler tout le code, on peut noter qu'il est facile de décrire la structure d'un arbre : soit l'arbre est vide, soit c'est un nœud avec une valeur associée de type a et 2 sous-arbres du même type (que l'on nomme généralement left et right). Cette structure est récursive et il donc logique que l'on retrouve des fonctions récursives pour la manipuler, comme insert.
Le côté programmation fonctionnelle ressort également de manière assez marquée dans cet exemple, que ce soit pour la ligne List.foldl insert empty xs, qui peut sembler magique à première vue, mais que l'on apprend rapidement à maîtriser, ou dans la signature de la fonction insert. C'est une fonction qui prend 2 arguments, un élément et un arbre, et retourne un nouvel arbre. Mais on peut aussi voir ça comme une fonction qui prend un élément et qui va retourner une fonction qui modifie un arbre en un nouvel arbre. Bien sûr, si on appelle la fonction avec 2 arguments, un élément et un arbre compatible, cela fait la même chose : renvoyer un nouvel arbre avec l'élément inséré. Mais on peut aussi s'en servir avec un seul paramètre pour créer une fonction intermédiaire :
insertZero : Tree Int -> Tree Int
insertZero =
insert 0
aListOfTrees =
[ fromList [1, 2, 3]
, fromList [4, 5, 6]
, fromList [7, 8, 9]
]
anotherList = List.map insertZero aListOfTreesLa programmation fonctionnelle fait partie des gènes d'Elm. C'est déroutant au début, mais ça se révèle être un outil très puissant par la suite, tout particulièrement quand on le combine avec le côté programmation réactive d'Elm.
En effet, Elm propose d'organiser son code d'une certaine façon, en séparant la logique en 3 parties :
- model
- update
- view
Cela revient à partir de ce squelette et l'enrichir au fur et à mesure :
-- MODEL
type alias Model = { ... }
-- UPDATE
type Action = NoOp | ...
update : Action -> Model -> Model
update action model =
case action of
NoOp ->
action
...
-- VIEW
view : Model -> Html
view =
...Pour aller plus loin (et j’espère que cet article vous en aura donné l’envie), je vous conseille la lecture de The Elm Architecture. Vous pouvez aussi lire le code de elm-peer-tweet, une implémentation en Elm de PeerTweet, un réseau social distribué qui s’appuie sur les DHT de Bittorrent. Enfin, pour les Parisiens, vous pouvez rencontrer d’autres développeurs lors des Meetups Elm Paris.
Cette découverte du langage fait bien entendu l’impasse sur beaucoup de choses. J’aurais pu parler des outils qui offrent un certain gain de productivité (par exemple, elm-package s’assure que les modules respectent le semantic versioning en analysant la signature des fonctions) ou de l’interaction avec le JavaScript via les ports. Elm n’est pas parfait (pas encore, du moins) : le JavaScript généré est assez gros actuellement (il y a des travaux en cours sur le compilateur pour optimiser ça dans la prochaine version), certaines choses sont difficiles à faire (en général, ce qui implique des effets de bord), etc. Mais je ne saurais trop vous encourager à essayer par vous‐même !
P.‐S. : merci aux personnes qui ont relu cette dépêche pour en corriger les fautes et proposer des améliorations.
Aller plus loin
- Le site officiel d'Elm (639 clics)
- Evan Czaplicki - Let's be mainstream! (vidéo) (118 clics)
- Awesome Elm, compilation de liens (146 clics)
- Try Elm (148 clics)
- The Elm Architecture (138 clics)
- Et si JavaScript allait droit dans le mur ? (440 clics)
# Clojure
Posté par theor . Évalué à 7.
Merci pour cet article, je ne connaissais pas du tout.
Qu'apporte Elm, selon toi, par rapport à d'autres langages fonctionnels comme ClojureScript, qui s'interface lui aussi avec JS mais avec l'avantage de conserver la syntaxe du Lisp, qui plait à certains par sa confusion entre syntaxe et AST et par son ultra-minimalisme assez élégant.
Haskell, par exemple, mise sur les monades et le "tout est lambda", mais j'ai spontanément plus de mal à voir ce que Elm apporte de nouveaux en la matière. Après, je viens juste de découvrir… :-)
[^] # Re: Clojure
Posté par Anthony Jaguenaud . Évalué à 1.
Je me demande également, s’il ne serait pas possible de compiler du haskell en javascript ? On le fait bien avec du C++(voir la présentation).
[^] # Re: Clojure
Posté par Anthony Jaguenaud . Évalué à 2. Dernière modification le 22 avril 2016 à 10:28.
Je m’auto répond, il y a une page « The Javascript Problem » sur le wiki haskell. Ça parle notamment de haste.
Quelqu’un aurait déjà utilisé et pourrait nous aider à comparer avec elm ?
[^] # Re: Clojure
Posté par rogo . Évalué à 3.
À ma connaissance, l'état de l'art pour produire du code JavaScript à partir de Haskell est ghcjs. Comme son nom l'indique, la conversion se fait au niveau de l'API de GHC (Glascow Haskell Compiler, l'implémentation de référence du langage Haskell depuis bien longtemps, pour ceux qui ne connaîtraient pas l'écosystème de Haskell).
Il y a toutes sortes d'avantages par rapport aux méthodes qui tenaient la corde avant ghcjs, notamment haste et fay. L'un est que l'on écrit du code Haskell relativement classique, puisque la conversion en JS se fait à un niveau assez bas. Un autre est, paraît-il, la rapidité et la compatibilité. Mais je n'ai essayé que ghcjs.
Mon expérience est toutefois très limitée. J'avais essayé surtout par curiosité, et je n'avais pas été convaincu. J'avais l'impression de devoir écrire bien plus de code en Haskell que son équivalent JavaScript, avec des dizaines de modules et fonctions idoines à apprendre, pour un résultat (post-compilation) énorme et assez cryptique. En compensation, je bénéficiais des types algébriques et autres conforts fournis par Haskell. Pour être rentable, il aurait fallu avoir à écrire une grosse appli JS. C'était il y a un an, et ghcjs s'est sûrement amélioré. Pour voir à quoi ça ressemble, il y a les exemples officiels, notamment le helloworld (qui va bien au-delà de "hello, world!").
[^] # Re: Clojure
Posté par kantien . Évalué à 3.
Ça se fait avec du OCaml : js_fo_ocaml et le framework complet ocsigen permet faire une webapp en codant à la fois la partie client et serveur.
J'en avais parlé aux rédacteurs de la dépêche qui m'ont répondu que Elm ne fait que la partie client pour le moment, mais il y a un projet pour faire la partie serveur.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Clojure
Posté par Maclag . Évalué à 5.
Ocsigen, ça fait un petit moment que c'est là, et le moins qu'on puisse dire, c'est que ça ne fait pas énormément de bruit.
Quid des perfs, de la compacité du code, ou de la rapidité à obtenir quelque chose rapidement?
[^] # Re: Clojure
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Je ne connais pas bien du tout ClojureScript. A priori, je dirais que le gros avantage d'Elm est d'avoir été pensé dès le départ pour fonctionner dans les navigateurs.
J'imagine qu'un développeur Clojure ira naturellement vers ClojureScript mais un développeur JS ira plus facilement vers Elm. Ce n'est pas forcément lié au langage, mais plutôt à la communauté et aux outils. Le compilateur Elm s'installer via npm, fournit des messages d'erreur compréhensibles par le commun des mortels, on commence à voir pas mal de tutoriels pour aborder Elm en venant du JavaScript, etc.
D'autre part, Elm propose avec The Elm Architecture, elm-html et start-app une approche directe pour faire des single page apps. C'est un équivalent de React + Flux dans le monde Elm, mais en beaucoup plus simple grâce aux propriétés d'Elm (l'immutabilité et les signaux notamment). Il existe bien Om pour ClojureScript, mais j'ai l'impression que ça n'a pas vraiment pris.
Par rapport à Haskell, Elm apporte de la simplicité. En tant que langage, Haskell est clairement beaucoup plus puissant. Mais ça vient avec un coup : c'est beaucoup plus compliqué de "rentrer" dans le langage. Je ne vois pas les développeurs front adopter massivement Haskell dans les années qui viennent. Il y a trop de freins, que ce soit en terme de documentation, de communauté qui n'a pas les mêmes valeurs ou d'outils. Elm semble répondre à ces questions. Par exemple, je n'ai pas vu de tutoriel Elm qui commence par définir ce qu'est une monade. Ça ne veut pas dire que les concepteurs du langage ne connaissent pas ce concept, mais juste qu'ils préfèrent mettre en avant le côté pratique plus que le côté théorique. La vidéo "Let's be mainstream" dans les liens de l'article est assez parlante à ce sujet.
[^] # Re: Clojure
Posté par Guillaume Denry (site web personnel) . Évalué à 3. Dernière modification le 22 avril 2016 à 12:50.
Tu as parfaitement raison d'insister sur ce point, la grande force de Elm, au delà de ce qu'il propose techniquement (le langage et le "toolbelt" autour), c'est l'angle choisi par ses promoteurs (*) pour en parler. Ayant essentiellement un profil de programmeur "impératif/procédural", je suis rentré dedans avec plaisir.
(*) je pense à Evancz bien sûr, mais aussi à Richard Feldman qui fait un formidable boulot d'évangélisation en s'appuyant régulièrement sur l'avancée de l'adoption de Elm par NoRedInk (la société dans laquelle il travaille)
[^] # Re: Clojure
Posté par barmic . Évalué à 4.
C'est ce qui m'a manqué dans la dépêche. Parler du langage c'est bien, mais si l'objectif c'est de remplacer JS il n'est pas possible de faire l'impasse sur la (ou les) manière(s) de gérer les vues. Une approche déclarative à la Angular ? De la manipulation direct de DOM comme avec JQuery ? De la création de composants comme React ? Et pour chacun ce qu'apporte Elm dans ces cas d'usages. Pour moi le JS reste un langage qui sert à dynamiser proprement une application web et le backend porte le gros de la charge et de l'intelligence.
L’interaction avec les bibliothèques existantes est aussi assez importante : comment gérer des choses comme 3Djs ou sockjs ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Clojure
Posté par barmic . Évalué à 3.
C'est d'ailleurs ce qui me fais ne pas trop m'intéresser aux transpilations entre les langages classiques et le JS (il y a aussi OPA qui essaie d'apporter vraiment quelque chose lié à la gestion du DOM).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Juste un langage ?
Posté par G.bleu (site web personnel) . Évalué à 2.
Merci beaucoup pour l'article, ça change d'avoir quelque chose de qualité posté un trolldi ;-)
Concernant Elm, je me pose la question de sa compatibilité avec le reste de l'écosystème javascript.
Par exemple dans la page vantant ses performances on peut voir que Elm est opposé à des frameworks web comme React, Angular plutôt qu'à d'autre "transpileurs" javascript (comme typescript ou coffeescript).
J'imagine que ça ne doit pas être simple de faire cohabiter des frameworks "mutables" avec un langage fonctionnel (ça doit être la fête à la monade…)
[^] # Re: Juste un langage ?
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Vu les différences fondamentales entre Elm et Javascript, j'ai plutôt l'impression que la philosophie, c'est de recréer tout un écosystème web autour de Elm en reléguant javascript à la portion congrue via les ports (et les bindings natifs dans certains cas). Autrement dit, utiliser ReactJs dans Elm, c'est pas pour demain, ni après-demain.
[^] # Re: Juste un langage ?
Posté par steph1978 . Évalué à 3.
Est-ce qu'à terme la cible ne sera pas de compiler vers du webassembly ?
# Référence
Posté par reynum (site web personnel) . Évalué à 6.
Moi j'ai juste peur que ce langage soit un gouffre en ressources et entraîne des batailles entre développeurs.
kentoc'h mervel eget bezan saotred
[^] # Re: Référence
Posté par Guillaume Denry (site web personnel) . Évalué à 5. Dernière modification le 22 avril 2016 à 14:55.
Des batailles dans la rue, la nuit, à coup de griffes.
[^] # Re: Référence
Posté par kantien . Évalué à 2.
Du genre pour régler des problèmes de droits de propriété intellectuelle sur une « bibliothèque » ridicule (comment peut on faire un paquet avec une seule fonction ???), alors que c'est de base dans le module String ? :-P
qui, ô surprise, génère l'arbre suivant (à tester ici):
Bon, là je taquine, mais apporter les bienfaits du fonctionnel fortement et statiquement typé à javascript est à mon avis une bonne chose (de base, ce langage est moisi).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# Nouveau
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Nouveau, nouveau, c'est vite dit. Elm existe depuis 2012. C'est plus récent que Swift (2014), et plus proche de Go (fin 2009) que d'aujourd'hui…
[^] # Re: Nouveau
Posté par Bruno Michel (site web personnel) . Évalué à 5. Dernière modification le 23 avril 2016 à 14:37.
C'est comparé des pommes et des oranges.
Non, pour le coup, le développement de Swift a commencé 2 ans avant celui d'Elm.
Ce n'est pas vrai si on parle du premier commit (qui me semble être la règle la plus juste). C'est vrai si on parle de première version publique.
Et Go et Swift restent des langages jeunes, comparés aux C, C++, Java, Python, PHP, Ruby, JavaScript, Perl qui ont tous plus de 20 ans d'existence.
# Yet another one
Posté par LouisB . Évalué à -3.
Tout ce à quoi je peux penser en voyant cet article, c'est ce strip de xkcd…
De plus,
je suis tout à fait pas d'accord. Ce qui fait un bon développeur, ce n'est pas la taille de la panoplie d'outils/méthodologies/paradigmes qu'il sait utiliser, mais la rapidité avec laquelle il s'acquitte d'une tâche (monnayant une certaine expertise).
Pour illustrer mon propos, je vous laisse regarder cette conférence de Kathy Sierra pour O'Reilly (l'éditeur de bouqins sur l'informatique). Pour les non-anglophones, je vais résumer par une question simple : quel est le meilleur développeur entre :
- celui qui sais écrire un bot twitter en [insérez votre langage préféré]
- celui qui sais écrire un bot twitter en C++, perl, python, smalltalk, ruby, javascript, scala, D, rust, swift et go
Spoiler réponse : Surement le premier car il n'a pas gaspillé ses ressources cognitives à apprendre des langages pour l'exemple, et donc maitrise bien mieux son langage de prédilection.
Comme le dit si bien le dicton : "Bon à tout, propre à rien".
[^] # Re: Yet another one
Posté par Victor . Évalué à 4.
Désolé mais ton commentaire est complètement à côté de la plaque :)
Elm apporte une façon radicalement différente de coder des applis dans le navigateur (frontend quoi, ça gère pas la partie serveur).
Ce n'est pas un n-ième clone de ce qui se fait déjà : je ne crois pas qu'il y ait beaucoup d'approche similaire existant.
Je comprend que tu ais pu te tromper, parce que je trouve que l'article met l'accent sur ce qu'il y a de moins intéressant avec Elm : la programmation fonctionnelle (au lieu des patterns architecturaux promeut par Elm).
[^] # Re: Yet another one
Posté par LouisB . Évalué à 0.
Je viens de lire le lien dans l'article pointant sur le tuto de "l'architecture elm" et, bah, soit j'ai pas compris, soit c'est un simple pattern MVC (où ils ont remplacé le terme "controller" par "update" pour plus de hype). Donc bon…
Ça me fait penser à des widgets. Oui, le truc qui existe depuis des lustres dans le domaine des interfaces graphiques. Rien de nouveau sous le soleil quoi.
Je suis d'accord avec toi, mais il faut bien avouer que le langage à l'air, malgrès lui, très fonctionnel (il suffit de voir les signatures curryfiés dans les exemples).
[^] # Re: Yet another one
Posté par Victor . Évalué à 3.
Tu peux aussi lire cet article que j'ai trouvé intéressant : http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
Comme je le dis en dessous, il y a le compilateur qui est vraiment bien foutu pour driver le développement (voir la section Wrap Up de l'article susnommé).
Je crois que surtout, ce qui donne un truc spécial à Elm c'est le mariage immutable, virtual-dom (pour les perfs), approche à la mvc (comme tu le dis) et typage statique et drivé par le compilo.
Mais bon, à dire vrai, je suis pas spécialiste du tout ^
[^] # Re: Yet another one
Posté par Victor . Évalué à 2.
Ou lire ça : http://futurice.com/blog/elm-in-the-real-world :)
[^] # Re: Yet another one
Posté par LouisB . Évalué à 2.
En effet, je comprends mieux les avantages qu'ont ce langage par rapport a javascript.
[^] # Re: Yet another one
Posté par Moonz . Évalué à 10.
D’ailleurs c’est pour ça que quand je bricole je n’utilise qu’un tournevis cruciforme. C’est vraiment un truc de hipster que d’aller gaspiller ses ressources cognitives dans l’apprentissage d’autres outils bizarres comme des marteaux, des scies, des clés, des mètres à rubans et autres pinces. Ces bricoleurs du dimanche qui se la pètent avec une boite à outils complète, ils sont vraiment propre à rien.
[^] # Re: Yet another one
Posté par LouisB . Évalué à -2.
Mouai, bof. Un tournevis cruciforme, c'est pas pratique pour enfoncer un clou, couper des planches, serrer des boulons, mesurer…
Je réitère ma question : quel est le meilleur bricoleur entre celui qui a un seul tournevis cruciforme et celui qui en a 12 différents ?
Spoiler réponse : celui qui sais s'en servir.
[^] # Re: Yet another one
Posté par Moonz . Évalué à 6.
Réponse : j’aurais du mal à faire confiance à un bricoleur qui me dit « je sais que me servir d’un tournevis cruciforme, mais vous inquiétez pas, je suis pas comme ces putains de hipsters qui apprennent tous les outils d’une boite à outil, moi mon tournevis cruciforme, j’en ai une maitrise parfaite ».
[^] # Re: Yet another one
Posté par LouisB . Évalué à -2.
Je me suis manifestement mal exprimé.
Le meilleur bricoleur entre celui qui a 12 tourne-vis, 5 marteaux, 27 clés, 3 mètres-rubans, 14 pinces et celui qui a 1 tourne-vis, 1 marteau, 1 clé, 1 mètre ruban, 1 pince ? Celui qui sais se servir de ces outils…
[^] # Re: Yet another one
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Bah, le bricoleur avec un seul tourne-vis, je doute qu'il soit très bon. Je ne suis qu'un bricoleur du dimanche mais je sais qu'il y a un paquet de vis de tailles et formes différentes et qu'un seul tourne-vis, ça ne le fait pas.
Mais passons outre cette analogie, la question est de savoir si on devient un meilleur développeur en se concentrant sur un seul langage ou si aller voir ailleurs peut aussi être efficace. Dans le commentaire initial, le meilleur développeur est celui qui est le plus rapide à réaliser une tâche donnée. Je trouve cela très réducteur, il faudrait au moins prendre en compte d'autres aspects comme la maintenabilité, la sécurité ou les performances du programme en question. Mais rien que pour la rapidité, je pense qu'il est préférable de connaître plusieurs langages.
Dans la courbe d'apprentissage, au début, il est effectivement préférable de se concentrer sur un seul langage. Mais une fois arrivé à un certain niveau, apprendre de nouveaux langages (même superficiellement) permet de voir de nouvelles choses et d'autres manières de faire. Et souvent, il est possible d’incorporer ces nouveautés dans son langage favori pour devenir plus productif. Je suis persuadé que tous les excellents développeurs dans un langage connaissent d'autres langages et se sont servis des enseignements dans ces autres langages pour parfaire leur maîtrise dans leur langage de prédilection.
Tous les développeurs les plus connus maîtrisent un paquet de langages en plus de leur langage de prédilection, sans exception. Bram Moolenaar a écrit Vim, mais a aussi développé son propre langage de programmation, Zimbu. Voici ce qu'il dit sur la page inspiration :
Un autre point important est que l'on est très rarement un bon développeur seul dans son coin. Le plus souvent, un bon développeur travaille en équipe et connaître d'autres langages permet de mieux communiquer avec le reste de l'équipe. Un développeur back-end qui connaît un peu d'HTML / CSS / JS sera souvent plus efficace dans son travail que celui qui s'est concentré sur sa partie.
[^] # Re: Yet another one
Posté par LouisB . Évalué à 2.
Moi aussi à vrai dire. D'un autre coté, j'ai été vite en besogne dans la traduction de la conclusion. J'aurais plutôt du dire "le meilleur développeur est celui qui se fatigue le moins en réalisant ses tâches" (ce qui ne veut pas dire la même chose).
Pour le reste, je comprends ton point de vue.
[^] # Re: Yet another one
Posté par max22 . Évalué à 6.
Le mauvais bricoleur, il a un tournevis cruciforme. Le bon bricoleur, il a un tournevis cruciforme, mais c'est un bon bricoleur.
[^] # Re: Yet another one
Posté par barmic . Évalué à 7.
Ça n'a rien avoir… La question c'est quel est le meilleur développeur entre celui qui sait faire de l'impératif et celui qui sait faire de l'impératif, de la gestion des pointeurs/références, qui connaît la POO (=> les notions d'encapsulation, de polymorphismes et de séparation de responsabilité), qui connaît le fonctionnel (=> ce qu'est une fonction pure, la gestion du typage), etc
Les langages en soit ne sont que des outils, ils permettent de découvrir des façons de penser différentes. S'y intéresser sans devenir un spécialiste du dit langage permet de découvrir de nouvelles approchent qui t'enrichissent même si elles sont mauvaises (pour savoir qu'elles sont mauvaises).
Ça ne veux pas dire qu'il faut connaître tous les langages existant, juste que tu pose le problème de la mauvaise façon et ta réponse est donc à coté de la plaque.
C'est très différent par rapport à si tu avais expliqué qu'Elm n'apporte pas grand chose face à Ocaml ou Haskel et qu'il n'est donc pas si intéressant que ça de s'y pencher sauf si on veut vraiment l'utiliser.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Yet another one
Posté par kantien . Évalué à 2.
Autrement dit : comme LouisB ne semble pas avoir saisi la problématique sous-jacente, doit-on le ranger dans la catégorie « mauvais développeur » ?
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Yet another one
Posté par barmic . Évalué à 3.
Pourquoi vouloir juger les gens ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Yet another one
Posté par kantien . Évalué à 3. Dernière modification le 25 avril 2016 à 15:28.
Je ne le jugeais pas, je lui renvoyais sa propre interrogation (celui qui juge les autres se condamne lui-même). ;-)
Il renvoyait au strip xkcd « comment les standards prolifèrent » (c'est un jugement de valeur sur Elm), il distinguait entre le bon et le mauvais développeur (c'est un jugement de valeur1)… et pourtant il passe complètement à côté de la problématique à laquelle s'attaque Elm (c'est certes là aussi un jugement, mais non de valeur, qui est factuel et objectif : il passe à côté de la question « pourquoi Elm ? »; ce qui, pour moi, correspond à ton message et à la partie que j'ai citée).
le summum étant sa conclusion : « bon à tout, propre à rien ». ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Yet another one
Posté par LouisB . Évalué à -1.
C'était justement tout l'intérêt de la question (suffit le voir la réponse que j'apporte).
On me vend un nouveau langage = meh
On me vend un outil qui permet de générer facilement et fiablement un front-end javascript = ha, c'est déjà un peu plus cool
Le soucis que j'ai avec elm, c'est qu'il est vendu comme un truc révolutionnaire, alors qu'au final il ne fait que forcer les bonnes pratiques déjà connus et applicables à javascript…
[^] # Re: Yet another one
Posté par barmic . Évalué à 7.
Alors t'a vraiment pas était clair. Si ton propos c'est juste de dire que la dépêche parlait trop du langage et pas assez des pratiques lié au web avec ce langage, il y en a d'autres qui ont mieux réussi à se faire comprendre que toi (probablement parce qu'ils n'ont pas sous-entendu que les autres étaient nuls).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Yet another one
Posté par steph1978 . Évalué à 6.
Je ne partage mais alors pas du tout.
Apprendre plusieurs langage permet de ne pas tomber dans les travers d'un seul.
Tu peux mieux coder en C en apprenant un langage fonctionnel.
Ensuite la métrique du temps de dev est ridicule si tu ne mais aucun critère de qualité.
Tout problème se code en 5 minutes en allant sur SO.
Mais de là à bien avoir un code suffisamment efficace en ressources, adapté à tes cas limites, maintenable dans le temps ; ça demande beaucoup plus.
Et puis c'est comme parler une seule langue. Si tu dois bosser sur un projet qui a fait un choix de langage différent du tien, t'es marron. Et un projet dans un seul langage, déjà c'est rare.
IMHO, il serait plus constructif de commencer à coder que de regarder des conférences boiteuses.
# Dommage...
Posté par Victor . Évalué à 7.
Je trouve que dommage que l'article se soit concentré sur une présentation des avantages de la programmation fonctionnelle et immutable.
On a tous lu (ou on peut tous lire) des articles sur la question.
Mais ce qui fait de Elm un super langage, c'est bien ce que PERMET cette utilisation de la prog fonctionnelle.
Ce qui déchire avec Elm c'est les patterns qu'il promeut, avec cette séparation modèle/action/vu et la composabilité des modules que tu fabrique avec. Bien sûr, sans la programmation fonctionnelle et immutable, ce sera impossible, mais on a pas besoin de faire un cours sur les arbres pour présenter cet autre aspect.
Par exemple l'introduction à l'architecture typique d'un programme Elm (The Elm Architecture) pourrait avoir ête utilisé comme base de cet article pour bien montrer en quoi Elm se démarque de beaucoup (toutes ?) d'autres approches au développement de frontend web.
Bon ceci dit, merci pour en faire parler, ça fait plusieurs semaines que j'en entend parler, j'ai regardé un peu et je trouve l'approche très excitante !
Je déteste javascript et au boulot je pleurs qu'on choisisse de développer des applis web avec ça.
[^] # Re: Dommage...
Posté par Moonz . Évalué à 2. Dernière modification le 24 avril 2016 à 12:35.
Du peu que je vois, c’est exactement l’idée derrière React+Redux.
[^] # Re: Dommage...
Posté par Victor . Évalué à 3. Dernière modification le 24 avril 2016 à 17:42.
Oui, c'est ce que dit l'introduction du présent article, Redux est inspiré de Elm ;)
Mais bon, ce qui est vraiment cool avec Elm c'est que tu as le compilateur de ton côté pour driver ton développement.
Voir par exemple ça je crois : http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html (lire la partie Wrap Up en particulier).
(Après, j'aime vraiment pas javascript, c'est trop n'importe quoi, mais bon, je suis un grand fan de typage statique d'une manière générale, donc c'est mon opinion perso).
[^] # Re: Dommage...
Posté par kantien . Évalué à 3.
Le compilateur permet de conduire le développement, c'est certain, mais c'est là une caractéristique propre à tout langage statiquement typé (et le système de type de Elm, ADT, offre une bonne expressivité sémantique). Mais, le fait que ce soit de la programmation réactive en fonctionnel pur (FRP) offre une possibilité unique dans la phase de développement : le hot-swapping.
Cela permet de modifier le code à chaud, et de rejouer toutes les interactions utilisateurs avec le code modifié. Autrement dit : je teste mon code, j'interagis avec lui et je constate un comportement non souhaité; alors je modifie dans mon code la partie qui me semble être fautive, et je vais rejouer la même séquence d'entrée sur le nouveau code (sans la refaire moi-même à la main, bien entendu). Je ne sais pas si React+Redux permet ce genre de chose, en plus du paradigme réactif il faut l'immutabilité des structures pour effectuer ce genre de chose.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage...
Posté par Moonz . Évalué à 2.
Je ne sais pas si c’est déjà implémenté, mais c’est clairement dans les plans de l’auteur de Redux.
[^] # Re: Dommage...
Posté par kantien . Évalué à 2.
De ce que j'ai compris, après une lecture rapide en diagonale, redux encapsule l'état d'une application en ne faisant que du fonctionnel pur (paradigme tout à fait praticable en javascript). Mais là où l'auteur de redux va en chier pour son implémentation, c'est que du code utilisant redux cohabite avec du javascript générique qui lui n'interdit pas les effets de bords. Il va devoir contrôler et mettre en place des systèmes d'inférences pour vérifier qu'il n'y a pas d'effets de bord dans le code, là où c'est impossible dans Elm et cela par conception même du langage.
De toute façon, comme Victor je ne suis pas objectif, pour moi javascript est un langage qui est defective by design. Voir la vidéo wat :
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage...
Posté par Victor . Évalué à 2.
Bien vu, c'est vrai que le FRP apporte beaucoup de choses et j'avais un peu zappé cet aspect dans ma tentative de défendre l'originalité de Elm :)
[^] # Re: Dommage...
Posté par barmic . Évalué à 3.
Oui mais justement. Autant l'approche fonctionnel c'est assez vieux autant React et Redux, c'est beaucoup plus récent et beaucoup moins connu (genre moi je connais que les noms).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dommage...
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Oui, je me rends compte a posteriori que je n'ai pas mis l'accent où il fallait pour cet article sur Elm. Je voulais garder un article assez court pour ne pas faire peur et permettre à beaucoup de gens de le lire rapidement. Il y a plein d'autres choses intéressantes dans Elm et je ne voulais pas répéter bêtement The Elm Architecture. Bref, peut-être qu'un lecteur proposera une suite à mon article pour le compléter.
[^] # Re: Dommage...
Posté par Victor . Évalué à 7.
C'est quand même vachement bien d'avoir fait un article sur le sujet et je crois que ça a éveillé l'intérêt de pleins de gens en tout cas ! Perso ça m'a motivé à re-regarder ce week-end et me plonger dedans plus sérieusement :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.