Un moteur de template Rust à base de macros. C'est évidement terriblement performant, et sacrément astucieux.

Cette police pour développeur est vraiment joliment arrondie.

Voici pour cet ingénieur les neuf critères d'évaluation d'un langage de programmation (pour peu qu'on arrive à dépasser la question de l'identité construite par le développeur sur son langage préféré)

Oh wow, l'article est vraiment passionant sur la façon dont les questions de choix de langage, de framework, d'architecture, sont avant tout des constructions identitaires.
La psychologie se cache décidément partout ...

Oh mais c'est une belle facon d'exposer les TODO pour ce qu'ils sont : des marqueurs de dette technique.

Oh c'est vraiment un article fantastique !
Le développement est certes un métier, mais c'est aussi souvent une passion qui pousse les gens dans des directions curieuses, mais parfois productives. Et c'est cool!

Un article qui colle bien avec un thème d'une conférence que je vais donner la semaine prochaine à Snowcamp

L'article est suffisament clair pour me donner l'envie d'en faire un plugin maven (ca n'est même pas dur)

Un langage de programmation dans lequel le seul conteneur possible est le tableau, et qui dispose d'innombrables fonctions définies avec un seul caractère unicode. C'est étrange à regarder, et ça demande à mon avis un beau temps d'adaptation. Mais le fait que ce soit interprétable dans un navigateur est vraiment sympa, et ça peut être très utile, en particulier pour les problèmes algorithmiques (ce qu'on appelle aussi le code golf)

Il y a là-dedans des idées extrêmement intéressantes.

Un exercice de prétention en programmation. Le concept de logique combinatoire semble intéressant, mais franchement, c'est juste pour se pourrir la vie.

Une série de conseils utiles pour les ingénieurs technophiles (comme moi)

Un catalogue d'antipatterns d'architecture

Ah ben voilà ! Donc en Groovy "moderne", pour pouvoir réécrire les commentaires, il ne faut pas utiliser XmlSlurper

Un remplacement des principes SOLID qui semble aller dans la direction d'une meilleure appropriation du code. Il faudrait que je lise ça

Je suis authentiquement fasciné par ce genre de pratique : vous iamginez le temps passé à communiquer l'intention à travers le code alors qu'il aurait sans doute été plus simple, plus clair, et plus rapide d'écrire un document portant l'intention de l'auteur.
Mais non, les développeurs préfèrent lancer des sorts dans leur repo Git pour faire porter cette intention à un ensemble de commits.
Cette capacité à complexifier et à ralentir me stupéfie.

L'argument du goût me paraît pertinent : en tant que gourmet de l'informatique, je trouve que l'ia est le mcdo de l'informatique : ça a un goût pas terrible, c'est toxique très rapidement, e on paiera toujours trop cher pour son usage.

En 2 minutes, l'écriture d'un morceau de musique électronique en live. C'est franchement saisissant de voir ces outils de génération de musique algorithmique (même si il faut bien connaître toute l'API pour en tirer profit au mieux)

L'intersection entre l'implémentation des classes en Python et le pattern matching crée des résultats suffisament terrifiants pour que je me demande comment ce même pattern matching est réellement implémenté en Java.

Une opinion intéressante.
Je sais pourquoi les compréhensions de liste Python s'écrivent comme ça. Mais je comprends aussi très bien pourquoi c'est peu ergonomique. Et l'opinion finale de l'article est assez intéressante.