Bruno Michel a écrit 3285 commentaires

C'est comparé des pommes et des oranges.

• Le premier commit d'Elm date effectivement d'avril 2012, mais il n'a pas encore atteint une version 1.0.
• Le premier commit de Swift date de 2010 et la version 1.0 (première version publique) de 2014.
• Le premier commit de Go date de 2007, la première version publique de fin 2009 et la 1.0 de 2012.

C'est plus récent que Swift (2014)

Non, pour le coup, le développement de Swift a commencé 2 ans avant celui d'Elm.

et plus proche de Go (fin 2009) que d'aujourd'hui…

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.

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.

Cependant, dans le cas de mutex par exemple, un langage qui ne fournit pas cela, c'est plus un langage jouet pour moi (probablement très bien pour l'apprentissage, hein !) et pas quelque chose d'exploitable.

C'est très réducteur : tous les langages n'ont pas les mêmes abstractions. Pour les mutex, il me semble qu'Erlang n'en a pas et ça ne l'empêche pas d'être très très bon dans la gestion de la concurrence. OTP est même ce qui considéré comme ce qu'il se fait de mieux actuellement dans ce domaine. Erlang est très utilisé dans les Télécom et part des sociétés comme Amazon, Facebook, Github et WhatsApp. Bref, c'est tout sauf un langage jouet.

Un lien intéressant à ce sujet : Why Erlang matters.

Ce serait un point à ajouter dans le journal "arrêter de jouer à l'homme orchestre".

+1. Pour moi, une caractéristique essentielle d'un bon développeur est de savoir travailler en équipe.

Pour les freelances, c'est très compliqué, il faut souvent faire un peu de tout (de la gestion de projet au graphisme en passant par les parties commerciales/contractuelles). Mais de mon expérience, ce ne sont pas les meilleurs développeurs, ils sont très polyvalents mais moins capables quand il faut rentrer dans les détails. Bien sûr, il y a des exceptions, mais c'est globalement mon impression.

À l'inverse, les très bons développeurs vont souvent travailler dans une équipe qui leur permet de se concentrer sur ce qui est important : écrire du code qui apporte des fonctionnalités et améliore l'expérience de l'utilisateur. Ça veut dire savoir se reposer sur un chef de projet ou un product owner qui est capable de prioriser les bonnes fonctionnalités et de fournir les éléments qui vont bien. Ou ne pas essayer de faire le design graphique mais s'appuyer sur des graphistes et designers pour ça.

En ce moment j'hésite à me lancer dans The Pragmatic Programmer ou Programming Pearls. Qu'en penses-tu ?

J'ai lu The Pragmatic Programmer il y a de ça une dizaine d'années et j'ai beaucoup appris avec. Je recommande fortement sa lecture.

Les vrais commentaires supprimés par l'équipe de modération ont un liseré rouge avec la CSS par défaut.

Je vais faire un peu de pub. Je travaille pour Cozy Cloud et je te conseille d'y jeter un coup d’œil. La partie synchronisation de fichiers est encore loin d'être au niveau d'OwnCloud et SyncThing. J'y travaille mais ça va prendre du temps (ça ne sera probablement pas dans les six mois qui viennent).

Par contre, pour la partie calendrier et contacts, on a déjà quelque chose qui marche bien et joli en plus.

Côté sécurité, tout n'est pas parfait. On a des progrès à faire pour sandboxer les applications tierces. Mais si on se restreint aux applications distribuées dans le store, ça tient bien la route.

Voici le point de vue d'un développeur connu pour faire beaucoup de modules avec peu de lignes de code :

https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328

Oui, je voulais parler de trademark. Kik.com a une API Rest et veut proposer un SDK en nodejs pour l'utiliser. Ils ont donc contacté l'auteur du module kik sur npm pour essayer de négocier de pouvoir récupérer le nom de ce module pour leur SDK. Derrière, ça a vite dégénéré avec des noms d'oiseaux.

L'histoire vu du côté Kik : https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d

Oui, j'aimerais bien voir un autre langage disponible dans les navigateurs (ou même plusieurs via WebAssembly). Côté serveur, la question ne se pose pas trop, on a déjà le choix d'utiliser Go, Ruby, Python, Erlang, Elixir et plein d'autres langages plus sensés que le JS.

En ce moment, je regarde du côté d'Elm. Ça a l'air pas mal mais je ne connais pas encore assez pour dire s'il répond aux critères. Le langage est jeune et a encore des défauts de jeunesse, mais on sent qu'il a du potentiel.

