Je ne sais pas ce que tu veux dire par "en lisant un peu plus", j'ai bien sûr lu le billet avant de le critiquer.
Je voulais dire « en allant 2 paragraphes plus bas ».
Le texte que tu cites n'a rien de particulièrement convaincant : tu peux avoir un paquet Firefox qui dépend du paquet Toto qui lui-même dépend du paquet Tiff pour certaines de ses fonctionnalités, que Firefox lui-même n'utilise pas (genre, au hasard, un truc à la ImageMagick qui supporte 60 formats dont 59 intéressent Firefox).
Merci je connais la logique qui induit ce genre de dépendances.
De même, Firefox peut décider d'utiliser deux bibliothèques super utiles, une pour parser le HTML et l'autre pour communiquer à travers le réseau, l'une étant écrite en Python et l'autre en Perl, deux langages qui demandent un support runtime donc doivent être installés avec ces libs.
Soit.
Qu'est-ce que l'auteur aigri conseille aux développeurs de Firefox (ou autre) de faire en ce cas ?
D'arrêter de faire du bloatware. Avoir 2 runtimes (un perl et un python) pour finallement en exécuter un autre (JS), en passant son temps à faire des bindings dans tout les sens ces contre-productifs et contre-performant. Ça rend le logiciel plus compliquer à maintenir (multiplier les langages dans un même projet ça ne simplifie rien). Ça rend de plus le logiciel plus fragile si l'une des briques a un problème, firefox en a un.
Ré-écrire l'une des bibliothèques dans l'autre langage pour n'installer qu'un seul runtime ?
Je vais me contenter de citer ce que j'ai dis dans le journal :
Bien sûr qu'il peut y avoir de bonnes raisons pour ajouter une dépendance, mais il faut justement la chercher avant de la créer.
Si la raison est simplement qu'un développeur préfère tel ou tel langage, ça ne me semble pas être une bonne raison.
Le problème à grande échelle c'est que l'on arrive a avoir des systèmes de paquet dont le graphe de dépendances des paquets se rapproche d'une clique pour éxagérer. Tu peut le voir comme un aigri, mais c'est un réel problème pour le packaging.
Sauf que dans la vraie vie ces gens-là ont bien plus intéressant et utile à faire de leur temps et leur énergie, pour aider à résoudre d'autres problèmes qui font certainement râler quelqu'un d'autre sur le net.
Parce que tu pense que la lourdeur de Firefox n'est pas aussi (mais pas que) lié à ce genre de gestion ? Si demain, Mozilla trouve qu'OSGi est vraiment la meilleure manière pour gérer les plugins et ajoute comme dépendance à Firefox la JVM (et felix histoire de). Tu vois pas où est-ce que ça peut mener ?
Et si un jour ces problèmes deviennent gênants (oui ça arrive), les gens investissent plus d'effort là-dedans, on a un peu plus de cathédrale et un peu moins de bazaar le temps d'une restructuration, et ça repart.
Ouai on se traine une dette technique et il n'y a que quand on ne peu plus regarder ailleurs qu'on y fait attention. C'est une manière de faire, c'est pas la seule et je pense que tu peut comprendre que l'opposée est envisageable.
PS: et tout ce que j'ai dit est assez évident, tu aurais certainement pu faire l'effort de dérouler cette argumentation toi-même.
Tout comme sa critique était assez évidente, tu aurais probablement pu faire l'effort de la dérouler toi même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par barmic . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 2.
Je voulais dire « en allant 2 paragraphes plus bas ».
Merci je connais la logique qui induit ce genre de dépendances.
Soit.
D'arrêter de faire du bloatware. Avoir 2 runtimes (un perl et un python) pour finallement en exécuter un autre (JS), en passant son temps à faire des bindings dans tout les sens ces contre-productifs et contre-performant. Ça rend le logiciel plus compliquer à maintenir (multiplier les langages dans un même projet ça ne simplifie rien). Ça rend de plus le logiciel plus fragile si l'une des briques a un problème, firefox en a un.
Je vais me contenter de citer ce que j'ai dis dans le journal :
Si la raison est simplement qu'un développeur préfère tel ou tel langage, ça ne me semble pas être une bonne raison.
Le problème à grande échelle c'est que l'on arrive a avoir des systèmes de paquet dont le graphe de dépendances des paquets se rapproche d'une clique pour éxagérer. Tu peut le voir comme un aigri, mais c'est un réel problème pour le packaging.
Parce que tu pense que la lourdeur de Firefox n'est pas aussi (mais pas que) lié à ce genre de gestion ? Si demain, Mozilla trouve qu'OSGi est vraiment la meilleure manière pour gérer les plugins et ajoute comme dépendance à Firefox la JVM (et felix histoire de). Tu vois pas où est-ce que ça peut mener ?
Ouai on se traine une dette technique et il n'y a que quand on ne peu plus regarder ailleurs qu'on y fait attention. C'est une manière de faire, c'est pas la seule et je pense que tu peut comprendre que l'opposée est envisageable.
Tout comme sa critique était assez évidente, tu aurais probablement pu faire l'effort de la dérouler toi même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)