Sur le fond, c'est dur de lui donner tort, sur la forme, il y a des trucs douteux. L'exemple des compilateurs, par exemple. Pourquoi compiler du C++ prend des plombes? En grande partie, parce que c'est une tâche hyper complexe, du fait de l'évolution du langage vers de plus en plus de trucs à faire au moment de la compilation (y compris l'optimisation). Pourquoi afficher des trucs prend des plombes? En partie, parce que le nombre de pixels n'a pas augmenté linéairement dans le temps, en partie aussi parce qu'on a amélioré les algorithmes d'affichage (sub-pixellisation, etc), en partie parce qu'on a complexifié les choses à afficher (transparence, coins arrondis...). Nier que les ordinateurs d'aujourd'hui font aussi des tâches beaucoup plus complexes, ça rend quand même l'argument moins pertinent.
Tout grossit aussi parce que les briques de base s'améliorent en terme de fonctionnalités. Ça me semble être une évolution difficile à enrayer pour les bibliothèques de base, par exemple : "et si vous faisiez ci, et si vous faisiez ça", avec l'argument de "mais votre concurrent X le fait!". Un exemple tout con, c'est par exemple d'avoir besoin de fonctions mathématiques pas complètement courantes (je ne sais pas, la fonction probit dans un programme en C, par exemple). Idéalement, il faudrait quoi? apt install lprobit-dev et #include "probit.h", chacun contenant quelques lignes de code? Ça ne marche pas comme ça. Il va falloir installer un gros paquet contenant des centaines ou des milliers de fonctions (boost?), puis appeler un gros .h qui va inclure d'autres .h qui vont inclure d'autres trucs, et voila, ça y est, on a bloaté son système et son logiciel. Honnêtement, j'ai du mal à imaginer de vraies alternatives.
# À boire et à manger
Posté par arnaudus . En réponse au journal Un développeur qui dénonce. Évalué à 10.
Sur le fond, c'est dur de lui donner tort, sur la forme, il y a des trucs douteux. L'exemple des compilateurs, par exemple. Pourquoi compiler du C++ prend des plombes? En grande partie, parce que c'est une tâche hyper complexe, du fait de l'évolution du langage vers de plus en plus de trucs à faire au moment de la compilation (y compris l'optimisation). Pourquoi afficher des trucs prend des plombes? En partie, parce que le nombre de pixels n'a pas augmenté linéairement dans le temps, en partie aussi parce qu'on a amélioré les algorithmes d'affichage (sub-pixellisation, etc), en partie parce qu'on a complexifié les choses à afficher (transparence, coins arrondis...). Nier que les ordinateurs d'aujourd'hui font aussi des tâches beaucoup plus complexes, ça rend quand même l'argument moins pertinent.
Tout grossit aussi parce que les briques de base s'améliorent en terme de fonctionnalités. Ça me semble être une évolution difficile à enrayer pour les bibliothèques de base, par exemple : "et si vous faisiez ci, et si vous faisiez ça", avec l'argument de "mais votre concurrent X le fait!". Un exemple tout con, c'est par exemple d'avoir besoin de fonctions mathématiques pas complètement courantes (je ne sais pas, la fonction probit dans un programme en C, par exemple). Idéalement, il faudrait quoi?
apt install lprobit-devet#include "probit.h", chacun contenant quelques lignes de code? Ça ne marche pas comme ça. Il va falloir installer un gros paquet contenant des centaines ou des milliers de fonctions (boost?), puis appeler un gros .h qui va inclure d'autres .h qui vont inclure d'autres trucs, et voila, ça y est, on a bloaté son système et son logiciel. Honnêtement, j'ai du mal à imaginer de vraies alternatives.