Il nous parle d'opensource mais ses projets ne comportent pas de mention de la licence utilisé surtout.

Si, la licence est mentionnée (même si c'est relativement bien caché). C'est du WTFPL.

M'enfin quand même, pouvoir dé-publier un truc publié de longue date sur npm ça me semble surtout une anti-fonctionnalité.

Oui, cette fonctionnalité est discutable. Mais je trouve encore plus discutable que npm puisse annuler la dépublication de l'auteur.

Oui, mais le risque est démultiplié en javascript pour 2 raisons :

• La bibliothèque standard est incroyablement pauvre et les modules npm sont souvent utilisés en grande quantité pour compenser ;
• Npm2 peut installer plusieurs fois la même dépendance dans des versions différentes (npm3 corrige ça mais a d'autres problèmes).

Au sujet des nombres aléatoires en Elm, je viens de voir passer ce billet de blog : http://reversemicrowave.me/blog/2016/03/04/elm-secure-random/. Je trouve que ça illustre bien les difficultés que l'on peut rencontrer quand on découvre un langage de programmation fonctionnel.

Tu veux dire que t'avais pas vu les défauts de JavaScript qui sont là depuis 1995 ?

C'est difficile de comparer le JavaScript de 1995, ou même celui de 2005, à celui d'aujourd'hui. D'abord, le langage a évolué, son écosystème aussi. Mais surtout, on ne fait plus la même chose avec. Pour écrire 10 ou 100 lignes de code qui rendent un site un peu plus dynamique, JavaScript me convient bien. Pour faire une application complète, beaucoup moins.

D'ailleurs, la plupart des défauts que je cite dans le journal, j'aurais eu bien du mal à les citer il y a 10 ans (en 1995, je ne faisais pas de JS). Et je doute que beaucoup d'autres développeurs les aient vu à cette époque là.

• Asynchrone : en 2005, je n'avais jamais entendu parlé de CSP et l'event loop du JavaScript me paraissait très bien pour ça. J'ai d'ailleurs fait du EventMachine (une sorte d'event loop pour Ruby) dans les années qui ont suivi.

• Confiance dans le code : j'étais sûrement jeune et naïf, mais je ne me voyais pas utiliser des structures immutables ou du typage statique fort à la haskell (trop contraignant au quotidien pour développer rapidement).

• Outils : le contexte a tellement changé de ce côté là en 10 ans. Jamais, je ne me serais plaint d'avoir trop d'outils ou qu'ils soient trop complexes en JS il y a 10 ans.

• Écosystème : nodejs et npmjs n'existaient pas en 2005, jquery et ses nombreux plugins non plus. Pouvait-on prévoir que cela allait devenir un tel bordel ?

• Complexité du langage : ça se discute. Mais j'ai l'impression que c'est quand même récent que la spec de JavaScript grossit rapidement et deviendra bientôt aussi épaisse que celle du C++.

Quand on utilise une lib open source avec peu de contributeurs, en 0.x.x ou pas, faut prendre en compte qu'il faudra peut-être la maintenir soi même.

On est bien d'accord. Et comme c'est le cas de quasiment tous les modules sur npm, on se retrouve rapidement à faire beaucoup de maintenance soi-même. Dans d'autres langages, les acteurs (entreprises et communauté) créent moins de paquets mais maintiennent mieux l'existant.

Est ce que je passe à côté de quelque chose ? Elm a-t-il des outils pour déboguer/visualiser/modifier aussi facilement son code que du vanilla HTML/JS ?

Oui, il y a des outils pour faire tout ça. D'ailleurs, un article montre comment rejouer des interactions pour tester une nouvelle version du code : http://elm-lang.org/blog/time-travel-made-easy. C'est assez impressionnant !

Pour le build, je passe mon tour. Pour les tests, ça dépend si je veux quelque chose d'éprouvé ou si je peux me permettre d'expérimenter.

Pour la version éprouvée, je me tournerais vers Mocha, avec ses amis chai et sinon.

Pour l'expérimental, je prendrais painless. L'approche me plaît beaucoup, il y a des fonctionnalités intéressantes mais ça n'a pas l'air très utilisé pour le moment.

Et pour rire 2 minutes, voici les numéros de la dernière version de typescript :

This release has the version tag of 1.8.5.0 for Visual Studio 2013, 1.8.6.0 for NuGet and Visual Studio 2015 and 1.8.7.0 for npm.

Source : https://github.com/Microsoft/TypeScript/releases

Bien vu, c'est une erreur de ma part. L'underscore n'a pas de sens spécial ici.

Oui, il faudrait faire ça. Quand j'ai codé ça, je me suis appuyé sur l'avis des modérateurs de l'époque. À l'usage, on s'est effectivement rendu compte que ce n'était pas idéal. D'ailleurs, il y a une entrée de suivi à ce sujet. Si un volontaire veut envoyer un patch, je m'engage à le relire, l'intégrer et le déployer en production rapidement.

2 petites précisions sur cette phrase :

Typescript (qui n'est ni plus ni moins qu'un subset de JS hein) avec les nouveautés de ES6

• Typescript est un superset, pas un subset de JS. Il propose le typage en plus (avec sa syntaxe).
• La prise en charge d'ES6 par Typescript n'est pas mauvaise, mais reste en-dessous de celle proposée par Babel, traceur, Chrome, Firefox ou Edge. Par contre, Typescript a aussi commencé à prendre en charge des évolutions futures de JavaScript, comme Array.prototype.includes (ES2016), Object.values et Object.entries (stage 3 et très certainement dans ES2017) et même async/await (stage 3, mais aucune implémentation existante dans les navigateurs, donc chances assez mitigées d'être dans ES2017).

Je note que cette tendance à valoriser des langages peu connus et peu éprouvés date d'il y a une dizaine d'années, et qu'on en a déjà vu passer un certain nombre…

C'est même probablement plus vieux que ça. Mais bon, je pense que tous les langages ont été peu connus et peu éprouvés à un moment. Il y en a même qui ont défendu le Python à une époque…

Mon point n'était pas de dire qu'il ne faut plus utiliser le JavaScript dès aujourd'hui et passer à ces langages inconnus. Ces langages sont des expérimentations, pas un truc solide pour construire des applications qui iront en production aujourd'hui. Mais étudier ces langages restent utile, on apprend des outils et des façons différentes de coder.

Ces terrains d'expérimentation permettent souvent d'avoir une idée des concepts que l'on retrouvera dans quelques années dans les langages majeurs. Par exemple, les channels et goroutines de Go ont beaucoup profité des expériences de 2 langages obscurs : occam et limbo (d'ailleurs, ce n'est pas étonnant, Rob Pike est l'un des créateurs de Limbo et de Go). Les lambdas de Java 8 sont arrivées après celles de Groovy (et autres langages basés sur la JVM). Et bien entendu, un bon paquet des fonctionnalités introduites dans ES6 viennent de CoffeeScript.

Au final, ma question n'est pas de dire par quoi on va remplacer JavaScript aujourd'hui, mais dans quel état il sera dans quelques années. Ces dernières années, le nombre de développeurs JS a clairement augmenté. Mais je crains que le JavaScript (langage, outils, écosystème) n'aille dans une mauvaise direction.

Quant à m'expliquer que je dois participer à des bibliothèques Open Source, c'est assez naïf. Ça fait un paquet d'années que je le fais, comme mon compte github pourrait l'attester. Cela inclut des bibliothèques JS, comme moment ou forever.

J'aime bien les fat arrows, mais plutôt celle de CoffeeScript que d'ES6. Bon, globalement, ça reste positif, mais j'aurais préféré moins de complexité.

• les parenthèses sont optionnelles quand on a un seul argument (et uniquement dans ce cas)

// Valide
let inc = a => a + 1
let dec = (a) => a - 1
let add = (a,b) => a + b

// Invalide
let sub = a,b => a - b

• Le comportement est différent selon que l'on utilise des accolades ou non

// Le return est implicite
let add = (a,b) => a + b
add(3,5) // => 8

// Mais pas ici
let sub = (a,b) => { a - b }
sub(5,3) // => undefined

• Et comme les accolades définissent un bloc de code, on ne peut pas les utiliser pour renvoyer un objet. Il faut du coup penser à les entourer par des parenthèses…

let foo = (a,b) -> ({ a: a, b: b })

• Pourquoi avoir donné un sens spécial au caractère underscore ? Si je ne me trompe pas, il n'en avait pas jusque là.

// Une fat arrow sans paramètre
setInterval(_ => { console.log(new Date) }, 1000)

Certains ont un avis différents : http://www.elmbark.com/2016/03/02/mainstream-elm. Pour ma part, je ne connais pas encore assez le langage pour avoir un avis tranché.