Journal Et si JavaScript allait droit dans le mur ?

Posté par Bruno Michel (site web personnel) le 02 mars 2016 à 20:55. Licence CC By‑SA.

Étiquettes :

mar.

2016

Ce journal a été promu en dépêche : Et si JavaScript allait droit dans le mur ?.

Sommaire

Always bet on JS - Brendan Eich

Je me pose pas mal de questions sur l'avenir du JavaScript. D'un côté, il semble plus fort que jamais et ses surcouches (CoffeeScript, PureScript, etc.) ne sont plus à la mode. De l'autre, ces défauts me sautent de plus en plus aux yeux.

Je passe pas mal de temps à regarder de nouveaux langages de programmation. La plupart resteront expérimental, mais de temps à autre, un langage perce. Ce fût par exemple le cas de Go il y a quelques années. Ceci dit, ma motivation principale quand j'étudie ces nouveaux langages n'est pas tant de trouver le futur langage qui deviendra à la mode que d'apprendre de nouvelles façons de penser et de programmer. Voici un petit tour très très succinct des derniers langages qui ont retenu mon attention :

Crystal est un langage dont la syntaxe s'inspire très fortement du Ruby mais qui est compilé et non pas interprété. Celui lui donne des performances bien plus avantageuses et offre le filet de sécurité qu'est le typage statique (sans avoir à ne jamais écrire le moindre type !).

Pony est un langage orienté objets, avec un modèle d'actors (similaire à celui d'Erlang ou Akka) et un système de capabilities très intéressant. La syntaxe est très agréable et on retrouve de nombreuses structures tirées des langages fonctionnels (pattern matching, application partielle d'une fonction).

Oden est un langage qui vise à profiter de l'écosystème golang mais avec un langage plus fonctionnel. On retrouve ainsi du typage statique, avec la prise en charge du polymorphisme, ainsi qu'une syntaxe plus épurée que le Go.

Elm est un langage fonctionnel pour écrire des applications dans un navigateur. Prenez React, Redux, Immutuable.js, enlevez beaucoup de bruit pour ne garder que l'essentiel, poussez le concept un peu plus loin, et Elm pourrait bien être ce que vous obtenez.

Elixir est déjà plus établi que les langages précédents. C'est un langage qui permet de profiter de la machinerie d'Erlang quand on est allergique à sa syntaxe. Au passage, on gagne aussi des outils bien pratiques.

Bien sûr, il y aurait beaucoup plus à dire sur chacun de ses langages, mais ce qui m'intéresse ici est qu'ils apportent beaucoup de mécanismes qui me manquent cruellement quand je code en JavaScript.

L'asynchrone

JavaScript, avec son Event Loop et ses callbacks dans tous les sens, était à la pointe de la gestion de l'asynchrone il y a 15 ou 20 ans. Maintenant, CSP est devenu populaire, et à juste titre.

JavaScript n'est pas resté immobile. On a vu apparaître les Promise, puis certains ont détourné les générateurs. On parle beaucoup d'async/await. Il n'empêche, on est toujours dans un bourbier, coincé entre des API qui utilisent parfois des callbacks, parfois des promises.

Async/await est présenté comme une solution miracle depuis un bout de temps mais n'avance que très lentement. Il n'a pas été intégré à ES6, il ne passera pas dans ES2016 et ça semble mal parti pour ES2017. Et pour cause, aucun moteur JavaScript des principaux navigateur n'a d'implémentation pour lui. Côté nodejs, pas mieux, on attend sur V8 et il n'y aura pas de version LTS qui prendra en charge async/await avant un paquet de temps. On peut jouer avec Babel en attendant, mais ça reste un jeu, pas quelque chose que l'on peut espérer utiliser en production et encore moins dans un projet Open-Source.

La confiance dans le code

La confiance dans le code passe naturellement par les tests. Mais ceux-ci ne sont pas parfaits et ne devraient en aucun être notre seul moyen d'avoir confiance dans le code que l'on écrit. D'ailleurs, les autres langages cités au-dessus sont très riches en enseignements de ce côté là.

Il y a bien sûr l'immutabilité (on ne modifie jamais un objet ou une valeur, on en crée un nouveau avec les informations mises à jour). Côté JS, const permet juste d'éviter de réassigner une valeur à une variable mais si cette valeur est un objet ou un tableau, il est toujours possible de le modifier. On a également Object.freeze et Object.seal, mais franchement, vous avez déjà vu des gens recommander d'utiliser ça à une large échelle ? Non, c'est trop compliqué en pratique, surtout quand on utilise des dépendances externes.

Le typage statique est également très intéressant pour détecter des erreurs. Et Elm en fait un usage très instructif : non seulement, il détecte les erreurs, mais il explique pourquoi et permet d'apprendre certaines subtilités du langage (parfois, on gagne juste un temps fou en détectant une typo).

Ici, l'héritage du JavaScript pèse lourd dans la balance. Il y a trop de pièges, trop de comportements qui demandent une attention permanente (perdre le this, se tromper dans la portée d'une variable).

Les outils

J'en ai parlé au-dessus : le compilateur d'Elm fait des merveilles. Elixir a également des outils très solides. Plusieurs des langages ci-dessus ont des fmt, à la manière de gofmt, pour formater le code d'une manière standard. Je ne suis pas un utilisateur d'IDE, mon Neovim me convient bien, mais ça ne veut pas dire que je refuse l'aide d'outils pour m'aider dans mes activités de codage.

Et là encore, JavaScript est à la traîne. Oh, il ne manque pas d'outils ! C'est même l'inverse, on croule sous les gulp, grunt, broccoli, brunch, webpack, browserify, rollup, babel, estlint, jslint, jscs, jshint, etc. Et on s'y perd. D'un projet à l'autre, ce n'est jamais la même chose, jamais les mêmes règles pour le lint. Un coup, ce sont des require CommonJS, l'autre des import/export d'ES6. Et je ne parle même pas du temps fou qu'il faut passer pour réussir à les compiler. Et quand vous avez un outil qui marche, vous pouvez être sûr que dans quelques mois, ses plugins pour faire du sass ou générer des sprites ne seront plus maintenus. Ce n'est pas pour rien que l'expression JavaScript fatigue est très à la mode.

Un écosystème verdoyant

On parle souvent du nombre impressionnant de paquets publiés sur npm. Pourtant, quand on y regarde de plus près, c'est loin d'être reluisant. On trouve des tonnes de paquets qui sont des expérimentations qui n'ont jamais dépassé le stade de la version 0.0.x. Ensuite, il y a tous ces plugins d'intégration d'un outil avec l'autre (sails-generate-backend-gulp-webpack pour donner un exemple du ridicule que l'on atteint).

La bibliothèque standard de JavaScript me désole toujours autant. Il y a bien lodash, mais franchement j’aimerais bien avoir pick ou debounce dans la bibliothèque standard.

Node.js ne fait pas mieux. Il faut toujours installer un paquet pour faire un mkdir -p, ou un rm -rf (d'ailleurs, vous risquez de vous retrouver avec rimraf et del si vous ne faites pas attention).

Enfin, certaines entreprises ont les dents longues et il n'est pas rare d'en venir aux drames pour parfois faire avancer les choses. On se rappelle du fork io.js pour soustraire nodejs de l'emprise de Joyent. Plus récemment, c'est le principal contributeur d'express qui a jeté l'éponge (et même deux fois) pour des raisons similaires. On peut aussi s'amuser de github transformé en bac à sable. Mais ce qui est sûr est qu'il y a bien des progrès à faire dans ce domaine.

La complexité du langage

Dernier point, avec ES6 et les versions futures, je trouve le langage de plus en plus complexe. Mais surtout cette complexité ne répond pas à mes besoins. C'est sûrement très bien d'avoir des décorateurs des observables et des symboles. Mais je trouve déjà les styles de code JavaScript très disparates et je ne pense pas qu'ajouter de nouvelles fonctionnalités comme celles-ci apportent vraiment quelque chose de suffisamment intéressant pour compenser la complexité induite.

Au final, je suis de plus en plus déçu. Il y a sûrement certains points qui me sont personnels et d'autres qui sont partagés par la communauté. En tout cas, je vois cela comme une grosse faiblesse du JavaScript, et comme je ne vois pas les choses changer dans les prochains mois ou années, j'ai l'impression que le JavaScript va droit dans le mur. Je vais bien sûr continuer à utiliser du JavaScript au quotidien. Sa place dans les navigateurs en fait quelque chose de trop difficile à éviter. Mais je vais aussi continuer à regarder ce qui se fait ailleurs et probablement finir par détester le JavaScript.

Et vous, quels sont vos langages du moment ? Et que font-ils mieux que JavaScript ?

# Go

Posté par Ririsoft le 02 mars 2016 à 22:30. Évalué à 10.

Je suis sur Go en ce moment. J'aime beaucoup sa simplicité, les variables typées, la compilation statique et la cross compilation. Je suis entrain d'abandonner Python, qui avait une grande place dans mon coeur, pour Go. Travaillant sur une grande diversité d'OS et d'architectures, n'ayant pas toujours les mains libres sur l'OS où je suis, l'argument décisif c'est la facilité de déployer un programme Go par rapport à la galère que c'est de déployer un programme Python (PYTHONPATH, Python 2.6, 2.7, 3.1, 3.2 …).

Sur le Javascript je te rejoins à 100%. Il parait accessible quand on le découvre, mais je le mets en numéro 2 derrière le C++ dans la liste des langages difficiles et piégeux. Du coup je l'utilise en mode très minimaliste, pas de programmation objet, surtout pas de prototypes, pas d'abus des promises (qui sont quand même assez élégantes il faut le reconnaitre) et surtout aucun framework.

D'ailleurs quelque soit le langage j'en ai ras le bol des frameworks. Je préfère recoder un truc minimaliste pour mon besoin qu'utiliser une usine à gaz dont j'utilise 1% des fonctionnalités.
- [^] # Re: Go
  
  Posté par Antoine le 03 mars 2016 à 13:16. Évalué à 8.
  
  Les trucs minimalistes, c'est bien quand on a des besoins minimaux et qui le restent. Si tes besoins (ou ceux de ton employeur, de tes utilisateurs ou clients…) évoluent et grandissent, d'ici quelques années ton truc minimaliste sera devenu un genre de framework à part entière, mais moins pensé, moins bien maintenu, plus difficile à faire évoluer.
  - [^] # Re: Go
    
    Posté par freepius (site web personnel) le 03 mars 2016 à 16:08. Évalué à 7.
    
    Ou alors il y a l'utilisation de micro-frameworks, qui offrent les composants minimaux et qui n'imposent souvent aucune organisation strict du code.
  - [^] # Re: Go
    
    Posté par wilk le 04 mars 2016 à 12:17. Évalué à 9.
    
    Tout dépend de ce qu'on appelle un framework ?
    Je constate plutôt l'inverse de ce que tu décrits, un gros framework (genre RoR ou Django) rend de plus en plus difficile toute évolution car il y a trop d'effet de bords et de surcouches à maintenir. En revanche un framework minimaliste comme Pyramid permet de faire évoluer un code dans n'importe quelle direction beaucoup plus facilement et surtout sans avoir à tout réécrire. Combien de projets on voit partis de RoR ou Django être réécrits entièrement car arrivés à une impasse ? On accuse bien trop souvent le langage alors que le problème vient du framework à mon avis.
    
    Un critère que je trouve pertinent est de pouvoir conserver un même code d'un framework à l'autre. C'est ce que j'ai pu faire sur des applis qui datent de plus de dix ans et que je fais évoluer au fil de l'eau justement par ce que je n'ai jamais utilisé de gros framework. C'est aussi ce qui me permet de réécrire une partie en Go sans avoir à toucher à l'architecture ni à abandonner et réécrire ce qui peut très bien rester en Python.
    
    J'aime bien Go pour ce même aspect minimaliste qu'on retrouvait au début en Python et qui a hélas été un peu perdu. Cet aspect me semble justement primordial pour la maintenance sur le long terme.
    - [^] # Re: Go
      
      Posté par barmic le 04 mars 2016 à 21:32. Évalué à 3.
      
      Je constate plutôt l'inverse de ce que tu décrits, un gros framework (genre RoR ou Django) rend de plus en plus difficile toute évolution car il y a trop d'effet de bords et de surcouches à maintenir.
      
      Je trouve que c'est exactement l'inverse et je en trouve pas que c'est un problème. Les frameworks minimalistes ont une durée de vie généralement bien plus courte et sont promptes à casser la compatibilité (tu parle de pyramid, les débuts de pyramid ont étaient houleux).
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Go
        
        Posté par wilk le 05 mars 2016 à 11:08. Évalué à 4.
        
        C'est bien pour ça que j'insiste sur un des avantages des micros frameworks qui est de pouvoir être changés facilement au cas où ça tournerait mal (ou que l'app évolue dans un sens différent), ce qui est loin d'être évident avec un plus gros et qui entraîne d'énormes problèmes pour faire évoluer le framework lui-même. Alors oui, le gros framework ne casse pas la compatibilité, mais pour cause, il n'évolue plus et au bout d'un moment on change tout, le langage avec l'eau du bain !
        
        On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.
        
        [^] # Re: Go
        
        Posté par GuieA_7 (site web personnel) le 05 mars 2016 à 17:29. Évalué à 5.
        
        Mouais, je ne me suis pas vraiment convaincu. Lorsque tu as 30K lignes de template Machin et 50K lignes de code utilisant l'ORM Bidule, quand bien même tu peux changer ton moteur de template ou ton ORM, tu ne vas pas le faire car tu devras quand même réécrire énormément de choses. Alors oui tu vas peut être pouvoir changer des composants secondaires, mais je pense que le choix des composants principaux se fera au début du projet et ne changera plus lorsqu'une masse critique de code sera atteinte.
        
        On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.
        
        Lorsque ton code grossi, il devient son propre boulet. Regarde FireFox ou OpenOffice (programmes que je respectent énormément mais qui illustreront très bien mon propos): ils n'utilisent pas de framework, pourtant les faire évoluer est très complexe, même si leurs développeurs sont eux mêmes écrits la plupart du code, parce que les décisions de design d'il y a plus de 15 ans ne sont plus forcément pertinentes aujourd'hui etc… Et OpenOffice passerait volontiers à Qt (un framework donc) si ça ne représentait pas tant de travail que ça de changer son propre code tout-écrit-à-la-main-sans-dépendance-à-un-framework.
        
        Lorsqu'il y a aura pléthore de programmes en Go de plusieurs millions de ligne, que les gens auront essayé de s'en servir pour plein de choses pour lesquelles il n'était pas prévu à la base (ce qui est naturel et moteur de progrès), tu en trouveras plein des programmes en Go qui se traînent des boulets.
        
        [^] # Re: Go
        
        Posté par wilk le 05 mars 2016 à 20:02. Évalué à 3.
        
        J'ai des applis qui durent depuis plus de dix ans donc ça m'arrive assez souvent de changer un composant principal. Je préfère changer composant par composant que tout d'un coup. Si je dois démarrer une nouvelle app avec un autre moteur de template, je n'ai pas envie d'avoir à réaprendre un nouveau méga-framework et changer d'orm pour autant.
        Mais bon, je ne cherche pas à convaincre, c'est juste mon expérience après avoir étudié et essayé les deux.
        
        [^] # Re: Go
        
        Posté par GuieA_7 (site web personnel) le 06 mars 2016 à 00:18. Évalué à 4.
        
        Mais bon, je ne cherche pas à convaincre, c'est juste mon expérience après avoir étudié et essayé les deux.
        
        Je ne doute pas que ton expérience soit intéressante, mais tu donnes peu de détails sur cette dernière qui permettrait de donner une idée de son aspect universel (si tu l'as expérimentée sur 12 applis de 500K lignes dans 5 langages, ce n'est pas pareil que 3 applis de 150 lignes dans 1 langage), tout en balançant des généralités ("les micro-frameworks c'est mieux sur le long terme").
        
        Personnellement je bosse quotidiennement sur une application en Django depuis 2009 (et le prototype date de 2007), et la maintenance n'est pas un problème, sachant qu'on a commencé avant la 1.0, et qu'on utilise actuellement la 1.8. Il nous arrivent régulièrement d'atteindre les limites du framework, et je ne veux absolument pas à dire qu'il est parfait (non il est même très perfectible) ni lui faire spécialement de publicité (il n'en a pas besoin, et des tas d'outils de qualité bénéficient de moins de visibilité). Mais au final ce qui me limite le plus c'est mon propre code, et les quelques problèmes techniques que me posent le framework sont complètement anecdotiques par rapport à tout ce qu'il peut m'apporter par ailleurs.
        
        Maintenant j'admets tout à fait que dans l'absolu le design monolithique de Django est moins élégant que le design d'un Pyramid par exemple; et je suis content qu'il existe des alternatives à la philosophie différente. Mais en l'occurrence Pyramid n'existait pas quand on a commencé le projet (je ne sais plus si Pylons existait à l'époque) ; je serai bien incapable de dire ce qui se serait passé si on avait utilisé autre chose (il faudrait une machine à voyager dans le temps pour ça), mais vu que Django a évolué de manière efficace (en cassant des choses quand il le fallait, mais en essayant de rendre les cassures les moins pénibles possibles), je doute que les choses auraient pu se passer beaucoup mieux.
        
        [^] # Re: Go
        
        Posté par wilk le 06 mars 2016 à 10:48. Évalué à 3.
        
        Tu as raison il faut préciser le contexte sinon on ne sait pas de quoi on parle.
        Mon créneau c'est beaucoup de petites et moyennes (1 à 15K lignes de code très concis) applications web très spécifiques, dont certaines vont durer très longtemps et évoluer dans des sens non définis au départ et que je gère quasiment seul. Genre des gestion de chantiers qui commencent gérées au siege, puis par des agences, puis par des chefs d'équipe sur leur smartphone etc… Après ça sera une gestion de résidents d'une maison de retraite qui pointent leur repas, leur ménage etc. Ou bien un site de vente de livres, où les éditeurs se regroupent puis se séparent puis se regroupent à nouveau, un jeu en ligne, un service de calcul d'itinéraire… Je suis également admin sys de tout ça, cad quelque dizaines d'apps en cours. Et c'est chouette de rentabiliser sa passion :-)
        
        Donc mon casse tête c'est de pouvoir réutiliser le maximum de composants pour ne pas réinventer et réapprendre la roue. A court terme un bon framework c'est royal pour moi, j'essaye souvent.
        Mais sachant que les composants et frameworks vont avoir une durée de vie plus courte que certaines applis et qu'ils seront utilisés dans des contextes parfois très différents, il faut impérativement que j'évite les effets de bords, dans l'instant et sur la durée, qu'en faisant évoluer un composant ça n'impacte pas les autres mais qu'une ancienne appli puisse quand même en bénéficier facilement un jour.
        
        Si j'avais utilisé des gros frameworks, j'aurai du en utiliser plusieurs en même temps dont certains qui n'existeraient plus. Imagine si j'avais à maintenir des applis Zope et Django en même temps avec une demande d'évolution vers les websockets ou une contrainte de perf…
        En revanche, avec un micro framework comme Pyramid je trouve un outil qui me permet de remplacer progressivement des composants de mon framework perso sans avoir à changer une ligne de code de mon appli. Donc j'achète, au pire je revend plus tard, le coût de la manoeuvre reste faible. Je prend Pyramid comme exemple car la doc explique de manière très détaillée cette philosophie, qui plus est par un ancien de Zope qui connaît bien le domaine, ça vaut le coup d'être lu même si on ne l'utilise pas.
        
        Je faisais l'analogie avec la philosophie Go dans le sens où les auteurs ont décidés d'accepter une fonctionnalité du langage que s'ils étaient tous d'accord. J'applique la même règle avec mes composants perso, pour en faire une lib que je vais partager il faut que toutes mes applis soient d'accord, même la plus ancienne. En attendant : "une petite copie vaut mieux qu'une grosse dépendance" (Rob Pike).
        
        C'est sûrement pas universel mais c'est assez marrant de partager certains points de vue entre Google et un indep ! J'ai vraiment été surpris. De la même manière quand je me suis aperçu que je pouvais utiliser Python pour le boulot, un langage qui semblait fait pour les enfants !
        
        [^] # Re: Go
        
        Posté par barmic le 05 mars 2016 à 17:51. Évalué à 4.
        
        C'est bien pour ça que j'insiste sur un des avantages des micros frameworks qui est de pouvoir être changés facilement au cas où ça tournerait mal (ou que l'app évolue dans un sens différent), ce qui est loin d'être évident avec un plus gros et qui entraîne d'énormes problèmes pour faire évoluer le framework lui-même. Alors oui, le gros framework ne casse pas la compatibilité, mais pour cause, il n'évolue plus et au bout d'un moment on change tout, le langage avec l'eau du bain !
        
        Je ne suis pas d'accord avec cette dichotomie. CDI qui est un énorme framework (on parle de Java EE des familles) est très peu intrusif, par exemple. Rx qui est relativement petit va lui lourdement impacter ton code.
        
        Pour moi il ne faut pas dire, « je prends un framework minimaliste parce que je peux le changer », mais je sais où j'ai mes adhérences et tu as quelques cas :
        
        le code dont tu ne peux te passer (hibernate es-tu là ?)
        
        le code dont tu peux te passer facilement (bonjour dagger)
        
        le code dont l'interface est normalisé (PEP, JSR voir IETF/what ever)
        
        Chercher à être hors de toute dépendance, n'a pas grand intérêt AMHA.
        
        On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.
        
        Le langage qui intègre un serveur web dans sa bibliothèque standard ? Ouai :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par wilk le 05 mars 2016 à 20:10. Évalué à 3.
        
        Je ne cherche pas à être hors de toute dépendance, mes projets dépendent souvent de postgresql et reportlab par exemple mais aucun d'eux ne m'oblige à utiliser un orm quelconque ou à mettre mes fichiers de conf à tel endroit par exemple.
        On n'utilise pas les mêmes frameworks du coup j'ai l'impression que ça commence à devenir difficile de savoir de quoi on parle…
        
        [^] # Re: Go
        
        Posté par barmic le 05 mars 2016 à 22:13. Évalué à 2.
        
        On n'utilise pas les mêmes frameworks du coup j'ai l'impression que ça commence à devenir difficile de savoir de quoi on parle…
        
        Un framework c'est un morceau de code qui te forunis un ou plusieurs service et qui va structurer ton code (il peut être non-opiniated, mais son boulot c'est de te permettre d'organiser ton code pour accéder aux fonctionnalités qu'il propose).
        
        aucun d'eux ne m'oblige à utiliser un orm quelconque
        
        Tu ne désérialise pas tes données dans un objet métier ? Tu te contente d'utiliser des dictionnaires ? Si non tu es obligé d'utiliser un orm (même si c'est le tiens :) ). Hibernate s'utilise très bien comme ça, il faut juste créer une DAO par dessus son objet qui gère la connexion. Changer d'ORM c'est réécrire l'implémentation de ta DAO (tu vire les annotations de tes objets métier et tu les utilise comme tu veux).
        
        Un framework vraiment intrusif c'est RxJava. Il te pousse à utiliser son propre conteneur (Observable) et à l'utiliser de bout en bout dans tes traitements. Retirer Rx d'un programme c'est très impactant.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par wilk le 06 mars 2016 à 08:54. Évalué à 4.
        
        Je ne dis pas que je n'utilise pas d'orm, je dis juste que si je veux changer d'orm je ne veux pas avoir à changer de template pour autant.
- [^] # Re: Go
  
  Posté par barmic le 03 mars 2016 à 17:59. Évalué à -3.
  
  D'ailleurs quelque soit le langage j'en ai ras le bol des frameworks. Je préfère recoder un truc minimaliste pour mon besoin qu'utiliser une usine à gaz dont j'utilise 1% des fonctionnalités.
  
  D'ailleurs quelque soit le langage j'en ai ras le bol ~~des frameworks~~ d'apprendre. Je préfère recoder ~~un truc~~ mes bugs ~~minimaliste~~ pour mon besoin qu'utiliser une usine à gaz dont ~~j'utilise 1% des fonctionnalités~~je connais rien.
  
  Tu trouve pas marrant tous ces gens qui créent des usines à gaz ? La plupart des gens sont vraiment des crétins finis tu ne trouve pas ? À croire qu'il n'y a que quelques personnes dont toi qui savent ce que ça veut dire que coder pour de vrais.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Go
    
    Posté par Tit le 04 mars 2016 à 11:10. Évalué à 4.
    
    Je me demandais pourquoi ton message intéressant dans le fond a été moinssé alors que celui d'antoine qui dit à peu près la même chose a été plussé. Je suppose que c'est à cause de son coté aggressif, et c'est vrai qu'il ne me semble pas nécessaire que tu t'en prennes à chicha pour faire passer ta pensée.
    - [^] # Re: Go
      
      Posté par barmic le 04 mars 2016 à 11:46. Évalué à 8.
      
      C'est probablement parce qu'on ne dit pas la même chose…
      
      Il dit simplement que les frameworks sont pas si mal quand ils sont petits et non-opiniated. Je cherche à montrer que beaucoup de gens disent du mal des framework principalement parce qu'ils ne les maîtrisent et préfèrent affirmer que le framework est mauvais plutôt d'expliquer qu'ils n'ont pas envie de prendre le temps d'apprendre, comprendre, puis maîtriser le dit framework.
      
      Je suppose que c'est à cause de son coté aggressif, et c'est vrai qu'il ne me semble pas nécessaire que tu t'en prennes à chicha pour faire passer ta pensée.
      
      Tout comme parler ici, n'est pas nécessaire (surtout pour avancer une idée qui est totalement à contre courant de ce que la majorité avance), mais je ne suis pas là pour faire un concourt de karma.
      
      J'ai un ton un peu condescendant, parce que je trouve ridicule, les gens qui affirment des grandes vérité (« les gros frameworks c'est des usines à gaz ») sans vraiment prendre en compte pourquoi est-ce qu'il y a autant de gens qui travaillent sur ce genre de choses.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Go
        
        Posté par Guillaume Denry (site web personnel) le 04 mars 2016 à 11:54. Évalué à 2.
        
        Peut-être aussi que vous ne parlez pas de la même chose avec chicha. Par exemple, installer jQuery juste pour passer des requêtes Ajax est devenu un peu too much, quand il existe des trucs comme Reqwest ou Superagent ?
        Par contre, comme toi, je ne crois pas du tout à "je me refais les choses dans mon coin en mode minimaliste", il y a des cas où tu ne peux pas y couper si tu veux vraiment avancer dans ton métier, tu dois "monter sur les épaules des géants".
      - [^] # Re: Go
        
        Posté par wilk le 04 mars 2016 à 12:37. Évalué à 6.
        
        Je suis également surpris par le ton que tu emplois contrairement à tes habitudes…
        Chicha a juste dit qu'il en avait raz le bol lui-même pour ses propres besoins persos ! je ne vois pas où il y a une généralité là dedans ? Mais pas de quoi en faire un fromage, ça reste marrant à lire.
        
        Par rapport à ton affirmation que beaucoup de gens disent du mal des frameworks parce qu'ils ne les maîtrisent pas, et bien là encore je constate exactement l'inverse, ce que j'ai écris sur les gros frameworks je ne l'applique pas uniquement aux frameworks que je ne connais pas bien mais également aux miens ! Quand j'utilisais Java, fier de la philosophie du langage qui incitait à faire les choses bien comme il faut je me suis écris à l'époque quelques bon gros framework qui me permettait d'aller hyper vite sur certains projets. En revanche comme je l'expliquait, sur le long terme j'ai du tout réécrire pour faire évoluer les applications dans des sens trop différents les unes des autres, ça m'a servi de leçon !
        
        Ne m'incendie pas, c'est pas une généralité c'est mon expérience perso (petits projets qui évoluent sur du long terme) ;-)
        
        [^] # Re: Go
        
        Posté par barmic le 04 mars 2016 à 19:55. Évalué à 3.
        
        j'utilisais Java, fier de la philosophie du langage qui incitait à faire les choses bien comme il faut
        
        On en doit pas utiliser le même Java ;-)
        Jette un œil à Vert.x, spark (le framework web pas le framework de big data), jOOQ (oui c'est pas libre) ou même a du Spring récent tu va être surpris.
        
        En revanche comme je l'expliquait, sur le long terme j'ai du tout réécrire pour faire évoluer les applications dans des sens trop différents les unes des autres, ça m'a servi de leçon !
        
        Je vois pas bien en quoi un framwork va te limiter là dedans. À moins d'utiliser hibernate et de vouloir passer à une base NoSQL qui n'est pas géré par hibernate OGM. Mais c'est une question d'adhérence entre ton code et celui du framework ou de l'intrusivité du framework dans ton code. Selon ce que cherche à faire le framework et le langage que tu utilise tu n'a pas forcément le choix.
        
        Personnellement, ce que je trouve important c'est de savoir avec quels frameworks j'ai une adhérence forte ou pas. Après tu as des choix qui te permettent de gérer ça. Le framwork Qt est extrêmement intrusif (en C++ au moins), tu peut tout de même organiser ton code pour maîtriser les portions de code qui en sont dépendants. Il me semble qu'il est utopique d'imaginer avoir tout ton code avec un couplage inexistant.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par wilk le 04 mars 2016 à 20:32. Évalué à 2.
        
        On n'utilise sûrement pas le même java. Celui que j'utilisais était en version 1.x, j'adhérai d'autant plus au framework que c'était le mien !
        Ce que je veux dire par là c'est qu'un framework, même si on le connaît très bien, comporte trop d'effets de bords et de couches à maintenir pour évoluer sans peine sur des projets divers et variés.
        Donc par la suite, en python, j'ai préféré opter pour un framework minimaliste (perso car à l'époque ça n'existait pas) et travailler sur la composition.
        Par exemple je peux utiliser le même framework pour faire du "traversal" http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/traversal.html
        Mais il est difficile de savoir si on parle de la même chose en terme de framework… Autrement dit, je préfère la méthode "Unix" où chaque chose fait une seule chose mais bien et communique avec les autres.
        
        [^] # Re: Go
        
        Posté par wilk le 04 mars 2016 à 20:43. Évalué à 2.
        
        edit: sur les frameworks que tu m'indiques, à vu de nez ça ne me déplaît pas, ça n'est pas ce que je critique, au contraire.
      - [^] # Re: Go
        
        Posté par Lizzie Crowdagger (site web personnel) le 04 mars 2016 à 15:08. Évalué à 3.
        
        «Je cherche à montrer que beaucoup de gens disent du mal des framework principalement parce qu'ils ne les maîtrisent et préfèrent affirmer que le framework est mauvais plutôt d'expliquer qu'ils n'ont pas envie de prendre le temps d'apprendre, comprendre, puis maîtriser le dit framework.»
        
        Cela dit ça me parait pas en soi une mauvaise raison. Personnellement, je sais que ça me fatigue que beaucoup d'exemples de code que je peux trouver quand je cherche de la doc sur javascript dépendent de gros frameworks parce qu'effectivement en général les fois où je fais du javascript c'est pour une fonction de 10 lignes, ça arrive assez peu souvent pour que je doive googler le mot-clé pour déclarer une fonction et j'ai pas spécialement envie d'apprendre un framework alors que j'ai juste besoin d'une fonction qui prend une valeur en entrée et renvoie une valeur en sortie, point. J'irais pas dire que ces frameworks sont mauvais pour autant, mais par contre le fait de tomber avant tout sur des exemples dépendant de frameworks quand tu cherches à faire un truc basique qui n'en a pas besoin ça peut être rebutant (surtout quand t'as l'impression qu'il te faudrait déjà investir un temps considérable uniquement pour choisir quel framework utiliser).
        
        [^] # Re: Go
        
        Posté par barmic le 04 mars 2016 à 19:22. Évalué à 2.
        
        Cela dit ça me parait pas en soi une mauvaise raison.
        
        Tout à fait. C'est juste plus honnête de dire qu'on ne veut pas s'investir dans un framework que de le considérer comme nul/bidon/etc.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par wilk le 04 mars 2016 à 20:38. Évalué à 4.
        
        Personne n'a prétendu que les frameworks étaient nuls. Au contraire, ce sont souvent des monuments d'ingénierie. Mais ça ne signifie pas pour autant qu'ils soient adaptées à tous les cas de figure, surtout sur le long terme.
        
        [^] # Re: Go
        
        Posté par barmic le 04 mars 2016 à 21:37. Évalué à 1.
        
        Du coup ça me fait penser à une question piège d'entretiens d'embauche :
        
        Quel est votre design pattern préféré ?
        
        Ce à quoi il faudrait répondre « aucun, ça dépend du besoin ».
        
        Personne n'a prétendu que les frameworks étaient nuls.
        
        Juste des usines à gaz…
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par Lizzie Crowdagger (site web personnel) le 05 mars 2016 à 00:16. Évalué à 6.
        
        (Hors sujet)
        
        Du coup ça me fait penser à une question piège d'entretiens d'embauche :
        Quel est votre design pattern préféré ?Ce à quoi il faudrait répondre « aucun, ça dépend du besoin ».
        
        J'ai déjà vu aussi appliqué aux langages de programmation, et j'ai jamais compris la logique d'opposer « avoir un préféré » et « adapter au besoin ». Je veux dire, si je je préfère faire à manger que faire la vaisselle c'est pas pour autant que si je sors de table je vais me préparer un deuxième repas plutôt que de laver mon assiette :P
        
        [^] # Re: Go
        
        Posté par Dr BG (site web personnel) le 05 mars 2016 à 10:06. Évalué à 5.
        
        Je ne sais pas ce que pensent les autres, mais j'aime bien demander quel est le langage préféré et surtout pourquoi. Je me fiche du langage,je veux juste voir si le candidat à des opinions, réfléchit aux outils qu'il utilise, est curieux, etc.
        
        [^] # Re: Go
        
        Posté par barmic le 05 mars 2016 à 10:33. Évalué à 4.
        
        j'ai jamais compris la logique d'opposer « avoir un préféré » et « adapter au besoin »
        
        Alors, la question est idiote, mais la relation est pourtant évidente. Ton choix sera porté par tes goûts. Et tu aura tendance à choisir l'outil qui te plaît plus facilement que celui qui est le plus adapté. Ce qui n'est pas forcément un mal, il vaut mieux quelque chose qui correspond correctement que tu maîtrise que l'outil exact que tu ne sais pas utilisé.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par Lizzie Crowdagger (site web personnel) le 05 mars 2016 à 16:35. Évalué à 3.
        
        Certes, mais ce que je voulais dire c'est surtout que je ne vois pas en quoi le fait de ne pas avoir (ou montrer) d'opinion serait la démonstration de plus de capacité à choisir le bon outil : tu peux aussi avoir tendance à utiliser tout le temps la même chose simplement parce que c'est la seule que tu connais, ou parce que t'en as plus l'habitude, etc.
        
        [^] # Re: Go
        
        Posté par barmic le 05 mars 2016 à 17:57. Évalué à 3.
        
        À mon avis, ce que le recruteur veux c'est que tu lui montre que tu as conscience de ce biais. Si quelqu'un te recale parce que tu lui a dis « que tu trouve élégant les décorateurs, mais qu'il faut voir au cas par cas parce que ça n'est pas adapté à tous les besoins », mon avis c'est que le recruteur s'est planté.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Go
        
        Posté par Elfir3 le 05 mars 2016 à 14:45. Évalué à 2.
        
        Quel est votre design pattern préféré ?
        Ce à quoi il faudrait répondre « aucun, ça dépend du besoin ».
        
        C'est triste ton avis sur les design patterns.
    - [^] # Re: Go
      
      Posté par barmic le 05 mars 2016 à 18:03. Évalué à 2.
      
      Je suppose que c'est à cause de son coté agressif, et c'est vrai qu'il ne me semble pas nécessaire […]
      
      Et pourtant je pense que ça l'est. Cela suscite des débats un peu plus intéressants que de rester dans une ambiance feutrer en arrondissant les angles et en cherchant un consensus mou à tout prix.
      
      On est pas dans un milieu diplomatique où chaque phrase doit être pesée et sous-pesée parce que, grand dieux ! Il faut que j'ai mon karma qui grimpe !
      
      J'ai déjà expliqué pourquoi je peux avoir ce genre de comportement : https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      
      Que beaucoup de membres, ne soient pas capable de comprendre ça ne me dérange pas.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Go
  
  Posté par anaseto (site web personnel) le 03 mars 2016 à 19:37. Évalué à 7.
  
  Je suis sur Go en ce moment. J'aime beaucoup sa simplicité, les variables typées, la compilation statique et la cross compilation.
  
  Je me suis mis à apprendre Go il n'y a pas longtemps, et je dois dire que j'ai été très agréablement surpris par ce langage. C'est peut-être le premier langage généraliste que j'apprends où au bout de trois ou quatre jours j'ai l'impression que je peux comprendre à peu près n'importe quel bout de code écrit dans le langage, sans devoir démêler des astuces tordues ou des abstractions complexes (un fichier au hasard d'un programme complexe comme le compilo lui-même a de bonnes chances d'être assez accessible).
  
  Et si le langage est simple, il n'est pas pour autant simpliste : même s'il ne permet pas une concision extrême, il est relativement concis sur plein de cas courants, et a fait quelques choix pragmatiques qui me semblent plutôt bons, comme le fait d'avoir des tableaux dynamiques (slices) et des maps de base, utilisables avec une syntaxe pratique, ce qui le rapproche des langages de script, mais avec des avantages du typage statique.
  Et j'aime la qualité des divers outils (gofmt, godef, etc.), qui permettent à un éditeur de texte de fournir de bons plugins pour le langage ; qualité qui doit beaucoup à la simplicité du langage, je pense.
  
  D'un point de vue concision et puissance du système de types il y a du coup quelques sacrifices qui sont faits (pas de généricité, pas de types algébriques, pas de classes avec héritage, etc.), mais le mécanisme fournit pour réutilisation de code (les interfaces) offre quand même beaucoup pour pas cher (moins compliqué pour l'implémentation, et moins à apprendre pour l'utilisateur), et les fonctions du langage pour les types de base comme les maps et les slices sont polymorphes, donc en pratique ces manques ne doivent pas souvent être très gênants. Bref, c'est un langage où tout est balance et compromis entre divers critères (parfois philosophiques même), mais le résultat est intéressant.
- [^] # Re: Go
  
  Posté par Xavier Combelle (site web personnel) le 07 mars 2016 à 13:13. Évalué à 2.
  
  Je suppose dans la liste des langages difficile et piégeux, tu mets php en position 0. ( A moins que tu le considère pas comme un langage)
# La force de l'inertie fait que rien ne changera

Posté par Ontologia (site web personnel) le 02 mars 2016 à 23:35. Évalué à 10.

Javascript est là, et utilisé par des milliards de pages. Sa syntaxe ressemble à C/Java. Donc il est assimilable par tout le monde car il est devenu le standard du consensus mou.

Certes, nous, amoureux des beaux langages, rageons devant ses défauts.
Mais le développeur moyen, dont c'est juste le métier et qui ferait du BrainFuck si on lui en donnait l'ordre (pour avoir sa paye à la fin du mois), constitue le gros des bataillons de programmeurs dans le monde.

Nous sommes des vieux développeurs, on développe des choses un tant soit peu complexes, mais la plupart développent des sites basiques, des logiciels de gestion structurés autour du triptyque Un Client-Un Service-Un contrat…
(Aucun mépris là dedans je précise, chacun ses passions)

Javascript restera parce que tous ces langages sont et resteront des langages de niches pour faire plaisir à de vieux développeurs ou a des matheux.
Les grosses boites ne prendront jamais le risque de changer de technos, sans compter qu'il faudrait trouver des compétences rares, etc…

Bref, relis Crossing The Chasm de Geoffrey Moore, et tu verras, on est éternellement condamné à voir des langages de merde rester les leaders du marché…

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: La force de l'inertie fait que rien ne changera
  
  Posté par matthieu bollot (site web personnel, Mastodon) le 03 mars 2016 à 00:37. Évalué à 10.
```
on développe des choses un tant soit peu complexes, mais la plupart développent des sites basiques, des logiciels de gestion structurés autour du triptyque Un Client-Un Service-Un contrat…
(Aucun mépris là dedans je précise, chacun ses passions)
```
  On développe des sites dans le but qu'ils soient utilisés et servent à quelque chose mais certains développent juste des POC pour se faire plaisir sans faire quoi que ce soit de grand intérêt (aucun mépris là dedans)
- [^] # Re: La force de l'inertie fait que rien ne changera
  
  Posté par barmic le 03 mars 2016 à 11:00. Évalué à 4.
  
  Aucun mépris là dedans je précise, chacun ses passions
  
  Il ne suffit pas de l'énoncer pour que ce soit vrai, hein ?
  
  Non, il y a des tas de gens qui font des choses très sophistiquées avec ce langage que tu conchie. Il suffit de voir tout ce qui sort aujourd'hui autour de node y compris hors d'un mode serveur ou navigateur (par exemple en CLI).
  
  C'est dommage de se fermer comme ça en se disant que parce qu'on aime pas le langage tout ceux qui l'utilisent sont des incompétents/simples/noobs/non-passionnés/…
  
  Ta passion c'est de kiffer avec des langages qui ont du potentiel et qui restent à jamais juste du potentiel (« Oh oui ! On est 7 dans le monde à comprendre ce concept (et on a pas encore trouvé de cas d'utilisation), comme c'est top bon ! »). D'autres préfèrent prendre des langages utilisé et subvenir à des besoins pratiques du mieux qui leur ai possible. Je ne vois pas en quoi c'est moins passionnés.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: La force de l'inertie fait que rien ne changera
    
    Posté par Ontologia (site web personnel) le 03 mars 2016 à 13:29. Évalué à 6. Dernière modification le 03 mars 2016 à 13:48.
    
    Il ne suffit pas de l'énoncer pour que ce soit vrai, hein ?
    
    J'ai 15 ans de linuxfr derrière moi, et je précise pour éviter les susceptibilités qui pourraient survenir :-)
    
    Non, il y a des tas de gens qui font des choses très sophistiquées avec ce langage que tu conchie. Il suffit de voir tout ce qui sort aujourd'hui autour de node y compris hors d'un mode serveur ou navigateur (par exemple en CLI).
    
    On s'est mal compris, j'aime bien Javascript. Du moment que je peux utiliser lodash ou map/fold/filter, je trouve que c'est un langage très bien.
    Kaane le dit très bien, plus bas, Javascript est un langage fonctionnel dans le fond, et ça ne peut que me plaire.
    J'en ai codé quelques milliers de lignes, et même si c'est un peu limité, j'ai bien aimé.
    Bref, un peu limité mais sympa !
    
    C'est dommage de se fermer comme ça en se disant que parce qu'on aime pas le langage tout ceux qui l'utilisent sont des incompétents/simples/noobs/non-passionnés/…
    Ta passion c'est de kiffer avec des langages qui ont du potentiel et qui restent à jamais juste du potentiel (« Oh oui ! On est 7 dans le monde à comprendre ce concept (et on a pas encore trouvé de cas d'utilisation), comme c'est top bon ! »). D'autres préfèrent prendre des langages utilisé et subvenir à des besoins pratiques du mieux qui leur ai possible. Je ne vois pas en quoi c'est moins passionnés.
    
    J'ai du mal m'exprimer.
    Comme je disais, chacun ses passions, et je connais plein de gens qui font des choses fantastiques en js/html5/css, que je ne prendrais sûrement pas pour des incompétents/simples/noobs/non-passionnés/…
    Javascript leur suffit.
    Un de mes meilleurs amis adore PHP, par exemple. Parce que PHP lui suffit, et il adore le côté crade, donc libre, du langage.
    Chacun son truc.
    Prend aussi en compte tout ceux dont le développement est un métier et pas une passion, c'est d'eux dont je parle, car ils constituent, comme je disais, l'essentiel de la masse des développeurs. Et beaucoup de ces gens là ont des passions très différentes, très intéressantes, ou pas de passions et ont à cœur de s'occuper de leurs proche ce qui est très noble.
    
    Bref, essayez d'établir une quelconque relation d'ordre entre les gens est totalement stupide.
    Je voulais simplement illustrer la force de l'inertie.
    
    Tu te sens blessé/visé par quoi, en fait ?
    
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # Re: La force de l'inertie fait que rien ne changera
      
      Posté par barmic le 03 mars 2016 à 14:42. Évalué à 5.
      
      Tu te sens blessé/visé par quoi, en fait ?
      
      Ni blessé, ni visé. Ce que je fais me plaît, je n'ai pas besoin de l'aval de quelqu'un pour me sentir bien :)
      
      Non c'est juste que je n'aime pas les geeks élitistes qui ont une vision et qui vont dénigrer tout ce qui s'écarte de leur vision (il y en a un paquet, y compris par ici). Si ce n'était pas ta volonté désolé.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: La force de l'inertie fait que rien ne changera
        
        Posté par Ontologia (site web personnel) le 04 mars 2016 à 11:10. Évalué à 6. Dernière modification le 04 mars 2016 à 15:16.
        
        Non c'est juste que je n'aime pas les geeks élitistes qui ont une vision et qui vont dénigrer tout ce qui s'écarte de leur vision (il y en a un paquet, y compris par ici). Si ce n'était pas ta volonté désolé.
        
        J'ai été comme ça, mais maintenant je m'en fou. Professionnellement, je suis maintenant reconnu et je peux travailler avec les technos qui me plaisent, alors qu'avant c'était le festival de technos merdiques et de chefs pas très bons techniquement qui prétendais m'apprendre la vie. J'ai aussi compris que le cerveau de chacun est différent. Je parlais de mon pote qui fais du PHP : il est super à l'aise avec des boucles qu'il imbrique avec dextérité, je l'ai vu en gérer 7 à 8 imbriquées.
        Au bout de 2, je suis déjà complètement perdu. Moi je suis plutôt très à l'aise avec les ensembles que je découpe, filtre, etc…
        Donc j'adore SQL et le fonctionnel et j'ai horreur des boucles et des pointeurs.
        Chacun une façon de pensée avec laquelle il est plus à l'aise. C'est d'ailleurs pour ça que le débat "l'impératif ceymieux meuuuhnon le fonctionnel ceymieux" est complètement débile.
        
        Et je préfère un mec pas passionné qui s'occupe bien de ses proches qu'un geek élitiste impressionnant sans humanité.
        D'ailleurs en dehors de mon boulot, je fais plus de technique, mais de la musique et je vais voir des gens :p
        
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: La force de l'inertie fait que rien ne changera
        
        Posté par Michaël (site web personnel) le 06 mars 2016 à 10:25. Évalué à 3.
        
        Ce que je fais me plaît, je n'ai pas besoin de l'aval de quelqu'un pour me sentir bien :)
        
        Je dis juste ça en passant, mais imagine un peu que tu sois prof en lycée et prononce cette phrase devant une trentaine de pré-ados. ;)
- [^] # Re: La force de l'inertie fait que rien ne changera
  
  Posté par Bruno Michel (site web personnel) le 04 mars 2016 à 10:57. Évalué à 5.
  
  Certes, les langages utilisés par les masses de développeurs évoluent lentement. Mais ils évoluent quand même. Fortran et Cobol disparaissent, PHP et Python ont gagné en popularité. Et ces langages s'améliorent aussi avec le temps. C++, Java et PHP ont fait de gros progrès et auraient sûrement vu leur part de marché décroître si ce n'était pas le cas.
  
  Pour les langages fortement liés à une plateforme (et c'est le cas du JS), ça peut aller beaucoup plus vite. Je ne serais pas surpris qu'Objective-C soit devenu quasiment négligeable devant Swift d'ici quelques années. Bref, même si le développeur moyen, dont c'est juste le boulot, se fout de son langage, il code quand même avec un langage bien meilleur aujourd'hui qu'il y a 20 ans.
  
  Et, en dehors de ces gros langages, il y a de la place pour d'autres langages pour des développeurs qui veulent mieux que ça. Ruby, ou plus récemment Go, sont des langages plus agréables pour le développeur, mais avec un écosystème suffisamment riche pour quand même pouvoir répondre à des besoins plus larges que juste ceux d'une niche très spécifique.
  
  Et pour les grosses boites, il y a aussi du changement. Elles se retrouvent prises dans les technos web et mobiles. Et là, le changement est obligatoire. Elles demandaient du jQuery, maintenant c'est du Angular et on commence à voir du React. Elles veulent maintenant être elles aussi à la pointe. Et des concepts comme "Mobile first", "responsive" ou "continuous deployment" sont des bons moyens pour faire changer les mentalités.
  - [^] # Re: La force de l'inertie fait que rien ne changera
    
    Posté par groumly le 04 mars 2016 à 17:08. Évalué à 4.
    
    Je ne serais pas surpris qu'Objective-C soit devenu quasiment négligeable devant Swift d'ici quelques années
    
    Oui et non.
    Apple met le paquet sur swift, objc est clairement pas un language d'avenir. Mais ya des millions/milliards de lignes de code ecrites en objc et la migration est loin d'etre triviale.
    Me suis fait avoir par le comportement d'overflow ya pas une semaine. On a porte une classe simple ligne a ligne. Un truc simple, on pensait, pas de risques.
    Il se trouve qu'on additionait 2 ints ensembles, facile! Tu parles, foundation nous retournait un NSRange not found dans un cas, qui met le champ "length" a Int.max, et c'est ca qu'on additionait. Il se trouve que swift throw sur un int overflow (c'est voulu).
    5k crashs par jour, et on a detrone le sdk fb dans le top 5 de crashlytics.
    
    On le savait bien sur, mais les reflexes sont la, et a+b pour moi c'est 100% sur.
    Du coup, on va freiner un peu la migration, et ca va nous prendre tellement longtemps de migrer que je suis meme pas sur qu'on porte tout le code un jour. On a des classes pas simples du tout vieilles de 3/4 ans, elles marchent tres bien en prod sur des millions de telephones, pas sur de vouloir prendre le risque de foutre la chtouille la dedans.
    Alors ouais, yavait un bug chez nous, mais entre un utilisateur qui voit une chaine un peu chelou et un hard crash, je prend la chaine chelou.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Clojurescript

Posté par CrEv (site web personnel) le 02 mars 2016 à 23:37. Évalué à 3.
Il manque un langage dans ta liste, Clojurescript. Fonctionnel, élégant, concis, lisible. Certes c'est un dérivé de lisp et donc est plein de parenthèses.

On a vu apparaître les Promise, puis certains ont détourné les générateurs. On parle beaucoup d'async/await. Il n'empêche, on est toujours dans un bourbier, coincé entre des API qui utilisent parfois des callbacks, parfois des promises.

C'est un des points que j'apprécie vraiment le moins aujourd'hui dans le monde javascript. Ok, avant il y avait des callbacks et c'était pas terrible. Mais ce qu'on fait aujourd'hui avec les promises n'est pas tellement mieux, au prix d'une lourdeur d'écriture et de, en général, une difficulté à avoir quelque chose de proprement testable. Certes async/await va dans le bon sens, mais il y aura encore des Promises.

Dans mon taff je bosse parfois sur un projet basé sur Electron. Au final nous avons choisis de faire un backend Go et un frontend à base de clojurescript. Tellement plus agréable. Et l'utilisation de core.async répond tellement mieux à la gestion asynchrone que les promises que ça donne encore moins envie d'aller voir du côté de javascript "classique".
```
(go (let [results-from-first-request (<! (get-first))
          results-from-second-request (<! (get-second results-from-first-request))]
      (.log js/console results-from-second-request)))
```
Ok, en brut comme ça c'est pas simple et ça nécessiterait un article entier (à venir) mais pour faire simple j'ai deux requêtes asynchrones, la deuxième dépendant du résultat de la première. Et pourtant je l'ai écrit quasiment comme si c'était synchrone, à part go et <!.
- [^] # Re: Clojurescript
  
  Posté par rakoo (site web personnel) le 03 mars 2016 à 00:15. Évalué à 2.
  C'est une des raisons pour lesquelles je garde cet article sous la main dans l'espoir de pouvoir jouer un peu avec du CSP en Javascript, ça donnerait quelque chose du genre:
```
go(function*() {
  let results1 = yield take(first())
  let results2 = yield take(second(results1))
  console.log(results2)
})
```
  C'est un peu du async/await en première approximation, sauf qu'avec CSP on gagne la puissance des select par exemple, le tout en javascript "standard" (bon, c'est faux, il faut quand même du javascript récent avec générateurs)
  - [^] # Re: Clojurescript
    
    Posté par jerome (site web personnel) le 03 mars 2016 à 00:34. Évalué à 2.
    
    Cela dit, js-csp n'a pas bougé depuis des mois et plus personne ne répond aux "issues" github. J'ai envie d'aimer mais je ne suis pas sûr que ce soit autre chose qu'un hack.
# asm.js

Posté par CrEv (site web personnel) le 02 mars 2016 à 23:39. Évalué à 7.

Et si javascript ne devenait simplement pas un langage intermédiaire ?
Je me posais justement la question de pourquoi les nouveaux langages qui sont traduits en javascript ne ciblent-ils pas plus asm.js ?
Ainsi les performances seraient meilleures, asm.js ne serait qu'un langage intermédiaire, comme un bytecode au fond.
- [^] # Re: asm.js
  
  Posté par lockidor le 02 mars 2016 à 23:57. Évalué à 10.
  
  Je me posais justement la question de pourquoi les nouveaux langages qui sont traduits en javascript ne ciblent-ils pas plus asm.js ?
  
  Probablement parce que Webassembly est en train d'arriver. Grosso modo, ça définit un bytecode standard pour les navigateurs, ce qui permettra à terme de compiler depuis n'importe quel langage en ajoutant « simplement » un nouveau backend auc compilos existants. LLVM par exemple commence à s'y mettre.
  - [^] # Re: asm.js
    
    Posté par ZeroHeure (site web personnel) le 03 mars 2016 à 12:53. Évalué à 5.
    
    Tiens ça mériterait une dépêche ça !
    A. Journal de Nono (ci-dessus)
    B. Les diverses remarques des commentaires
    C. Webassembly
    
    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Langage web et monde du travail

Posté par matthieu bollot (site web personnel, Mastodon) le 03 mars 2016 à 00:28. Évalué à 6.

Oui javascript est encore là pour longtemps, c'est le langage de base sur tous les navigateurs, ça risque pas de changer demain :-/
ses surcouches (CoffeeScript, PureScript, etc.) ne sont plus à la modeAngularJS 2 est basé sur typescript, et en terme de mode ou de buzzword on fait pas beaucoup mieux (dans le domaine du web)

Je suis pas un fanboy de javascript ou de node. Mais j'avoue adorer faire de l'AngularJS, ça marche vite et bien, on peut faire des applis de bonne envergure très proprement, avec un code clair et bien testé. Après ça reste du front, je suis pas du tout intéressé par faire du NodeJS mais il y a des avantages, un seul langage à connaître pour le back et le front et les benchmarks sont quand même assez valorisant.
# Opinion personnelle

Posté par Kaane le 03 mars 2016 à 01:31. Évalué à 10.

Personnellement j'adore JavaScript, c'est pour moi le langage le plus abouti qui soit à l'heure actuelle. Mais il faut bien comprendre que depuis le début il essaye de se faire passer pour ce qu'il n'est pas.

JavaScript est un langage prototypal, mono thread orienté vers la programmation événementielle. Et c'est tout. Pour tout un tas de raisons on lui a donné une syntaxe aussi proche du C++/Java que possible - alors qu'il est plutôt proche des langages fonctionnels. On va dire que ça a grandement aidé à son adoption (c'est pas Erlang ou Racket qui peuvent prétendre avoir réussi à séduire les foules même si ils sont meilleurs sur bien des points).

Maintenant il faut bien comprendre qu'il s'agit de maquillage. En JavaScript vous avez des Scopes (ou états si vous préférez) qui contiennent des paramètres qui peuvent eux mêmes être des scopes. Ces scopes se partagent un temps d’exécution sur un seul thread en utilisant des évènements pour se passer la main les uns aux autres. Voilà c'est tout. Il y a tout en haut des prototypes qui peuvent servir de moules, c'est pratique mais pas franchement essentiel. Ça évite de devoir se fader une lib en plus pour la gestion des tableaux et des chaines principalement.

Tout le reste, et ça inclue les notions de variables, d'objet, de fonction etc, ne sont que des postiches pour faire plaisir aux codeurs C/C++/Java.

Une fois qu'on a compris ça, on arrête de coder en JavaScript comme si il s'agissait d'un langage procédural, et ça va beaucoup mieux.

Après concernant la multitude de bibliothèque en pré-alpha, c'est vrai que npm+GitHub n'a pas simplifié la tache. On manque en Javascript d'une bibliothèque standard. Mais à moins que vous soyez en train de coder un shell ou un système d'init en JS (là on crache du sang, je confirme), on trouve toujours d'excellente libs qui facilitent le boulot dans des proportions hallucinantes. J'ai écrit une interface console pour le pilotage et le monitoring d'appareils via TL1 ou SNMP en quelques heures (et encore parce que je ne connaissais pas bien TL1).

Après il y a des limitations, pour la crypto, le temps réel (même mou) ou le calcul massivement parallèle (les workers c'est bien, mais jusqu'à un certain point), c'est clairement pas le bon langage.

Mais clairement un langage de script qui permet en quelques centaines de lignes d'encaisser et d'envoyer des millions de traitement par seconde tout en restant lisible et debugable et en prenant moins de 100Mo tout compris en exécution - il y en a quand même pas des masses.

Et ensuite il y a des produits dont je ne peux plus me passer en JavaScript. PEG js par exemple - ou D3 js même si il est parfois incohérent avec lui même - ou Blessed

Alors certes ce n'est pas le langage parfait, son plus gros défaut étant les comportement singulier de certaines fonctions suivant que vous soyez en mode exécution (normal) ou en mode évaluation (console de debug navigateur par exemple) CF Understanding delete

Mais les incohérences sont tellement faibles comparées aux autres langages, à moins de faire du Haskell, ca va être dur de trouver un langage raisonnablement moderne et ouvert sur l'extérieur (capable de gérer des I/Os de façon un poil intuitive) qui soit meilleur à ce niveau là.

Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses. Et on est en train de créer des tonnes de sucre syntaxiques pour que les fans de C++/Ruby puissent utiliser leur habitudes de programmations sans dégommer les perfs.

Tant mieux si ça ramène des gens en plus sur le langage. Mais je suis très content en ES5 avec du Q(pour le prototypage)/Bluebird (pour la production), du lodash et les outils précités pour l'habillage.
- [^] # Re: Opinion personnelle
  
  Posté par CrEv (site web personnel) le 03 mars 2016 à 06:27. Évalué à 8.
  
  Personnellement j'adore JavaScript
  
  Ok, pour avoir fait du js full time pendant plusieurs années de taff je peux comprendre :-)
  
  c'est pour moi le langage le plus abouti qui soit à l'heure actuelle
  
  Heu, par contre faut quand même garder les yeux ouverts :-D
  
  Certes javascript évolue, dans un sens plutôt agréable, mais le plus abouti je ne pense pas.
  
  Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses.
  
  A mon avis ce n'est juste parce que les gens ont du mal. Il y a des gens très compétents qui trouvent cela absolument horrible.
  
  les fans de C++/Ruby
  
  Mouai…
  
  Un article parmi d'autres qui évoquent certains problèmes de node/js The Node.js Event Loop is a Damn Mess
  - [^] # Re: Opinion personnelle
    
    Posté par Kaane le 03 mars 2016 à 09:22. Évalué à 5.
    
    Un article parmi d'autres qui évoquent certains problèmes de node/js The Node.js Event Loop is a Damn Mess
    
    Mouai aussi.
    Tous les problèmes évoqués ont des solutions. Certaines sont d'ailleurs évoquées dans le texte. Oui si on surcharge un certain type d'I/O sans prendre de précautions on peut exploser l'appli.
    Comme dans n'importe quel autre langage.
    
    Mais bon en JavaScript
    a) On a généralement beaucoup plus de marge avant que ça ne se produise. Un script JS accepte et traite les requêtes I/O a des vitesses démentielles pour le peu de code écrit par le dev.
    b) On a systématiquement une pléthore de solutions :
    - Trop de petites demandes en simultané ? Ben on lance une seconde, puis une troisième instance de la même appli, que ce soit avec de la proxification (nginx par exemple) ou via le forking natif node
    - Le back-end n'arrive pas à suivre ? Ben on fait du state counting quand on rentre dans les promesses/event loops problématiques et on limite le nombre de connexions au backend.
    - Certaines opérations de calculs prennent trop de temps CPU et pourissent le time sharing ? Ben on les exporte dans des workers.
    -Certains backend n'ont pas la politesse de nous insulter ou de nous raccrocher au nez quand ils ne peuvent pas traiter la demande ? setTimeout() et c'est réglé.
    -Trop de callbacks - on utilise des promesses A+
    -Trop de promesses illisibles imbriquées les unes dans les autres ? Ben scope dédié avec un event loop.
    -Une instance Node bouffe trop de mémoire ? Ben on ferme la création de nouvelles sessions (on laisse ça à d'autres instances) et on fait un graceful restart.
    
    Etc.
    
    Et très honnêtement citer PHP comme exemple du truc à faire ? Sur les threads par session ? On parle bien du langage qui oblige à mettre des entrées dans le cron toutes les X heures pour éviter les memory leak, et qui va bazarder toute la session si un seul évènement non interceptable se pointe ? PHP qui va prendre 2000 descripteurs, des heures de debug et l'aide d'un module Apache de rewriting pour faire un routage web correct en cas de forte charge ? Sérieusement ?
    
    JavaScript a des défauts, beaucoup même, mais malgré les très gros progrès de PHP ces dernières années - il ne tient pas une seconde la comparaison avec NodeJS + Koa/Express.
    
    La personne qui a écrit cette article ne donne pas d'exemples concrets (juste une analogie idiote qui revient à dire que chaque scope amènerait du temps CPU avec lui à l’instanciation GNI ???) - Mais à mon sens il s'agit d'un cas typique d'un mec qui veut faire du PHP/Java/Ruby/C++ ou autre en JavaScript, et qui se plaint que ça ne marche pas.
    
    Cette phrase en particulier
    
    Exceeding the stack size is so common because there is no good way for the programmer to slow down the influx of operations from the execution queue while all these unreturned function calls are performing work.
    
    Pourrait difficilement être plus fausse. J'ai rarement vu de langage qui offrait autant de méthodes simples, lisibles et maintenables pour gérer les évènements asynchrones.
    - [^] # Re: Opinion personnelle
      
      Posté par totof2000 le 03 mars 2016 à 19:07. Évalué à 3.
      
      Pourrait difficilement être plus fausse. J'ai rarement vu de langage qui offrait autant de méthodes simples, lisibles et maintenables pour gérer les évènements asynchrones.
      
      Simple, je suis d'accord. Mais lisible et maintenables, pas forcément. On a vite fait de se perdre sans le vouloir en Javascript (plus qu'avec d'autres langages) et on peut arriver assez facilement à du code non maintenable.
      
      Attention, je ne dénigre pas : j'exprime juste mon ressenti, mon expérience personnelle.
      - [^] # Re: Opinion personnelle
        
        Posté par Kaane le 04 mars 2016 à 01:26. Évalué à 2.
        
        Mais lisible et maintenables, pas forcément.
        
        Oui on est d'accord, on peut écrire du code illisible et in maintenable dans n'importe quel langage. Mais en JavaScript a la possibilité de faire du code "propre" même sur des applications techniquement complexe. Ce qui n'est pas toujours possible dans tous les langages.
        
        Un exemple tout bête, si une connexion est cassée, et qu'elle faisait partie d'un pool qui a été utilisé par plusieurs scopes qui sont en attente de réponse. Il faut donc prévenir tous les scopes concernées qu'il faut réessayer, certains vont répondre que c'est possible, d'autres que ce n'est pas possible. Une fois que toutes les fonctions auront répondus, ou après un temps d'attente maximum, il faudra filer une nouvelle connexion à celle qui peuvent réessayer et nettoyer celles qui ne peuvent pas - puis nettoyer proprement la socket pour libérer les descripteurs.
        
        C'est le genre de truc qui rend fou à écrire dans la majorité des langages. Et je ne parle pas de le maintenir.
        
        En JavaScript ça va donner un truc du genre :
        var myPool { ... mySocket.on('RST','DESTROY','CLOSE') { var curSocket = this; Promise.allSettled(curSocket.Clients.map(raiseRetryEvent)) //Send an event "retry" to all client of this socket .timeout(15000) //wait 15 sec max before resolution .then(function(results) { results.forEach(function (result, index) { if(typeof result === 'function') // callback sent from client {result(myPool.allocateConnection);} else {curSocket.Clients[index].cleanup();} //client did not answer with a callback curSocket.cleanup(); //We do not need to keep the socket alive any longer. }); }) } }11 lignes niveau débutant plus à intermédiaire. Lisible même par des gens qui n'ont jamais fait de javascript de leur vie mais qui connaissent des langages avec une syntaxe similaire. Il n'y a guere que le Promise.allSettled qui peut faire se gratter la tête 30 secondes.
        
        P.S le code est présenté de façon très moche, mais j'arrive pas à faire mieux…
        
        [^] # Re: Opinion personnelle
        
        Posté par BAud (site web personnel) le 04 mars 2016 à 02:28. Évalué à 10. Dernière modification le 04 mars 2016 à 02:28.
        
        P.S le code est présenté de façon très moche, mais j'arrive pas à faire mieux…
        
        C'est tout de même très dommage (te concernant) :
        
        var myPool { ... mySocket.on('RST','DESTROY','CLOSE') { var curSocket = this; Promise.allSettled(curSocket.Clients.map(raiseRetryEvent)) //Send an event "retry" to all client of this socket .timeout(15000) //wait 15 sec max before resolution .then(function(results) { results.forEach(function (result, index) { if(typeof result === 'function') // callback sent from client {result(myPool.allocateConnection);} else {curSocket.Clients[index].cleanup();} //client did not answer with a callback curSocket.cleanup(); //We do not need to keep the socket alive any longer. }); }) } }
        
        11 lignes niveau débutant plus à intermédiaire. Lisible même par des gens qui n'ont jamais fait de javascript de leur vie mais qui connaissent des langages avec une syntaxe similaire. Il n'y a guere que le Promise.allSettled qui peut faire se gratter la tête 30 secondes.
        
        un tel jugement à l'emporte-pièce pour quelqu'un pas foutu de lire l'aide-mémoire en bas de chaque commentaire (voir tout en bas pour formater du code) qui est rappelé sur aide-édition notamment pour le code, tu comprendras que tu passes toi aussi pour un débutant :-)
        
        [^] # Re: Opinion personnelle
        
        Posté par Kaane le 04 mars 2016 à 08:58. Évalué à 4.
        
        tu comprendras que tu passes toi aussi pour un débutant :-)
        
        Mais j'en ai bien conscience.
        Merci d'avoir reformaté le code en tout cas, c'est quand même plus lisible.
        
        [^] # Re: Opinion personnelle
        
        Posté par feth le 04 mars 2016 à 15:06. Évalué à 6.
        
        Je suis "intermédiaire" en javascript, et je déteste voir autant de niveaux d'imbrication, sans parler du nombre d'accolades fermantes qu'il faut compter. La charge cognitive est insurmontable pour rentrer vraiment rapidement au cœur de cet algo.
        Je sais que c'est bien pensé algorithmiquement -j'ai quand même compris :-) - et que c'est le style attendu partout, puisque même moi je finis par écrire ainsi, mais franchement, c'est rédhibitoire pour quelqu'un qui fait du Python en découpant tout ce qu'il peut en morceaux, avec des "return", des "break" ou des "continue" le plus en amont possible, pour désindenter désindenter.
        
        Les coups et les douleurs, je sais. Et on m'avait pas sonné :-)
        
        [^] # Re: Opinion personnelle
        
        Posté par Bruno Michel (site web personnel) le 04 mars 2016 à 10:35. Évalué à 10. Dernière modification le 04 mars 2016 à 11:02.
        
        Pour le coup, je ne suis vraiment pas convaincu par un tel exemple. 11 lignes, ce n'est pas beaucoup, mais ici, ça a l'air truffé d'erreurs.
        
        var myPool {
        
        Il manque le = ? Ou ça aurait dû être une définition de fonction ?
        
        mySocket.on('RST','DESTROY','CLOSE') {
        
        J'imagine que ça aurait dû être mySocket.on(['RST', 'DESTROY', 'CLOSE'], function() {.
        
        Promise.allSettled .timeout
        
        Les Promise ont été normalisées, mais allSettled et timeout ne font pas partis de cette API. Je suppose que ça doit venir d'une implémentation tierce à la bluebird.
        
        curSocket.Clients.map(raiseRetryEvent)
        
        La fonction raiseRetryEvent n'est pas définie ici, mais elle n'aura pas accès à curSocket, ce qui paraît bizarre. J'aurais plutôt attendu curSocket.Clients.map(curSocket.raiseRetryEvent.bind(curSocket)), histoire d'avoir d'utiliser une méthode rattachée à curSocket.
        
        if(typeof result === 'function')
        
        Ça peut suffire ici, mais il faut faire attention. Il y a beaucoup de choses qui peuvent passer au travers (les classes ES6 sont vues comme des fonctions IIRC, lodash traite aussi de certains cas particuliers : https://github.com/lodash/lodash/blob/4.6.1/lodash.js#L10020).
        
        result(myPool.allocateConnection);
        
        Sans l'implémentation de myPool.allocateConnection, c'est difficile à dire, mais je pense que ça devrait probablement être result(myPool.allocateConnection.bind(myPool));
        
        results.forEach(function (result, index) { // ... curSocket.cleanup(); });
        
        L'appel à curSocket.cleanup devrait sûrement être en dehors de la boucle.
        
        Bref, c'est un bel exemple que le JavaScript est un langage avec beaucoup de pièges. Et je pense que les 5 langages que j'ai cités dans mon journal s'en serait tous tirés bien mieux que ça sur cet exemple.
        
        [^] # Re: Opinion personnelle
        
        Posté par Kaane le 04 mars 2016 à 19:14. Évalué à 1.
        
        Effectivement j'ai fais de la boue hier. Mea Culpa - pourtant je sais qu'il ne faut pas essayer d'écrire du code à une heure du mat quand on est claqué…
        
        Ca m'apprendra.
        
        var myPool {
        
        Il manque le = ? Ou ça aurait dû être une définition de fonction ?
        
        Il manque le =
        
        mySocket.on('RST','DESTROY','CLOSE') {
        
        J'imagine que ça aurait dû être mySocket.on(['RST', 'DESTROY', 'CLOSE'], function() {
        
        Oui tout à fait.
        
        La fonction raiseRetryEvent n'est pas définie ici, mais elle n'aura pas accès à curSocket, ce qui paraît bizarre. J'aurais plutôt attendu curSocket.Clients.map(curSocket.raiseRetryEvent.bind(curSocket)), histoire d'avoir d'utiliser une méthode rattachée à curSocket.
        
        C'est une autre façon de faire - j'aime moins car ca duplique des méthodes dans chaque connexion, pour moi la méthode raiseRetryEvent est une méthode de myPool. Comme on est dans le scope, si la fonction n'a pas été surchargée par mySocket il n'y aura pas de soucis.
        
        if(typeof result === 'function')
        
        Ça peut suffire ici, mais il faut faire attention. Il y a beaucoup de choses qui peuvent passer au travers (les classes ES6 sont vues comme des fonctions IIRC, lodash traite aussi de certains cas particuliers : https://github.com/lodash/lodash/blob/4.6.1/lodash.js#L10020).
        
        Certes si je joue avec des lib extérieures et que j'ai pas lu la doc. Mais là j'ai quand même supposément la maitrise de tout le code. J'ai donc le droit de dire que mes clients renvoie soit un callback, soit autre chose qu'une fonction, soit ne renvoie rien.
        
        result(myPool.allocateConnection);
        
        Sans l'implémentation de myPool.allocateConnection, c'est difficile à dire, mais je pense que ça devrait probablement être result(myPool.allocateConnection.bind(myPool));
        
        Là par contre ce serait bizarre, certes je n'ai pas mis le code, mais on se doute que allocateConnection retourne un objet connexion, ou au moins une promesse de connexion à qui en fait la demande. Si le code est correct, il y a peu de chance qu'une telle fonction ait besoin de se référer explicitement à son scope parent.
        
        Ceci étant j'ai voulu (trop) simplifier le code que j'écris d'habitude sur ce genre de cas. Ça plus la fatigue ça devient forcément brouillon.
        
        C'est vrai que
        
        var myCon = myPool.returnPromiseOfConnection(curSocket.Clients[index]);
        result(myCon);
        
        aurait été plus lisible.
        
        L'appel à curSocket.cleanup devrait sûrement être en dehors de la boucle.
        
        Clairement oui.
        
        Bref, c'est un bel exemple que le JavaScript est un langage avec beaucoup de pièges.
        
        Oui enfin le fautes de syntaxe et les oublis de keyword c'est de la fatigue pure. JavaScript n'est pas responsable de mes migraines nocturnes non plus.
        Après je n'utilise presque jamais bind() dans mon code. Dans ma logique si il y a une fonction qui doit être appelée dans un scope précis, autant l'invoquer depuis ce scope précis. Les mécanismes d'event permettent souvent de faire ça sans grosses difficultés.
        
        Et je pense que les 5 langages que j'ai cités dans mon journal s'en serait tous tirés bien mieux que ça sur cet exemple.
        
        Si on met de coté le fait que j'ai pas exactement servi ma cause en écrivant du code à 1h00 du mat, j'ai un doute.
        Elixir peut probablement écrire un code aussi compact et clair pour un codeur Elixir, parce que je sais que c'est possible en Erlang. Maintenant le jour ou il faut trouver un codeur Elixir (ou Erlang d'ailleurs) pour maintenir le bousin parce que le précédent est parti, ca va piquer.
        
        Elm est pas vraiment fait pour ce genre d’âneries. Mais je serai curieux de voir la tête d'un gestionnaire de pool de websockets en Elm. Je n'arrive juste pas trop à avoir un exemple ou ce serait utile ou fun de le faire.
        
        Crystal, je ne pense pas que le langage puisse créer un code aussi compact et lisible. Toute la partie gestion/transmission d'évènements risque d'être plutôt velue sauf erreur de ma part.
        
        les autres je ne les connais pas du tout (non pas que je connaisse les 3 premiers - j'ai essayé mais j'ai pas insisté)
# Wtfjs en fait trop (un peu)

Posté par Christophe HENRY (site web personnel) le 03 mars 2016 à 06:58. Évalué à 10.
En cliquant sur le lien dans Il y a trop de pièges j'arrive sur une page se plaignant de ceci :
```
/[A-z]/.test("\\"); // true WTF?
```
C'est-à-dire que l'expression rationnelle est censée chercher en apparence les caractères alphabétiques majuscules ou minuscules. L'anti-slash (échappé) satisfait pourtant au test.

C'est pareil en Python, aussi :
```
>>> bool(re.match('[A-z]', '\\'))
True
```
En fait, on comprend quand on consulte l'extrait de la table ASCII :
```
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
```
Et plus précisément, ce qu'il y a entre Z et a :
```
[\]^_`
```
- [^] # Re: Wtfjs en fait trop (un peu)
  
  Posté par KiKouN le 03 mars 2016 à 09:18. Évalué à 10.
  
  A bin, sans le savoir, je ne tombe jamais dans le piège car je ne savais pas que l'on pouvait écrire [A-z] .
  J'ai toujours écris : [a-zA-Z] . Maintenant, il faut que j'oubli [A-z] pour ne pas y tomber.
  Enfin, merci pour cette explication de cette mécanique interne.
- [^] # Re: Wtfjs en fait trop (un peu)
  
  Posté par woprandi le 03 mars 2016 à 10:19. Évalué à 4.
  
  Pour ça qu'on écrit en général [a-zA-Z]
  - [^] # Re: Wtfjs en fait trop (un peu)
    
    Posté par barmic le 03 mars 2016 à 10:48. Évalué à 10.
    
    Voir mieux : [:alpha:]
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Wtfjs en fait trop (un peu)
  
  Posté par freem le 03 mars 2016 à 11:51. Évalué à 7.
  
  /[A-z]/
  
  Uhhhh ça me serait jamais venu à l'idée de faire un truc aussi space perso… y'a vraiment des gens qui font ça dans du vrai code? Y'a pas de fonction type isalpha( c ) ?
  
  C'est pas que j'aime pas les regex, loin de là, mais bon une fonction avec un nom clair c'est quand même plus agréable à utiliser je trouve… (en fait, j'utilise les regex comme les lambda: quand je n'ai pas d'alternative…)
# tracer un nouveau chemin

Posté par CrEv (site web personnel) le 03 mars 2016 à 07:05. Évalué à 9.

En substance ton journal me fait penser à ce que j'écrivais ici même il y a un peu plus de 2 ans :

Il faut dire que j'ai été un peu moins passionné par le monde du web ces derniers temps. Ok, on trouve beaucoup de choses sur AngularJS par exemple, sur du CSS, sur des bibliothèques JS, etc. Mais je dois dire que j'ai un peu l'impression que ça tourne en rond. Certes c'est toujours plus mieux, certes il y a des nouveautés. Mais il y a aussi beaucoup de réinventage de roue, de NIH. Depuis que j'ai commencé à vraiment coder sur le web, il y a une petite dizaine d'année, j'ai l'impression que ça n'a pas beaucoup évolué par certains côtés. On se retrouve à, encore aujourd'hui, refaire une énième bibliothèque de composants html/js pour, par exemple, styliser des listes déroulantes. Le style à changé, c'est vrai. On est d'ailleurs passé par pas mal de choses, des biens lourdes pendant un temps, et on s'oriente vers du minimalisme, avec des couleurs bien utilisées et un accent sur la typographie. Les outils ont changé aussi, on voit maintenant fleurir le code utilisant des pré-processeurs malgré l'aversion de certains (less et sass, mais aussi stylus pour le css, coffeescript pour le javascript par exemple). On voit aussi les systèmes de build, de gestion de dépendance (bower et requirejs).

Tout ça c'est bien, ça va dans le sens d'une industrialisation dont le web (et plus généralement malheureusement le développement) manque cruellement. Mais se retourner et voir qu'on fait par certains côtés toujours la même chose depuis 10 ans, c'est tout de même un peu triste, non ?

Je n'imaginais pas alors qu'entre ce message et aujourd'hui il y aurait d'une part de réelles avancées du langage mais surtout une explosion des outils "nécessaires" à mettre en oeuvre pour faire une application web aujourd'hui. Comme tu le dis, grunt, gulp, browserify, webpack, babel, etc. Le setup d'un projet contenant du javascript aujourd'hui me hérisse le poil à un point que je cherches par tous les moyens de ne plus en faire de cette façon. Et je ne suis pas non plus pour l'usage immodéré de générateurs qui vont tout faire, on est souvent obligé de mettre la main dedans et ce n'est pas toujours joli.

Quoi qu'il en soit je vais juste parler de ma propre expérience. Peut-être y a-t-il quelque chose à en tirer.
Après des années à faire du web et principalement du js j'en ai eu marre. Attention, j'adorais le langage, je le maitrisais plutôt bien, pas de problème. Mais j'ai fini par faire overdose de l'écosystème immature (et on voit que ça ne s'est pas arrangé).

J'ai donc choisi de simplement pivoter. J'ai toujours aimé beaucoup d'autres langages. J'ai donc commencé (professionnellement j'entends, ça reste une façon d'y consacrer plus de temps) à m'orienter vers d'autres domaines. Ces dernières années (en gros depuis quelques mois après le message du début du commentaire) j'ai donc réalisé des projets utilisant :
- clojure côté backend (ok, plus angularjs en front)
- C++/Qt
- Ruby/Qt
- Ruby
- Dev mobile Android avec un gros coeur cross platforme en C++ (durant 1.5 ans full time)
- Go/Clojurescript

Aujourd'hui je reviens sur du web mais retour aux fondamentaux : Ruby on Rails + juste ce qu'il faut de js par endroits.

Il faut surtout voir l'ensemble de ces changements, l'ensemble de ces projets comme un chemin. Un chemin vers d'autres langages, d'autres façons de faire, d'autres écosystèmes. Ce chemin m'a au fond conforté dans l'idée que j'avais du monde javascript. Mais quand on commence à détester le langage qu'on utilise tous les jours, il est temps de regarder ailleurs, vraiment.

Au final je continue à utiliser Javascript mais plutôt à contre courant. Je l'utilise là où il est bon, c'est à dire apporter du dynamisme dans une page web. Je l'oublie pour absolument tout le reste.
Si j'ai réellement besoin de faire une application web basée sur du javascript, aujourd'hui je me tournerais sur du clojure/reagent ou du elm. Je ne vois javascript presque que comme un langage intermédiaire cross-plateforme.

Tout ça me fait aussi penser à un tweet de Sam Stephenson :

Some things we don’t use in Basecamp 3: Angular. React. Ember. Backbone. jQuery UI. ES6. Babel. Browserify. Webpack. Anything from NPM. Grunt
- [^] # Re: tracer un nouveau chemin
  
  Posté par Michaël (site web personnel) le 03 mars 2016 à 10:33. Évalué à 2.
  
  clojure côté backend (ok, plus angularjs en front)
  
  Un langage de type Lisp sera très probablement le prochain grand langage du web, si ce n'est pas déjà le cas car certains considèrent presque JavaScript comme un Lisp!
  
  JavaScript a montré la pertinence de et familiarisé les développeurs avec certains traits typiques de Lisp comme les fermetures, les fonctions d'ordre supérieur, les fonctions anonymes, la programmation générique et un format de sérialisation qui correspond à la notation dans le code-source. Avec tous ces ingrédients, l'acceptance pour un langage de type Lisp a été bien préparée.
  - [^] # Re: tracer un nouveau chemin
    
    Posté par pushmepullme le 03 mars 2016 à 22:59. Évalué à 0.
    
    Peu probable. Au delà des paradigmes et des concepts, un langage c'est aussi une syntaxe. Dans le cas de lisp et consorts, le très fort parenthésage est un choix très fort qui ne plaît pas de toute évidence, à beaucoup de développeurs.
    - [^] # Re: tracer un nouveau chemin
      
      Posté par Michaël (site web personnel) le 04 mars 2016 à 09:53. Évalué à 2.
      
      Dans le cas de lisp et consorts, le très fort parenthésage est un choix très fort qui ne plaît pas de toute évidence, à beaucoup de développeurs.
      
      Les syntaxes de C, C++, Perl ou PHP ne sont pas moins abominables. Une syntaxe agréable n'est pas une condition sine qua non à l'adoption d'un langage.
- [^] # Re: tracer un nouveau chemin
  
  Posté par totof2000 le 03 mars 2016 à 19:13. Évalué à 2.
  
  Pour moi, clojure a 2 grands défauts :
  - il est basé sur Java
  - il ne bénéficie pas de l'optimisation de la récursion terminale(il semble que ce soit une conséquence de son premier défaut : http://www.clojure.org/about/functional_programming#_recursive_looping ) ce qui est moche et dommage pour un langage fonctionnel (attention à la pile).
  - [^] # Re: tracer un nouveau chemin
    
    Posté par CrEv (site web personnel) le 03 mars 2016 à 23:14. Évalué à 5.
    il est basé sur Java
    Si je ne me trompe il est basé sur la JVM (ce qui est différent).
    Et sinon, en quoi c'est un grand défaut ? Parce que là comme ça on dirait surtout du troll ;-)
    - [^] # Re: tracer un nouveau chemin
      
      Posté par flan (site web personnel) le 04 mars 2016 à 00:25. Évalué à 5.
      
      Si c'est comme Scala, c'est un inconvénient pour moi.
      On se retrouve avec deux langages à connaître au lieu d'un seul si on veut comprendre ce qui se passe et utiliser la lib standard.
      exemple tout bête : en Scala, tout objet hérite du type Any. Plus exactement, presque tout le monde hérite de AnyRef qui hérite de Any, sauf les int/float (eln fait les types primitifs de Java) qui héritent de AnyVal qui hérite de Any. Rien de très choquant là-dedans quand on connaît Java. Ça, c'est la théorie. Maintenant, si on veut faire un Array de Any et mettre dedans des String et des int, pas de souci d'après le système de types… sauf que ça casse à l'exécution pour un problème de type, alors que la grande promesse de Scala est de résoudre tous les problèmes de type à la compilation.
      Normal : sous le capot on a un type primitif de Java qui ne se caste pas bien comme un objet Java.
      
      Maintenant, ce problème ne devrait pas exister en Scala, et il est indispensable de connaître des subtilités de Java pour comprendre le comportement de Scala.
      Quant à la lib standard, c'est en fait essentiellement celle de Java, donc il on se retrouve à mélanger deux styles de programmation qui n'ont pas grand-chose à voir.
      - [^] # Re: tracer un nouveau chemin
        
        Posté par barmic le 04 mars 2016 à 09:17. Évalué à 4.
        
        Normal : sous le capot on a un type primitif de Java qui ne se caste pas bien comme un objet Java.
        
        Non c'est bien une question de JVM et pas de Java. C'est comme si tu disais qu'il fallait connaître le C pour pouvoir programmer en go parce que la gestion des nombre à virgule flottante est la même qu'en C.
        
        Pour ce que tu décris précisément ça me paraît être juste un bug du compilateur scala qui ne prend pas assez bien en compte la plateforme sous-jacente (la JVM). Connaissant les gens qui font scala, je ne serais pas surpris qu'ils considèrent eux que c'est un bug de la JVM qu'ils ne veulent pas contourner.
        
        Quant à la lib standard, c'est en fait essentiellement celle de Java,
        
        Ça c'est possible, je ne sais pas.
        
        […] donc il on se retrouve à mélanger deux styles de programmation qui n'ont pas grand-chose à voir.
        
        Comme à chaque fois que t'ajoute un bibliothèque à ton programme c'est un risque. Je m'amuse actuellement avec Vertx et ils se sont fadés 2 API une par callback et un rxifiée, mais ce n'est pas tous les projets qui s'embêtent avec ça.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: tracer un nouveau chemin
        
        Posté par flan (site web personnel) le 04 mars 2016 à 18:56. Évalué à 3.
        
        Le lien entre JVM et Java est quand même très légèrement plus fort que celui entre IEEE754 et C. La JVM a été pensée pour le Java (et Java a été pensé pour fonctionner sur la JVM), IEEE754 n'a pas été pensé spécialement pour le C, le C n'a pas été pensé pour IEEE-754 (et fonctionne sur des processeurs qui ne sont pas compatibles IEEE754).
        Si tu veux être compatible Java (un des buts est de réutiliser des libs Java), tu es obligé d'être compatible JVM. S'ils n'avaient pas besoin de cette compatibilité Java, ils n'auraient pas eu de problème avec la JVM…
        
        Ce que j'ai décrit n'est qu'un des aspects où on aboutit à vrai bug au runtime, mais il y a régulièrement des petits trucs qui ne s'expliquent que grâce au Java (notamment la gestion des types primitifs Java) et qui ne devraient pas expliquer si Scala n'était pas compatible Java.
        
        Et quand tu utilises la lib standard Java, tu te retrouves avec une doc en… Java (surprenant ! ), avec des exemples en Java bien orientés objet comme il faut.
      - [^] # Re: tracer un nouveau chemin
        
        Posté par Michaël (site web personnel) le 04 mars 2016 à 09:57. Évalué à 1.
        
        Quant à la lib standard, c'est en fait essentiellement celle de Java, donc il on se retrouve à mélanger deux styles de programmation qui n'ont pas grand-chose à voir.
        
        Pourquoi? Si tu fais allusion au impératif vs. fonctionnel Lisp est un langage multi-paradigme et pas du tout un langage fonctionnel pur.
# Mochi et LiveScript

Posté par dzecniv le 03 mars 2016 à 08:54. Évalué à 1.

Python est un chouette langage avec un énorme écosystème. Mais un peu plus de prog fonctionnelle serait coole… voici Mochi ! https://github.com/i2y/mochi Écrit en python 3, il transforme le code en AST python et est donc totalement inter-compatible avec les librairies python.

Et pour JS, j'adore LiveScript: http://livescript.net/ Ressemble à CoffeeScript, mais sa bib prelude fourni des méthodes fonctionnelles (avec currying, etc) ce qui est extrèmement pratique pour manipuler des données. J'écrivais du JS avec la fonction map d'underscore JS… quelle galère. Maintenant c'est plié en 3 lignes, on enchaîne clairement les filtres avec l'opérateur pipe, etc.
# Dart

Posté par patrick_g (site web personnel) le 03 mars 2016 à 09:22. Évalué à 6.

Et Dart, le truc de Google qui peut être compilé en JS, et qui était censé être mieux et plus propre. Ça n'a pas percé ce truc ?
- [^] # Re: Dart
  
  Posté par freem le 03 mars 2016 à 11:53. Évalué à 10.
  
  Dart […] Ça n'a pas percé ce truc ?
  
  C'est triste, vu le nom…
# Il ne reste qu'à essayer OCaml

Posté par Michaël (site web personnel) le 03 mars 2016 à 10:25. Évalué à 10.
Je me pose pas mal de questions sur l'avenir du JavaScript.

JavaScript n'est pas près de disparaître car:
- Il a aujourd'hui une énorme communauté de développeurs
- C'est un langage définit par un standard
- C'est le soldat qui a gagné la “guerre” des RPCs, des standards comme CORBA n'existent plus qu'à l'état de niche, et le JSON/HTTP s'est établi comme standard de facto dans le monde des RPCs. Bien-sûr on peut utiliser JSON/HTTP sans JavaScript, mais beaucoup de services proposes des APIs JavaScript pour interagir avec eux via JSON/HTTP.
- Les interpréteurs de JavaScript sont à la pointe de la technologie en raison de l'attention qu'ils ont reçue dans les dernières années à cause de la compétition acharnée entre les navigateurs. Sans cette compétition très tendue en arrière plan, il y a peu de chance qu'on voie apparaître des interpréteurs aussi performants pour des langages plus confidentiels.
JavaScript n'est pas resté immobile. On a vu apparaître les Promise, puis certains ont détourné les générateurs. On parle beaucoup d'async/await. Il n'empêche, on est toujours dans un bourbier, coincé entre des API qui utilisent parfois des callbacks, parfois des promises.

Ce n'est pas un très gros problème. En pratique c'est presque toujours mieux de programmer
avec des promise (style monadique) qu'avec des callback (style spaghetti). Losqu'on doit
utiliser une bibliothèque qui utilise des callback c'est utile (ou nécessaire) d'adapter son interface
en style promise.

Le typage statique est également très intéressant pour détecter des erreurs.

Programmeur OCaml chevronné, je trouve que le typage statique brille tout particulièrement pendant les refactorings car les gros changements d'organisation dans un programme amènent leur lot d'erreur. Pour des programmes équivalents, un refactoring JavaScript me prend 4-5 fois plus de temps qu'avec OCaml.

Dernier point, avec ES6 et les versions futures, je trouve le langage de plus en plus complexe. […]

Je partage ton avis. Pour être honnête, je n'ai jamais beaucoup aimé JavaScript jusqu'au jour
où j'ai lu et apprécié le livre de Douglas Crockford *JavaScript – The Good Parts” qui propose
une méthodique de programmation très simple, cohérente, et claire. Quel contraste avec le côté
bidouille et fouillis qu'on voit dans la plupart des programmes qu'on peut lire!

Et vous, quels sont vos langages du moment ? Et que font-ils mieux que JavaScript ?

Mon langage du moment est – depuis 1999 – le OCaml. Son adoption dans l'industrie se solidifie d'année en année. Ce qui pourrait t'intéresser, c'est la présence d'un compilateur js_of_ocaml qui permet de compiler
son programme OCaml en JavaScript. Écrire des bindings pour utiliser ses bibliothèques JavaScript sur
avec ses programmes OCaml est très facile quand on a pris le tour de main – mais en général il faut
un peu plus de travail pour avoir une interface “OCaml-ienne”. Mais ça marche superbement!
# Un autre avis perso

Posté par Hodj le 03 mars 2016 à 10:59. Évalué à 9.

Je fait des applis web depuis 20 ans et je n'aime toujours pas javascript ou du moins ce que l'on en a fait.
Il ne faut pas oublier le point de départ de javascript qui était de rendre les pages html un peu plus dynamiques, puis un jour un éditeur base à Redmond à ajouté l'instruction XmlHttpRequest et la ça s'est mis à partir en sucette.
Depuis, on passe notre temps à tordre le coup à ce pauvre langage pour lui faire faire des choses pour lesquelles il n'était pas prévu (objet,…), résultat on en a fait, AMHA, une sombre b… En plus vus la place qu'il a aujourd'hui, il empêche l’émergence d'autres langage qui serait bien plus adaptés à notre utilisation.
Pour couronner le tout chaque navigateur a son interpréteur et il réagit différemment des autres (pourquoi faire simple quand on peut faire compliqué).
Après, on ajoute des framework (Angular, node…) qui ajoute des truc venu de java (j'ai mémé entendu parler d'annotations) et la ça devient pire que pire.
- [^] # Re: Un autre avis perso
  
  Posté par freem le 03 mars 2016 à 11:55. Évalué à 7.
  
  j'ai mémé entendu parler d'annotations
  
  C'est pas tout jeune ça, non?
  - [^] # Re: Un autre avis perso
    
    Posté par Hodj le 03 mars 2016 à 12:19. Évalué à 1.
    
    En effet ça date mais ce n'est pas pour ça que c'est bien.
    J'en ai aussi vu en PHP et ce n'est pas mieux.
    AMHA, on tord le cou au langage pour ajouter cette notion.
    - [^] # Re: Un autre avis perso
      
      Posté par freem le 03 mars 2016 à 13:31. Évalué à 7.
      
      Je faisais référence à mémé ;) pour le reste, je n'y connais rien.
      - [^] # Re: Un autre avis perso
        
        Posté par Hodj le 03 mars 2016 à 15:16. Évalué à 3.
        
        Bon j'avoue, j'ai oublié d'enlever les moufles ce matin.
# Mon cas

Posté par barmic le 03 mars 2016 à 11:08. Évalué à 7.

Comme tout le monde donne la sienne, je vais faire de même.

Perso, je ne connais que très mal javascript et ce n'est pas un langage qui m'attire plus que ça. Je me sert de javascript uniquement à travers Angular. Ce dernier met permet d'avoir un framework « opinionated » histoire de faire un peu moins n'importe quoi et il me permet d'appliquer un concept que j'avais découvert avec JSF et que j'avais bien aimé : le fait d'avoir un controller qui a un état et une vue qui est une représentation de cet état. Mon projet actuel fait environ 75% de code serveur pour 25% de JS/HTML/CSS.

Pour moi c'est un usage plutôt sympa. Le serveur distribue tout un contenu statique pour faire de l'angular et ce dernier va faire des appels rest pour récupérer et modifier les données de l'application. Le truc est largement plus réactif que ma version précédente sans javascript.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# non ...

Posté par manatlan (site web personnel) le 03 mars 2016 à 11:34. Évalué à 2.

Javascript ne va pas droit dans le mur ;-)

L'avenir est à WebAssembly sans conteste ! Mais JS restera là, à côté (compatibilité + petits trucs).

La transpilation "était" à la mode (coffee, typescript, dart, …) : pour apporter de la "facilité de dev".

Maintenant, pour aller encore plus loin, on va vers la compilation (vers le webasm) à partir de n'importe quel autre langage (que demander de plus ?!).

Certes, on fera moins de JS pure. Mais il restera à côté de webasm. Il reviendra à la place pour laquelle il était destiné, au début.
# Javascript est déjà dans le mur

Posté par Florent Zara (site web personnel, Mastodon) le 03 mars 2016 à 11:56. Évalué à 10.

il est même dans beaucoup de murs… en voici un :

Ne bougez pas, je ↪️ [] .
# Elm

Posté par Guillaume Denry (site web personnel) le 04 mars 2016 à 10:57. Évalué à 8.

Tu cites Elm, je suis tombé amoureux de ce langage il y a quelques jours, mais comme tout réel objet de désir, il ne se laisse pas apprivoiser facilement.

Une petite anecdote pour bien montrer ce à quoi je suis parfois confronté en tant que "Javascriptiste" qui tente de se reformater le cerveau pour de nouveaux paradigmes.

Accéder à des nombres aléatoires en Javascript, c'est trivial.
On peut utiliser Math.random() pour du non cryptographique ou bien cette chose si on veut du random un peu plus sérieux.
Bref, où qu'on se trouve dans notre programme et à quelque niveau que ce soit, on va juste pêcher un nouveau nombre aléatoire quand on en a besoin.

En Elm, c'est une autre paire de manche. Chaque fonction est obligatoirement pure.
On n'a donc pas de fonction qui renvoie un résultat différent à chaque appel. Haha.

C'est quoi la solution ? Très simple, pour respecter la pureté, la fonction de génération de nombre random prend en paramètre une seed et renvoie non seulement le nombre dont on a besoin mais également une nouvelle seed qu'il faudra utiliser au prochain appel. Bon ok, ça paraît simple comme ça. Mais en fait, ça veut dire qu'il faut un moyen de stocker la seed précédente qu'il faudra ré-exhumer au prochain appel du générateur. On voit clairement que ça devient moins simple n'importe où dans le code de pouvoir accéder gratuitement à un nouveau nombre aléatoire, ça demande un aménagement particulier.

Y'a pas mal de situations comme ça où il faut se torturer un peu le cerveau et retourner le problème dans tous les sens pour PAF, trouver la solution, et ceci pour des problématiques qui en Javascript paraîtrait triviale à réaliser. Alors peut-être que je butte encore sur des choses simples parce que je viens de m'y mettre mais bon.

Bref, Elm est présenté comme un moyen simple de mettre un pied dans la programmation fonctionnelle et c'est vrai, il est nettement moins velu qu'Haskell et beaucoup plus ludique, mais même si c'est mon souhait le plus cher, j'ai du mal à penser que ce genre de langage est accessible au premier développeur venu, ne serait-ce que par les efforts fournis pour devoir penser autrement.
- [^] # Re: Elm
  
  Posté par chimrod (site web personnel) le 04 mars 2016 à 12:51. Évalué à 5.
  
  Je ne connais pas elm, mais ce que tu décris correspond tout à fait au problème auquel répond les monades. Ça permet de contenir un environnement et d'appliquer une fonction qui modifie l'environnement.
  
  Il existe une grande littérature sur ce sujet, et je ne vais pas paraphraser ce que d'autres exprimeront mieux que moi, aussi je te renvoie vers la langage dans lequel les monades sont reines.
  - [^] # Re: Elm
    
    Posté par Anthony Jaguenaud le 04 mars 2016 à 13:17. Évalué à 2.
    
    Elm ressemble vachement à Haskell au niveau de la syntaxe. Du coup, j’ai un doute que ça perce un jour, hélas.
    - [^] # Re: Elm
      
      Posté par Guillaume Denry (site web personnel) le 04 mars 2016 à 13:42. Évalué à 4.
      
      Une fonction en elm :
      f a b = a + bLa même fonction en JavaScript :
      function f(a, b) { return a + b; }Je préfère mille fois la version Elm et mes doigts me disent merci.
      - [^] # Re: Elm
        
        Posté par chimrod (site web personnel) le 04 mars 2016 à 14:46. Évalué à 2.
        
        C'est pas possible d'écrire plutôt ?
        
        f = (+)
        
        [^] # Re: Elm
        
        Posté par Guillaume Denry (site web personnel) le 04 mars 2016 à 14:51. Évalué à 2.
        
        Oui.
        Tu vois, c'est encore plus concis :)
      - [^] # Re: Elm
        
        Posté par BAKfr le 04 mars 2016 à 15:26. Évalué à 1.
        
        En Javascript moderne (Ecmascript 2015 pour être précis), on peut faire bien plus court avec les fat arrows:
        
        f = (a, b) => a + b
        
        [^] # Re: Elm
        
        Posté par Guillaume Denry (site web personnel) le 04 mars 2016 à 15:40. Évalué à 8.
        
        Yep et c'est génial, on a maintenant une fonction qui hérite du scope courant, comme ça, ça complique encore un peu plus le monde merveilleux des fonctions javascript où on sait jamais vraiment quel scope on manipule (j'exagère le trait, certes, suffit de comprendre ce qu'est this dans un certain contexte, mébon).
        
        L'autre jour au boulot, on était pas trop capable de dire immédiatement si le fait de remplacer une fonction anonyme traditionnelle par une fat arrow en tant qu'argument d'une autre fonction qui par en dessous faisait des bind dans tous les sens allait nous péter un truc ou pas.
        
        Je me moque mais j'aime les arrows functions, j'ai pu chasser beaucoup de vilains bind.
        
        [^] # Re: Elm
        
        Posté par Michaël (site web personnel) le 06 mars 2016 à 10:10. Évalué à 2.
        
        (j'exagère le trait, certes, suffit de comprendre ce qu'est this dans un certain contexte, mébon)
        
        Tu n'exagères pas tellement, c'est suffisamment complexe pour que Douglas Crockford conseille simplement de ne jamais utiliser this quand on écrit un programme. Les règles concernant l'usage de this ne sont, bien-sûr, pas incompréhensibles, mais c'est une chose d'écrire des programmes et une autre de faire la maintenance: dans cette perspective, il vaut toujours mieux préférer les solutions simples, robustes, et faciles à appréhender car lorsqu'un on fait la maintenance, on n'a pas une vision aussi claire du programme qu'au moment où on l'écrit.
        
        [^] # Re: Elm
        
        Posté par Bruno Michel (site web personnel) le 04 mars 2016 à 16:45. Évalué à 3. Dernière modification le 06 mars 2016 à 15:05.
        
        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)
        
        [^] # Re: Elm
        
        Posté par El Titi le 04 mars 2016 à 17:10. Évalué à 3.
        
        Au hasard… pour rendre le truc aussi imbitable que du Perl avec des contextes dans tous les sens et des rustines avec tout les symboles cabalistiques de l'ASCCI pour que le parser puisse encore passer. A quand l'usage obligatoire de l'UTF8 pour disposer de l'alphabet du Mordor (http://freetengwar.sourceforge.net/keylayouts.html)
        
        Ce truc, tout comme le HTTP qui a fait des contorsions monumentales pour faire passer ce qui n'aurait jamais du exister pour un protocole en mode non connecté … et aboutir à réinventer la roue … J'ai nommé WebSocket. Que de temps perdu!
        
        Quand je pense que Firefox supportait du scripting python un temps. Nostalgie !!!
        
        [^] # Re: Elm
        
        Posté par Juke (site web personnel) le 04 mars 2016 à 17:39. Évalué à 2.
        
        Quand je pense que Firefox supportait du scripting python un temps.
        
        Quand ?
        
        [^] # Re: Elm
        
        Posté par El Titi le 04 mars 2016 à 17:54. Évalué à 2. Dernière modification le 04 mars 2016 à 17:55.
        
        Il m'avait semblé que c'était dans les pipes en touts cas:
        https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_bindings/PyXPCOM
        
        La belle époque de XulRunner.
        
        C'est pas mort tout ça ?
        
        [^] # Re: Elm
        
        Posté par barmic le 04 mars 2016 à 19:20. Évalué à 1.
        
        C'est pas mort tout ça ?
        
        Oui ! Et bon débarras ! Toutes les techno XUL sont mortes ou vont l'être dans un temps limité.
        
        Ce que tu montre consiste à utiliser XPCOM (une composante de XUL) avec python. Ça pouvait peut être fonctionner avec XUL-remote, mais c'est mort il y a un paquet d'années et c'est une bonne chose parce que c'était une plaie du web au même titre que flash ou l'applet java.
        
        Xul n'est plus utilisé que dans Firefox Desktop, Thunderbird et quelques autres logiciels qui gravitent autour (comme BlueGriffon). Mozilla a arrêté de distribuer XUL comme une technologie à part et Firefox est entrain de voir comment il va se débarrasser de ça.
        
        XUL n'est pas une mauvaise techno (par contre c'est une techno mal gérée par Mozilla) qui a inspirée sur plusieurs point HTML5. Aujourd'hui tout le monde s'accorde à dire qu'il vaut mieux partir sur HTML5 que sur du XUL.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Elm
        
        Posté par lasher le 04 mars 2016 à 23:00. Évalué à 3.
        
        Hé, tu laisses Perl tranquille. En Perl je sais très bien où est ma portée lexicale, surtout si j'utiliser use strict;. NAMÉOH!@$
        
        [^] # Re: Elm
        
        Posté par Michaël (site web personnel) le 06 mars 2016 à 14:43. Évalué à 4.
        
        Pourquoi avoir donné un sens spécial au caractère underscore ? Si je ne me trompe pas, il n'en avait pas jusque là.
        
        Quel sens spécial? C'est juste un identifiant valide je m'en servais déjà pour marquer explicitement les arguments non-utilisés des fonctions ad-hoc passées à des fonctions d'ordre supérieur. Comme par exemple dans
        
        someArray.reduce(function(ax, _, _, _) { return ax + 1; }, 0);
        
        qui compte les éléments de l'array (exemple scolaire).
        
        [^] # Re: Elm
        
        Posté par Bruno Michel (site web personnel) le 06 mars 2016 à 15:07. Évalué à 3.
        
        Bien vu, c'est une erreur de ma part. L'underscore n'a pas de sens spécial ici.
    - [^] # Re: Elm
      
      Posté par Bruno Michel (site web personnel) le 04 mars 2016 à 14:15. Évalué à 2.
      
      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é.
    - [^] # Re: Elm
      
      Posté par El Titi le 04 mars 2016 à 16:36. Évalué à 5.
      
      aussi je te renvoie vers la langage dans lequel les monades sont reines.
      
      J'ai lu tout le thread et c'est une mine d'or, mais en lisant certains posts, j'ai un peu l'impression que certains veulent nous montrer leurs mgonades
      
      Ok => []
      - [^] # Re: Elm
        
        Posté par Michaël (site web personnel) le 06 mars 2016 à 10:15. Évalué à 3. Dernière modification le 06 mars 2016 à 10:15.
        
        Les monades sont juste un design pattern – ou patron de conception pour ceux qui connaîtraient, voire utiliseraient, l'expression française adéquate – qu'on peut très bien utiliser en JavaScript comme dans tous les langages qui permettent de créer des fermetures. Dans le cas de la programmation asynchrone, il est même recommandé d'utiliser un style monadique plutôt que le style spaghetti imposé par les callbacks car le premier permet de préserver l'idée de composition des traitement, qui disparaît complètement avec les callbacks.
        
        [^] # Re: Elm
        
        Posté par Aluminium95 le 07 mars 2016 à 23:13. Évalué à 3.
        
        Les monades sont juste un design pattern
        
        Je pense que c'est un peu plus que cela, c'est un « design pattern » au même titre que des objets dans un langage à objets. Mieux, c'est autant un design pattern qu'un groupe commutatif (int), qu'un monoïde libre sur un type (listes) : c'est une représentation mathématique formelle qui se trouve être implémentable et calculable dans une certaine mesure. Je ne sais pas si se rendre compte qu'un objet formel (int/liste) est un modèle d'une certaine théorie (groupe/monoïde) est considéré comme un pattern.
        
        D'un autre côté je ne connais pas beaucoup les « design pattern », donc je dis peut-être des absurdités et c'est une propriété commune aux différents patterns.
        
        [^] # Re: Elm
        
        Posté par Michaël (site web personnel) le 08 mars 2016 à 09:24. Évalué à 4.
        
        Je pense que c'est un peu plus que cela, c'est un « design pattern » au même titre que des objets dans un langage à objets.
        
        Du point de vue du programmeur c'est un design pattern, si tu préfères. Après, comme toutes les choses de ce monde, elles ont plein d'aspects différents. Connaître la théorie mathématique des types qui permet de réconcilier “la monade du programmeur” avec “la monade du mathématicien” n'a un intérêt pratique que pour les spécialistes de théorie des types qui développent des langages comme OCaml ou Haskell – mais pour développer avec ces langages, on ne perd rien à s'en tenir à une considération rudimentaire se bornant à voir une monade comme un design pattern qui factorise la prise de décision si le dernier calcul a fini par une erreur alors ne fait rien sinon applique la fonction f au résultat.
        
        [^] # Re: Elm
        
        Posté par Aluminium95 le 08 mars 2016 à 19:26. Évalué à 1.
        
        Je vois un peu mieux ta conception, mais pour être sûr : faire des objets, c'est un design pattern ? Dans ma perception (peut-être erronée), j'aurais dit que un objet c'est un concept « méta », à partir duquel on peut construire un design pattern particulier, quand on regarde sur wikipédia on trouve par exemple :
        
        Abstract factory : Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
        
        Builder : Separate the construction of a complex object from its representation, allowing the same construction process to create various representations.
        
        Publish/subscribe : Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically.
        
        Ce qui me semble vraiment différent de la définition même d'un objet, qui est un concept régi par des lois (même si c'est moins fort que pour une monade). Si on voulait ajouter « monadic code » dans la liste la seule définition que je vois est une tautologie :
        
        Monadic code : see if the code can be represented with a monad, and if so, do it.
        
        [^] # Re: Elm
        
        Posté par chimrod (site web personnel) le 08 mars 2016 à 21:04. Évalué à 3.
        
        Ça dépend dans quel contexte tu te places. Dans un langage qui t'impose l'usage de classes et d'instances, alors utiliser des objets n'est pas un choix de conception. Au contraire, si tu as le choix d'utiliser un objet, un foncteur, ou une monade, alors on peut penser qu'opter pour l'un au l'autre relève d'un patron de conception.
        
        Je rajouterai aussi que la monade ne s'applique pas vraiment dans le monde objet. C'est un design pattern de type (au sens de la théorie des types), et non pas du monde objet. Tout comme le visiteur n'a pas vraiment de sens dans un univers fonctionnel, le type Folddable n'a pas de sens dans le monde objet. Ça n'est pas pour rien que l'on parle de paradigme de programmations différents.
        
        [^] # Re: Elm
        
        Posté par Aluminium95 le 08 mars 2016 à 22:24. Évalué à 1.
        
        Dans un langage qui t'impose l'usage de classes
        
        Donc du coup il y a bien une hiérarchie :
        
        Les différents concepts qui sont accessibles facilement dans le langage
        
        Les différents patterns qui sont associés
        
        De plus, pour moi un design pattern c'est un choix qui est en un sens arbitraire, parce que sinon, ce n'est pas un design pattern, c'est simplement une technique nécessaire. Or, quand on fait un choix de type « monade / objet / groupe / interface / protocole » on considère une représentation, ensuite dans un design pattern, on sélectionne un choix d'implémentation dans le cadre que l'on a fixé.
        
        [^] # Re: Elm
        
        Posté par Michaël (site web personnel) le 09 mars 2016 à 13:45. Évalué à 3.
        
        De plus, pour moi un design pattern c'est un choix qui est en un sens arbitraire, parce que sinon, ce n'est pas un design pattern, c'est simplement une technique nécessaire.
        
        Le but des design-patterns n'est pas seulement de participer à la résolution du problème qui fait l'objet de l'écriture du programme dans lequel ils sont utilisés. C'est une notion qui recouvre les méthodes d'ingénierie qui permettent de tirer parti du soft dans le software – il s'agit donc de méthodes qui facilitent l'évolutivité et la maintenance des programmes.
        
        À ce titre les monades sont un exemple de design pattern, elles permettent par exemple d'éviter de programmer en style spaghetti comme lorsqu'on utilise des exceptions ou bien des callbacks en programmation asynchrone.
- [^] # Re: Elm
  
  Posté par Bruno Michel (site web personnel) le 10 mars 2016 à 18:55. Évalué à 4.
  
  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.