Je ne peux pas nier que certains des ces outils sont hyper élégants dans leur sortie console mais je ne peux m'empêcher de penser qu'on s'éloigne de plus en plus du principe KISS. On parle d'outils en ligne de commandes qui sont censées faire les choses simples et bien.
L'exemple de exa. Aujourd'hui même il fait 6658 lignes de code (sans compter les 16 (!) dépendances directes). Est-ce réellement nécessaire pour afficher le contenu d'un répertoire ?
Sincèrement je pense que ça fait un moment qu'on l'a quitté. Les systèmes d'aujourd'hui sont autrement plus complexes qu'avant, et je ne parle même pas des architectures serveur/haute disponibilité et déploiement.
D'un côté tu as une industrie qui est de plus en plus.. bah une industrie, donc exit les artisans.
Et de l’autre une majorité d'utilisateur a dans sa poche un appareil avec une ergonomie de fou, et souhaite retrouver cette ergonomie partout, donc au travail également (couleur, caractères utf8 pour facilité l'affichage des blocs, etc).
Bref, le nombre de ligne de code ne va faire qu'augmenter je pense ^
J'ai l'impression que ça dépend pas mal du contexte, par exemple les déploiements, est-ce que le déploiement de conteneur n'est pas plus simple au final que de déployer des tonnes de RPMs à l'ancienne ?
Aussi il y a un gros besoin au niveau sécurité. Il y a régulièrement des problèmes de sécurités liées à la nature du C (accès mémoire non sûr), donc une partie de ce qui motive de réécrire des bouts de système en Rust est d'éviter ce genre de problème.
Globalement les systèmes sont certes beaucoup plus complexes, mais on a aussi des besoins de simplicités accrus. En effet c'est trop compliqué de gérer un système complexe si ses composants sont aussi complexes à maintenir, donc certaines couches doivent êtres simplifiées. D'où par exemple le gain de popularité d'Alpine Linux pour construire des conteneurs, des binaires self-exécutables, etc.
Ne sommes nous pas entrain de quitter le monde de la simplicité et de l'élégance ?
Perso, je vois ça plutôt comme des logiciels différents que des réécritures : un peu comme perl par rapport à sed ou awk. C'est pas une mauvaise chose, au fond c'est pas des logiciels si gros que ça par rapport à bien d'autres (les originaux sont juste très petits) et ils apportent des fonctionnalités et une ergonomie différentes. Après, pour le moment le seul que j'utilise parfois c'est ripgrep.
En ce moment, pour ce qui est de la complexité, c'est plus les navigateurs qui m'inquiètent : tous ces gifs animés ont mangé toute la mémoire chez moi au point que je pouvais plus scroller la page ; ils m'inquiètent bien plus que les outils qu'ils décrivent :-)
# Oua !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Depuis le temps, que je voulais réécrire find à cause de sa lenteur ! (fd)
"La première sécurité est la liberté"
# Complexité
Posté par David Demelier (site web personnel) . Évalué à 10. Dernière modification le 02 septembre 2020 à 14:17.
Je ne peux pas nier que certains des ces outils sont hyper élégants dans leur sortie console mais je ne peux m'empêcher de penser qu'on s'éloigne de plus en plus du principe KISS. On parle d'outils en ligne de commandes qui sont censées faire les choses simples et bien.
L'exemple de exa. Aujourd'hui même il fait 6658 lignes de code (sans compter les 16 (!) dépendances directes). Est-ce réellement nécessaire pour afficher le contenu d'un répertoire ?
En comparaison la version FreeBSD de ls (la version sbase de suckless est encore plus minimaliste) :
Ne sommes nous pas entrain de quitter le monde de la simplicité et de l'élégance ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Complexité
Posté par Jean Gabes (site web personnel) . Évalué à 8.
Sincèrement je pense que ça fait un moment qu'on l'a quitté. Les systèmes d'aujourd'hui sont autrement plus complexes qu'avant, et je ne parle même pas des architectures serveur/haute disponibilité et déploiement.
D'un côté tu as une industrie qui est de plus en plus.. bah une industrie, donc exit les artisans.
Et de l’autre une majorité d'utilisateur a dans sa poche un appareil avec une ergonomie de fou, et souhaite retrouver cette ergonomie partout, donc au travail également (couleur, caractères utf8 pour facilité l'affichage des blocs, etc).
Bref, le nombre de ligne de code ne va faire qu'augmenter je pense ^
[^] # Re: Complexité
Posté par paulez (site web personnel) . Évalué à 3.
J'ai l'impression que ça dépend pas mal du contexte, par exemple les déploiements, est-ce que le déploiement de conteneur n'est pas plus simple au final que de déployer des tonnes de RPMs à l'ancienne ?
Aussi il y a un gros besoin au niveau sécurité. Il y a régulièrement des problèmes de sécurités liées à la nature du C (accès mémoire non sûr), donc une partie de ce qui motive de réécrire des bouts de système en Rust est d'éviter ce genre de problème.
Globalement les systèmes sont certes beaucoup plus complexes, mais on a aussi des besoins de simplicités accrus. En effet c'est trop compliqué de gérer un système complexe si ses composants sont aussi complexes à maintenir, donc certaines couches doivent êtres simplifiées. D'où par exemple le gain de popularité d'Alpine Linux pour construire des conteneurs, des binaires self-exécutables, etc.
[^] # Re: Complexité
Posté par Lutin . Évalué à 4.
D'un autre coté, si on arrive à mettre en place et maintenir ces systèmes complexes, c'est parce qu'on a des mécanismes de bases très simples.
[^] # Re: Complexité
Posté par barmic 🦦 . Évalué à 6.
Le dépôt d'exa inclut des fichiers pour l'intégration continue, de la documentation, du packaging,… Ce n'est pas très fairplay.
Après oui un logiciel qui cherche à en faire plus et plus gros qu'un logiciel qui chercher le minimalisme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Complexité
Posté par anaseto (site web personnel) . Évalué à 6.
Perso, je vois ça plutôt comme des logiciels différents que des réécritures : un peu comme perl par rapport à sed ou awk. C'est pas une mauvaise chose, au fond c'est pas des logiciels si gros que ça par rapport à bien d'autres (les originaux sont juste très petits) et ils apportent des fonctionnalités et une ergonomie différentes. Après, pour le moment le seul que j'utilise parfois c'est ripgrep.
En ce moment, pour ce qui est de la complexité, c'est plus les navigateurs qui m'inquiètent : tous ces gifs animés ont mangé toute la mémoire chez moi au point que je pouvais plus scroller la page ; ils m'inquiètent bien plus que les outils qu'ils décrivent :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.