Remarque traducteur:
Récemment, le créateur de NodeJS, Rain Dahl, a ouvert la conférence HolyJS à Saint-Pétersbourg. Et je me suis souvenu que j'avais une traduction non publiée de son blog et j'ai décidé de la publier. À certains endroits, la traduction est assez franche. J'espère que cela vous intéressera. La date de sortie de cet article est octobre 2011. La date de sortie pour NodeJS est le 27 mai 2009.Il est inutile et compliqué sur presque toutes les couches. Le mieux que je puisse faire est de féliciter quelqu'un pour la solution rapide et facile au problème, compte tenu de la merde qu'il fournit. Le seul logiciel que j'aime est que je peux facilement comprendre et qu'il résout mes problèmes. Le degré de difficulté que j'accepte de subir est proportionnel à la taille du problème qui doit être résolu.
Au cours de la dernière année, je pense avoir enfin compris les idéaux Unix: les descripteurs de fichiers et les processus sont orchestrés à l'aide de C. C'est une excellente idée. Mais ce n'est pas de cela qu'il s'agit. La complexité n'était pas implicite. Au contraire, je dois gérer DBus, / usr / lib, Boost, ioctls, SMF, les signaux, les variables volatiles, l'héritage du prototype, _C99_FEATURES_, dpkg et autoconf.
Ceux d'entre nous qui écrivent des logiciels sur ces systèmes ajoutent de la complexité. Maintenant, vous devez connaître non seulement $ LD_LIBRARY_PATH pour faire fonctionner le système, mais aussi $ NODE_PATH - sachez, c'est mon affaire, c'est ma complexité supplémentaire! Les utilisateurs - ceux qui veulent voir une page Web - ne s'en soucient pas du tout. Ils ne se soucient pas de la façon dont nous organisons / usr, ils ne se soucient pas du fonctionnement des processus zombie, de toute façon l'ajout de commandes dans bash fonctionne, peu importe la façon dont zlib est lié statiquement ou dynamiquement à Node. Il viendra un moment où la complexité accumulée de nos systèmes existants sera plus grande que la complexité d'en créer un nouveau. Quand ce moment arrive, toute cette merde ira à la poubelle. Nous pouvons tirer le coup de pouce et glib et autoconf aux toilettes et ne jamais penser à eux.
Ceux d'entre vous qui aiment encore apprendre les détails d'un langage de programmation, par exemple, ceux qui sont heureux de savoir comment dire si NaN est nul ou non, vous ne comprenez même pas à quel point c'est putain. Si vous pensez qu'il serait bien d'aligner tous les caractères égaux dans votre code, si vous passez du temps à configurer votre gestionnaire de fenêtres ou votre éditeur, si vous insérez des coches Unicode dans le lanceur de test, si vous ajoutez des hiérarchies inutiles dans vos dossiers de code, si vous le faites au moins autre chose que de résoudre le problème - vous ne comprenez pas à quel point il est ennuyeux. Personne ne se soucie du modèle d'objet glib.
Une chose qui compte dans le développement de logiciels est la façon dont l'utilisateur se sent (expérience de l'utilisateur).