Merci Riduidel pour cet article (http://nicolas-delsaux.hd.free.fr/Shaarli/?_Abm9A), ça me fait réaliser une chose:

Un développeur a deux choses en main: Le problème qu'on lui demande de résoudre, et la technique qui lui permet de le résoudre.
On cherche à avoir la technique la plus efficace, afin de se concentrer sur le problème. L'objectif, c'est le problème. La technique n'est qu'un moyen.
Donc nous avons conçu des outils pour nous simplifier la vie, pour rendre la partie technique plus efficace. C'est tout naturel.

Seulement ces outils censés nous simplifier la vie ajoutent en réalité une *charge mentale* aux développeurs.
Git est censé nous aider à gérer plus facilement les sources et leur modification. Mais il est complexe et impose un investissement intellectuel non négligeable, une charge mentale pour l'utiliser correctement.
Docker/Kubernetes sont censés simplifier le déploiement. Mais ils ont leur lot de problèmes et imposent une charge mentale pour savoir les utiliser et régler leurs problèmes spécifiques.
Les frameworks comme Vue.js/Angular/React sont censés simplifier et fluidifier le développement du front au back, mais nécessitent de comprendre et maîtriser leurs arcanes bien spécifiques avant même de produire un écran.

Tout ces outils, cumulés, finissent par imposer aux développeurs une charge mentale énorme sur la partie technique avant même de pouvoir commencer à produire du code, avant même de commencer à travailler concrètement sur le problème initial à résoudre. Vous dépensez du temps et de l'énergie pour comprendre la technique au lieu de dépenser ce temps et cette énergie pour réfléchir au problème que vous avez à résoudre.

Est-ce que ça vaut le coup ?  Est-ce qu'on a vraiment gagné du temps ?   Est-ce qu'on en gagnera à plus long terme avec ces outils ?  Je ne sais pas.

En fait si, je sais un peu.  Si on maîtrisait totalement *chacun* de ces outils, on gagnerait sans doute du temps, à court et à long terme. Cela ne fait aucun doute. Ces outils ont été conçus par des gens brillants, qui arrivent (par des sites web ou des conférences) à nous montrer tout le bien qu'ils peuvent produire. C'est beau, ça a l'air de marcher magnifiquement. Mais c'est normal: Ils maîtrisent à la perfection ces outils. Ils les ont conçus.
Dans la pratique, je constate que ces énormes cathédrales sont rarement bien maîtrisées (c'est le sujet de l'article), et que les gens perdent du temps à trouver comment bien faire les choses, voir comment faire les choses tout court. Non pas à cause du code qu'ils ont produit, mais déjà à cause des outils eux-mêmes.

Et c'est même pire que ça: Ces outils imposent une façon de penser spécifique. Mal comprise - et donc mal utilisée - cela impactera le code produit, qui non seulement sera sous-optimal par rapport au framework mais - comme il ne rentre pas bien dans l'état d'esprit du framework - sera compliqué à maintenir et faire évoluer. J'ai constaté ça sur divers projets.

Le monde du développement a oublié le principe du KISS pour se faire plaisir sur des outils qui - pris individuellement - sont séduisants. Du moins sur leur promesses.
Faites attention à la charge mentale que vous vous imposez en ajoutant ces outils.

Et un dernier mot d'avertissement: Faites attention à la perennité des outils que vous choisissez. Je pense en particulier aux frameworks Javascript dont la durée de vie est parfois particulièrement courte. C'est une dette technique que vous paierez. Et cher.
(Je le sais, je bosse en partie sur du WebObjects. Vous ne connaissez pas WebObjects ? Pourtant c'est le framework web qui était porté par une boîte aux moyen titanesques: Apple. Qui a décidé du jour au lendemain que ça ne l'intéressait plus.)
Grosse pensée pour les gens qui ont investi du temps à comprendre et maîtriser des technos mortes (Silverlight, etc.))

EDIT: Le xkcd approprié: https://xkcd.com/1597/

Sous le coude pour lecture ultérieure.

Les raisons de ne PAS utiliser un CDN pour le javascript.
(via Le Hollandais Volant).

Touvé au hasard du net : « le debugging, une énigme passionnante où vous êtes à la fois le détective, la victime et le coupable. »

L'auteur de SQLite (pour qui j'ai une énorme estime) ne veut pas de Git, et voici ses arguments.
(Il utilise FOSSIL, un excellent petit gestionnaire de sources qui contient un bugtracker et un wiki intégrés.)

Après tous les article anti-xml que je vous ai partagés, voici un article pro-xml.
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?ebA_BA)

Sous le coude.

Pas encore lu, mais je met ça de côté.

Alors ça, voyez-vous, c'est amusant.

Contexte:
Quand on développe un jeu, on doit choisir quelle "API" utiliser pour la 3D:
 - DirectX (Microsoft, mais du coup votre jeu ne marchera que sous Windows)
 - OpenGL (multiplateformes, mais très ancien)
 - Vulkan (multiplaformes, moderne et performant). Vulkan est actuellement en développement très actif.

DXVK est une couche d'émulation qui permet de faire tourner les jeux conçus pour DirectX vers Vulkan, donc de faire tourner des jeux Windows sous Linux. C'est son principal but.

Sauf que Vulkan est aussi disponible sous Windows. Et comble de l'ironie, les joueur qui passent par DXVK ont de meilleures performances qu'en DirectX pur !

Jeu => DirectX => DXVK => Vulkan => Carte graphique est plus performant que:
Jeu => DirectX => Carte graphique

(C'est du moins vrai pour DirectX 9/10/11.  DirectX 12 est - comme Vulkan - nettement plus bas niveau.  dxvk ne sait émuler que DirectX 9/10/11. Pour émuler DirectX 12, il faudra passer par un autre programme, vk3d, qui est encore jeune et pas abouti, et qui a priori n'apportera pas de gain de performances.)

Un super article qui explique la différence entre les exécutable liés statiquement et dynamiquement, et qui donne des exemples de liens dynamiques.

Différents algorithmes sur les graphes, les arbres, les listes… illustrés par des animations.

Sous le code: Pourquoi les développeurs aiment tellement le langage Rust.
Un jour il faudra vraiment que je prenne le temps de regarder.

Le moteur de jeu Defold passe en opensource.
Il permet de créer des jeux html, Android, etc.

Je pose ça là, parce que ça m'a fait sourire :-)
PS: Bien sûr cette page est simpliste, et il est intéressant de lire les commentaires sur HackerNews: https://news.ycombinator.com/item?id=23175334
Mais c'est vrai, les problèmes de multithreading peuvent être extrêmement difficile à investiguer/reproduire/corriger.
Avec des CPU qui ont de plus en plus de cœurs, je pense que le multiprocessing est plus intéressant à explorer (surtout que cela ouvre la voie à la répartition sur de multiples machines en réseau, et donc potentiellement une capacité de traitement colossale !). Il existe même des librairies qui vont répartir automatiquement vos traitements sur un ensemble de machines.

Le "Jeu de la vie" de Conway en 32 octets de code machine.
TRENTE DEUX OCTETS.

Sous le coude pour lecture ultérieure: En programmation orientée objet, l'héritage pose souvent des problèmes. Il vaut mieux privilégier d'autres solutions.

Trop drôle.

Totalement d'accord avec ça:
« As a programmer, it’s 💯 × more important to not over-engineer than to “avoid tech debt”.
You’ll have to refactor and throw away code in the future anyway—it’s impossible to know what requirements will be.
The less code you have, the easier it is to replace.»
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?3Y_7vg)

C'est quoi DevOps ?

Ah je me souviens de Delphi, oui.
C'est propre, pas lourd et très efficace ! J'avais beaucoup aimé.
On produisait des applications sans trois tonnes de dépendances, facile à installer et qui tournaient avec d'excellentes performances.

Petite introduction à Rust, un langage qui se veut performant et surtout beaucoup plus sûr (plus de dépassements de buffer, d'erreurs de segmentation, de risques de memoryleaks, etc.)
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?GMfn9A)
EDIT: Voir aussi: https://sebsauvage.net/links/?LUy39Q