Il y a tellement de choses avec lesquelles je suis en désaccord dans ce message, que je ne sais par où commencer.
Juste en avant propos, je viens du web, j'ai travaillé pendant 5 ans à faire du Python et du Javascript (pas du jQuery à 2 balles, mais du Ember.js/Angular). Je me suis maintenant mis en Freelance et fait de l'OCaml et Erlang.
La mode du JavaScript as target platform: Elm, PureScript
Aucun langage n'est parfait, mais ajouter à un langage médiocre une communauté incompétente pour 95% d'entre eux. Si tu te retrouve à faire du JavaScript, tu te retrouves avec du code spaghetti maintenable que tu dois maintenir.
Maintenant, je vais mettre Erlang de coté, car à mon avis, c'est plus un langage comparable à Rust qu'à Haskell/OCaml.
Pour les langages type Haskell et OCaml (ou les types sont inférés) la majorité des gens ne comprennent pas l'avantage, car ils n'ont jamais travaillé avec ces langages. Donc ils parlent de quelque chose qu'ils ne connaissent pas. Haskell et OCaml apportent des concepts qui n'existent pas dans aucun autre langage.
Je me rappelle, il y a 8 ans, PHP et Java étaient l'ennemi, c'était de la merde, plein de bug, in-maintenable. Tout le monde est passé à Ruby et Python et ne se sont pas rendu compte qu'ils n'ont absolument rien réglé.
Quand je faisait du python, combien de fois je me suis retrouvé avec des bugs du type: la fonction reçoit un entier au lieu d'une chaîne de caractère. Ou alors, cette fonction doit recevoir une liste chaine de caractères, mais elle reçois une chaine de caractères toute simple. Et en python, une chaine de caractère est une liste de chaine de caractère à un caractère. Donc tu vois le bug que très très profond dans le code, et tu dois passer la journée à remonter à la source.
En Haskell et OCaml ces bugs n'existent pas. Car tu as les avantages de Java (typage fort) et de Python (aucun besoin de spécifier les types) car les types sont inférés. Tu devrais jouer avec Ocaml et te rendre compte par toi même. Compiler OCaml/Haskell te donne la même chose qu'une couverture à 100% des branches de code avec des tests unitaires, mais sans aucune assertion. Ce qui est déjà pas mal.
Aussi, avec l'inférence de types, tu peux avoir une équipe qui implémente la moitié du code, et une autre équipe l'autre moitié. Du moment que tu as défini des interface communes.
Erlang, même si les gens le considère fonctionnel, est un tout autre langage. La puissance d'Erlang c'est la machine virtuelle. Je ne sais pas par où commencer, mais l'idée est que le programmeur doit utiliser un processus pour chaque fonction. Les processus peuvent être rafraichi pour mettre à jour leur code sans interruption de service. Une instance d'une machine virtuelle peut tourner sur plusieurs machine réelles, et donc tu peux migrer les processus d'une machine à une autre sans interruption de service. Des choses impossible dans aucun autre langage.
Qui plus est, les variables en Erlang sont constantes (comme Rust par défaut) ce qui empêche les race-condition mais aussi force les programmeurs à écrire des fonctions de pas plus d'une 10aine de lignes. Combien de fois je me suis retrouvé sur des projets python avec une méthode qui faisait 300 lignes de codes.
Voici les choses que ces langages ont depuis plus de 5 ans qui arrivent dans les autres langages:
Haskell avait les monades et Erlang avait receive pour faire de l'asynchrone. Python vient tout juste d'avoir yield from et asyncio.
Haskell avait Parsec pour parser de manière sécurisée. Rust vient tout juste d'implementer nom qui a été présenté au RMLL.
Et je dois en oublier plein d'autres...
Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »
[^] # Re: Le web
Posté par Ife . En réponse au journal Qui fait des trucs "cools" en France et en Europe?. Évalué à 7.
Il y a tellement de choses avec lesquelles je suis en désaccord dans ce message, que je ne sais par où commencer.
Juste en avant propos, je viens du web, j'ai travaillé pendant 5 ans à faire du Python et du Javascript (pas du jQuery à 2 balles, mais du Ember.js/Angular). Je me suis maintenant mis en Freelance et fait de l'OCaml et Erlang.
Je vais commencer par le JavaScript, parce que c'est les plus facile à attaquer: le web coté client est daubé du cul, il faut que les gens se mettent ça dans la tête. Brendan Eich explique lui même que le but du JavaScript était d'implémenter Scheme dans le navigateur, et ses supérieurs lui ont dit « en fait on veux quelque chose proche de Java ». Il a une quantité infinie de mauvais comportements.. Qui plus est, la communauté JavaScript pue la mort, elle est majoritairement composée de designers ou personnes qui ont appris la programmation sur le tas. Le langage est considéré comme un jouet de designer même s'il est bien plus puissant.
Il y a quelque efforts pour rendre JavaScript bien (meilleure communauté, moins code spaghetti):
Aucun langage n'est parfait, mais ajouter à un langage médiocre une communauté incompétente pour 95% d'entre eux. Si tu te retrouve à faire du JavaScript, tu te retrouves avec du code spaghetti maintenable que tu dois maintenir.
Maintenant, je vais mettre Erlang de coté, car à mon avis, c'est plus un langage comparable à Rust qu'à Haskell/OCaml.
Pour les langages type Haskell et OCaml (ou les types sont inférés) la majorité des gens ne comprennent pas l'avantage, car ils n'ont jamais travaillé avec ces langages. Donc ils parlent de quelque chose qu'ils ne connaissent pas. Haskell et OCaml apportent des concepts qui n'existent pas dans aucun autre langage.
Je me rappelle, il y a 8 ans, PHP et Java étaient l'ennemi, c'était de la merde, plein de bug, in-maintenable. Tout le monde est passé à Ruby et Python et ne se sont pas rendu compte qu'ils n'ont absolument rien réglé.
Quand je faisait du python, combien de fois je me suis retrouvé avec des bugs du type: la fonction reçoit un entier au lieu d'une chaîne de caractère. Ou alors, cette fonction doit recevoir une liste chaine de caractères, mais elle reçois une chaine de caractères toute simple. Et en python, une chaine de caractère est une liste de chaine de caractère à un caractère. Donc tu vois le bug que très très profond dans le code, et tu dois passer la journée à remonter à la source.
En Haskell et OCaml ces bugs n'existent pas. Car tu as les avantages de Java (typage fort) et de Python (aucun besoin de spécifier les types) car les types sont inférés. Tu devrais jouer avec Ocaml et te rendre compte par toi même. Compiler OCaml/Haskell te donne la même chose qu'une couverture à 100% des branches de code avec des tests unitaires, mais sans aucune assertion. Ce qui est déjà pas mal.
Aussi, avec l'inférence de types, tu peux avoir une équipe qui implémente la moitié du code, et une autre équipe l'autre moitié. Du moment que tu as défini des interface communes.
Et Haskell te permet de faire du multi-threading sans race-condition très facilement. Je te conseille de lire cet article
Erlang, même si les gens le considère fonctionnel, est un tout autre langage. La puissance d'Erlang c'est la machine virtuelle. Je ne sais pas par où commencer, mais l'idée est que le programmeur doit utiliser un processus pour chaque fonction. Les processus peuvent être rafraichi pour mettre à jour leur code sans interruption de service. Une instance d'une machine virtuelle peut tourner sur plusieurs machine réelles, et donc tu peux migrer les processus d'une machine à une autre sans interruption de service. Des choses impossible dans aucun autre langage.
Qui plus est, les variables en Erlang sont constantes (comme Rust par défaut) ce qui empêche les race-condition mais aussi force les programmeurs à écrire des fonctions de pas plus d'une 10aine de lignes. Combien de fois je me suis retrouvé sur des projets python avec une méthode qui faisait 300 lignes de codes.
Voici les choses que ces langages ont depuis plus de 5 ans qui arrivent dans les autres langages:
receivepour faire de l'asynchrone. Python vient tout juste d'avoiryield fromet asyncio.Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »