Guillaume Denry a écrit 2954 commentaires

Sinon si on pendait les criminels au lieu de les déchoir d'une nationalité dont ils n'ont que faire, ça serait plus productif.

Absolument d'accord, on devrait rétablir la peine de mort, surtout pour les kamikazes.

J'étais sûr que je ferai cette erreur un jour.
Toutes mes excuses :)

Et comme j'ai cru comprendre que tu t'étais mis à Elm, tu as le type Result qui devrait aussi répondre à cette problématique.

Wow, 650.000 lignes ! Du coup, j'espère qu'il est indexé en mémoire ce fichier :)

D'ailleurs, "npm install -g" suxx, du coup.

Je sais que c'est sacré et que cela ne ce fait pas d'en dire du mal

C'est curieux comme façon de voir les choses : c'est comme si tu nous disais que c'est sacré et que cela ne se fait pas de dire du mal des tournevis.

Tout cela reste des outils, ça ne sert à rien de passionner le débat.

Si des gens aiment viscéralement les expressions régulières au point d'en mettre même là où elles utilisées à mauvais escient (pour valider une adresse email par exemple /troll), fuis ces gens !

our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that — and we’d have no choice but to do all that because you have to enforce trademarks or you lose them.
Can we not come to some sort of a compromise to get you to change the name without involving lawyers?

C'est peut-être poli mais ils ont un petit peu sorti l'artillerie lourde et les menaces dès le deuxième mail alors qu'il n'avait répondu encore que : "Sorry, I’m building an open source project with that name."

Elm :

Pensé "batteries included" (piles fournies),

Pas check. L'écosystème d'Elm est encore trop jeune et trop maigre :( On arrive assez vite aux limites. Mais c'est en pleine progression actuellement.

Yeux reposés, optimisé pour l'expressivité, la durabilité (facilité de lecture),

Check

Tout en épargnant au développeur pressurisé la charge cognitive inutile du comptage d'accolades ouvertes,

Mega-check

Heureusement répandu et idéal en premier langage de programmation,

Pas check. La courbe d'apprentissage de Elm est plutôt raide, quoiqu'en disent ses promoteurs. Pas tant dans le langage dont on fait assez vite le tour, mais dans le fait de prendre de nouveaux réflexes et de s'adapter aux contraintes d'un langage purement fonctionnel.

Opiniâtre parce qu'il a de bonnes raisons d'être comme il est (évoluant quand ça n'est pas le cas),

Check

Nonobstant, qui fait repousser les cheveux et gagner au loto ?

Je sais pas si on a un Nonobstant ici, mais j'ai les cheveux de la barbe qui poussent depuis que je fais du Elm, quant à gagner au loto, faudrait déjà que je joue, mais je suis sûr que je gagnerais. Mais bon, j'ai déjà un ordinateur et un fauteuil confortable, de quoi aurais-je donc besoin de plus ?

Non, c'est Elm. Indiscutablement.

Je doute que des TDD peuvent m'éviter d'écrire du caca. En tout cas le TDD, ça m'embrouille plus qu'autre chose.

En fait, "TDD" est mal nommé. Quand j'écris en TDD, c'est pas tant les tests qui m'intéressent mais la description comportementale attendue de mon code.
Dans la même logique, lorsque je veux comprendre le code d'un collègue qui bosse en TDD, je ne vais pas voir son code, mais tout d'abord ses tests, ça en dit beaucoup plus sur ce qu'on doit attendre du code.

N'oublie pas que je ne suis pas pro, ni même payé pour écrire du code. Et je suis seul a mètre la main à la tache sur mon projet.

On ne fait pas du TDD parce qu'on est pro ou juste par plaisir de perdre du temps à pondre des lignes de code, mais parce que ça confère des avantages indéniables à court, moyen et long terme. Ces avantages ne s'arrêtent pas (comme le nuage de Tchernobyl) à la frontière qui sépare les pros des amateurs.

hoooo oui, malheureusement.
bcrypt par exemple.

Et tu ne parles même pas de "npm search" qui utilise un temps d'exécution calamiteux.

Tout à fait d'accord.

nventeur du courrier électronique

Dommage qu'il n'est pas eu le temps d'imposer les Reply dans le sens de la lecture.

Il y a peut-être un côté hipster de l'informatique : maintenant que Javascript s'est complètement massifié, certains ressentent le besoin de vanter de petits langages obscurs, des créations patientes d'artisans, des éléments de distinction qui montrent qu'on ne se laisse pas aller au mainstream (*).

On pourrait utiliser exactement le même argument à chaque fois qu'un nouveau langage naît.

Je trouve ta réaction incroyable. Tu ne connais pas ces langages ni à quelle problématique ils répondent mais tu te permets de les balayer d'un revers de la main en affirmant qu'ils ne sont que des outils de hype et de distinction.

C'est pour moi pire que tout, pire que de faire du hype par exemple :)

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.

Oui.
Tu vois, c'est encore plus concis :)

Une fonction en elm :

f a b =
a + b
La 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.

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".

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.

Quant aux '<<', c'est sûrement mon passé de C, mais je trouve ça immonde. J'aime pas les iostreams… un bon vieux printf c'est tellement plus lisible.

Ca dépend du contexte, la notation "<<" est pourtant très expressive dans le sens "j'envoie quelque chose dans mon flux", mais ici, on a besoin de formater une chaîne avec des paramètres dynamiques et effectivement, une notation à la printf est toute indiquée, surtout que la suite logique en industrialisation est la traduction de la chaîne, et pour traduire le résultat d'un ensemble d'envois dans le flux, bon courage :)

Je profite lâchement de ce journal que j'ai trouvé très didactique, pour causer brièvement d'un langage fortement inspiré d'une sous-partie d'Haskell, appelé Elm et qui a en ce moment le vent en poupe.

Pour ceux que Haskell effraie, ce langage présente des aspects relativement basique de la FP, il n'utilise pas de termes comme "monoid" ou "monade" ou "functor", mais pourtant permet d'en utiliser sans s'en rendre compte, et je pense que c'est un bon tremplin pour entrer dans le monde de la programmation fonctionnelle.

Il est particulièrement gratifiant car il permet très facilement de créer des applications web, en partant d'un simple Hello World ou bien d'une page qui affiche la position de la souris, jusqu'à ce genre de chose.
Bon, je mentirais en disant qu'il offre les mêmes capacités que tout l'écosystème web autour de React ou Angular, mais il embarque tout de même des choses comme un DOM virtuel à la ReactJs, un système de signaux extrêmement pratique permettant de faire (attention, buzzword en approche) de la FRP (Functional Reactive Programming), c'est-à-dire que tout ce qui peut varier dans le temps (l'état du clavier, la souris, le temps, la taille de la fenêtre, etc) est manipulable sous forme de signaux (un signal est une valeur qui change dans le temps) sur lesquels on applique ensuite du filtrage, de la fusion, etc.

Redux, la petite lib qui est un flux "2.0" qui devient incontournable dans l'écosystème ReactJs est d'ailleurs (et officiellement) fortement inspiré de Elm.

Je peux vous garantir qu'une fois qu'on a bien pris Elm en main, c'est rude de revenir à Javascript.

Quelques liens en vrac :

Le bac à sable Elm pour tester le langage sans rien installer

Un tutoriel progressif sur la création du jeu de tétris en Elm

Le site web est une très bonne porte d'entrée également, il fourmille d'exemple permet même au programmeur Javascript de s'acclimater en douceur à ce nouveau langage.

Mon commentaire est suffisamment clair et explicite.

Tu n'as pas expliqué ce que tu reproches aux organisations sus-nommées, donc il y a beaucoup d’ambiguïté.
Donc non, ça n'est ni clair, ni explicite.

Je pensais pas qu'un jour je citerais un article de 20 minutes mais bon

http://www.20minutes.fr/economie/1788679-20160217-temps-travail-salaire-indemnites-prudhomales-comment-quotidien-risque-etre-bouleverse-reforme

Bref, les socialistes semblent aller encore plus loin qu'un gouvernement "officiellement" de droit.

L'auteur propose un logiciel qu'il a créé d'abord pour ses besoins et propose d'en faire profiter d'autres que lui aux prix certes d'un petit effort d'installation de modules python, et toi tu te moques de sa démarche parce qu'il a pas fait un travail de packaging qui TE convient. Peut-être que Jérôme a autre chose à faire de sa vie ?
J'ai envie de dire, sors-toi les doigts du cul et fais un package.

La licence du logiciel utilisé par github est importante, mais elle n'est qu'un petit maillon de ce qui rend cette plateforme attractive. Imagine que demain, quelqu'un s'amène avec un github libre, que crois-tu qu'il va se passer ? Une migration de gens qui vont soudainement se mettre à héberger leur code chez eux sur une instance github ? Bien sûr que non.
Le coeur de github, c'est pas la licence, et j'ai envie de dire que c'est même pas le logiciel ; c'est le temps et l'argent investis pour faire tourner tout ça. Pour que les gens aient le confort de juste avoir à en faire le minimum en maintenance pour pouvoir collaborer avec d'autres développeurs.
Mais oui, la décentralisation, sur le papier, c'est beau :)