Recent searches
Search options
Ma question : "Comment faire X dans le langage Y ?"
Les réponses dans les années 2000 : "Alors voici du code écrit en Y pour faire X."
La totalité des réponses à la même question aujourd'hui : "Importez ce module Z sur ce repos TRUCMUCHE et c'est fini ! MAGIQUE 
"
MAIS C'EST PAS CE QUE J'AI DEMANDÉ.
Je veux savoir COMMENT FAIRE, pas qu'on fasse à ma place.
et (suite)
et
#opinion : Importer des modules externes au lieu de faire vous-même, c'est augmenter la vitesse à laquelle votre programme va cesser de fonctionner parce que vous dépendez d'un module qui - si ça se trouve - n'existera plus dans 2 ans, ou ne sera plus maintenu, ou dépendra d'un module qui n'existe plus ou hébergé sur un repos dont le site aura disparu.
EDIT: Et je ne vous parle pas des risques de sécurité.
@sebsauvage mais on se repose au dessus des externalités tout le temps. Si ce n'est pas la stdlib ou l'interpreter du language, c'est l'OS, la libc ou autre libraries basse (expat, pcre, ssl, etc). C'est toujours un balance entre vitesse d'implementation et mantenir notre propre code.
Sergueil
@mdione
Certes, tout dépend du niveau de dépendance.
En venir à voir du "is-odd" est quand même à se taper la tête contre les murs. Or on en est là.
@mdione @sebsauvage ce n'est pas le principe de l'Open Source ? D'importer des librairies de la communauté qui vont pouvoir être fixés / testés sur le plus grand nombre et nous permettre de développer plus rapidement et de manière plus sûr car plusieurs personnes plus doués que nous vont lire le code et le maintenir ? ( Hors cas du is-odd ). Je privilégie souvent des librairies open source au lieu de réinventé la roue, surtout quand il existe des librairies qui le font et sont souvent utilisés.
@TinyMarmot @mdione
Alors oui, je ne vais pas m'amuser à réimplémenter libpng, ni même du csv (c'est piégeux) et encore moins de la crypto.
Mais appliquer le D.R.Y. de manière jusqauboutiste pour en arriver à des libs du genre "is-even", c'est stupide.
Et même si tu trouves une bonne lib qui fait bien son boulot, tu deviens dépendant de sa durée de vie, de sa sécurité et de la durée et vie et de la sécurité de *toutes* ses dépendances. Il faut aussi y penser.
Autant passer par des bibliothèques a rendu très rare un paquet de failles (injections SQL par exemple), autant ça a ouvert la voie à beaucoup d’autres problèmes
@TinyMarmot @mdione
@Eldeberen @mdione @TinyMarmot
Au boulot certaines de nos applis dépendent de frameworks abandonnés et pour lesquels ont ne trouve même plus de formations.
Super
Mais qui fait vraiment l'effort de justement vérifier le code des dépendances avant de les utiliser et ensuite de s'assurer que c'est maintenu ? Surtout quand c'est du npm, rust, … avec un nombre de dépendances à facilement 3~4 chiffres sans aucun intermédiaire style distro pour potentiellement faire une revue rapide.
@sebsauvage @mdione du coup comme beaucoup de choses il faut trouver un équilibre entre réinventé la roue et faire les choses soit même pour la pérennité dans le temps. Je suis d'accord qu'en fonction des frameworks utilisé, il y a des tendances à dépendre de la terre entière et dans ces cas là être encore plus restrictif sur la librairies que tu intègres au projet :)