IBM FRANCE

Michel Lara, Architecte Cloud au sein d’IBM France, nous délivre sa vision sur les changements opérés chez IBM ces dernières années....

Lire la suite

Un résumé de la conférence ELM 2017

Par:
theo.fleury

jeu, 22/06/2017 - 17:29

Résumé de quelques talks :

Un des speakers (Noah Zachary Gordon, software developer neworkais) a comparé le langage avec de la cuisine. Il n'est pas cuisinier professionnel donc il a cherché une recette sur internet et en a trouvé une pas mal. Mais elle n'était pas assez détaillée. Trop compliquée, let's check for an other one ! C'est un peu la même chose qui se passe avec ce langage, "c'est pour les flemmards". Au final c'est quoi une recette ? C'est un enchaînement d'instructions ordonnées, un peu comme des couches de lasagnes. L’exportation est facile. Le code peut être repris par un autre développeur sans que cela pose autant de problème qu'avec les langages dont on a l'habitude. Ce langage est aussi expressif que le Ruby.

Le CTO de Nomalab, Sébastien Crème, travaille dans le traitement vidéo avant distribution aux grandes chaînes. Il y a un problème à l'encryptage, difficulté pour envoyer aux diffuseurs une image et son fidèles à l'original. Ils travaillent avec de gros fichiers de 500Mo à 500Go. La puissance de l'ELM est la refactorisation de code et c'est un langage solide et fiable. Il ne faut pas être effrayé par le changement. Même sur une grosse application, ça peut prendre seulement un jour à un nouveau développeur de se raccrocher à la locomotive. C'est-à-dire de comprendre le code et pouvoir travailler dessus. Il faut au préalable connaître le FP (Fonctionnal Programming = programmation fonctionnelle) obligatoirement. Tout le monde peut comprendre et modifier l'application. Le plus gros challenge ? Les gens ont peur des nouvelles choses. Comment les convaincre ?

Richard Feldman (@rtfeldman sur Twitter) de NoRedInk a parlé de scaling. On peut spliter son code grâce à la refactorisation. Quand on a un code très long il est difficile de trouver ce qu'on cherche. Le code peut être également trop gros pour tenir dans notre tête. Il peut y avoir des duplications. On fait des sortes d'include, on gagne en organisation. ELM permet d'avoir un code mieux organisé, plus court, réutilisable et refactorisation à faible risque.

Amitai Burstein le CTO de Gizra a parlé des perspectives de ELM en terme de business. Ce langage permet de s'assurer que le projet sera fructueux. Les Timebox des soucis (par 4 heures) servent de checkpoints pour avoir les choses à temps. Les bugs ont un coût et ELM en a peu. Pourquoi ELM est bien pour le business ? La communauté grandit, il y a un compiler, les résultats viennent plus vite avec moins de bugs. Il y a aucune RunTimeError, le langage est Cross Platform, déclarative API, facilement refactorisable. Cependant, c'est un langage encore incomplet, il manque de support librairies, ça ajoute des couches d'abstraction, imperative mismatch.

Tereza de OpBeat (@terezk_a sur Twitter) utilise ELM pour faire des graphes, elle a construit la bibliothèque elm-plot. C'est une API flexible et plus expressive que le JavaScript.

Interview de participants/speakers :

Evan Czaplicki (@evancz sur Github) est le créateur de ELM. Il aimerait qu'on retienne que c'est un langage super pratique pour faire des visuels sympas facilement. C'est un code qui ne crash pas. Il travaille dessus depuis 2012 et a commencé dans le cadre de ses études.

Un speaker (Martin Janiczek) d'une compagnie de CRM m'a dit que c'était un langage très lent, plus lent que le JavaScript c'est à dire qu'il se développe lentement mais il mourra également pas rapidement et c'est rassurant. On peut situer React entre le JS et ELM. Il n'utilise cependant pas encore ELM dans son travail, peut-etre dans un an.

Un Espagnol de la compagnie Gizra m'a expliqué qu'il travaillait déjà avec ELM. Il souhaite en apprendre plus, il est venu avec son boss pour profiter de la communauté qui se crée.

Lorsque le front end devient complexe ELM est une bonne alternative selon lui. C'est plus maintenable et plus difficilement cassable (on ne perd pas son code d'une version à l'autre) et beaucoup moins de bugs grâce au compilateur.

Un developpeur front end de chez OuiCar pense qu'il y a beaucoup de concurrence et que ce ne sera pas mainstream. ELM est bien pour les outils internes, il s'agit d'un langage à part entière et la communauté est plus conviviale que chez JavaScript.

Une boîte de sismologie travaillant pour le CNRS joue avec plein de langage pour s'amuser comme ELM par exemple. Ils ont trouvé le langage très agréable. Le code est incassable. Mais il n'y a pas assez de librairies, de doc... La communauté est très sympa. Ils pensent que le langage peut mourir.

Mozzila (un des sponsors présents) travaille avec ELM depuis quelques mois pour des outils en internes. C'est très pratique pour les dashboards... Ils étaient fâchés avec le front-end car le javascript est assez contraignant.

Théo Fleury 

Je suis Théo Fleury. J'ai fait deux ans de prépa scientifique avant d'entrer en L3 à l'Efrei. Je suivrai un cursus en Business Intelligence a partir de cette annee pour obtenir le diplôme d'ingénieur en 2019. J'aime beaucoup le développement web, j'en fais depuis de nombreuses années, c'est pourquoi j'ai voulu découvrir ce nouveau langage. Vous pouvez ajouter que l'on peut me trouver sur LinkedIn @ www.linkedin.com/in/fleurytheo