J'en doute fort, parce que .NET n'est ni plus ni moins qu'un outil bâtard entre le framework et la machine virtuelle de JAVA, selon moi.
Windows, exemple tellement cité, regorge de frameworks faisant le café… donc, les libristes ne sont pas les seuls.
En fait, je pense même que c'est l'exacte raison du succès de JAVA, et de .NET: l'abondance de fonctions au sein de la même (削除) merde (削除ここまで) chose.
Après, pour le reste, effectivement à lire les ressentis envers FF, un dev mozilla qui défends son patron me semble avoir assez peu à dire, au vu de ce que je vois sur DVP.
Après, je suis pas dev web/extensions donc il se peut que je me trompe quand j'ai l'impression que la stabilité des APIs laisse à désirer.
Ensuite, certains points d'intégration ne sont pas complexes à gérer, même sans librairies. (l'emplacement de la conf utilisateur, par exemple, ou il suffit de récup le contenu d'une variable… je serais heureux que plus de logiciels le fassent au lieu de pourrir mon ~/)
J'ignore si FF les respecte, cela dis, cela fait bien longtemps que je ne l'utilise plus. Utiliser une bdd pour stocker des favoris me fais assez tiquer, et de ce que je me souviens c'était un des trucs que FF faisait (sqlite3, ce me semble).
En revanche, pour le côté coup de gueule anti-toolkit… D'une part, je te rejoins, d'autre part je suis pas d'accord.
Les toolkits se sont construits à une époque ou ils étaient nécessaires car tout restait à faire, surtout en C++ qui est un langage (qui me semble) jeune, ayant trop peu d'outils en standard (d'où l'émergence de boost et Qt je dirais).
Donc, ces frameworks, même s'ils subissent les erreurs de leur passé, ont joué, et jouent toujours, un rôle utile, pour créer des logiciels utilisables autant sous windows que d'autres OS. Sans eux, je n'aurais jamais franchi le pas, parce que j'aurai dû découvrir à 100% mon environnement libre, plutôt que de le faire progressivement.
En revanche, je dois admettre que quand j'utilise ces frameworks, je fais mon maximum à utiliser des fonctionnalités standard au maximum: je bannis les XXString, notamment. Et quand c'est possible, j'ai une préférence pour boost, qui est un ensemble de librairies faiblement couplées les unes aux autres.
En gros, je pense que ces frameworks ont eus à trouver des workaround à un langage (C++) trop restreint suffisamment vite pour ne pas être freiné par des normes qui mettent 12 ans à naître (et je n'ai pas parlé d'implémentation).
Mais quand on peut utiliser les normes, je pense qu'il vaut mieux oublier les fonctionnalités équivalentes du framework. Une des raisons majeures pour lesquelles je n'aime pas Qt par exemple, c'est la modification de la chaîne de compilation. Mais je dois admettre qu'un soft Qt est portable et bénéficie de perf correctes… tant qu'il ne s'agit pas d'un truc KDE, qui impose de télécharger VLC-nox pour un émulateur de terminal…
Le problème, ce ne sont pas les frameworks, mais les environnement de bureau qui n'arrivent pas à faire des choses modulaire. Ce n'est pas du tout la même chose. (j'aimerai qu'on m'explique pourquoi un terminal doit installer un module son, qui lui-même dépend de vlc, le tout impliquant finalement d'installer phonon, dépendant de… je parle de Qt, mais gnome est pareil sur ce point)
J'ai dis le problème? En fait, non, c'est la conséquence. Le problème, c'est que l'on veut tout faire à moindre effort. Ce qui inclue l'effort de moindre conception. Ce qui génère un couplage fort d'éléments qui n'ont pas une utilité vitale (sérieux… coupler vlc et un terminal…)
# Libristes only? J'en doute fort...
Posté par freem . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 1.
J'en doute fort, parce que .NET n'est ni plus ni moins qu'un outil bâtard entre le framework et la machine virtuelle de JAVA, selon moi.
Windows, exemple tellement cité, regorge de frameworks faisant le café… donc, les libristes ne sont pas les seuls.
En fait, je pense même que c'est l'exacte raison du succès de JAVA, et de .NET: l'abondance de fonctions au sein de la même
(削除) merde (削除ここまで)chose.Après, pour le reste, effectivement à lire les ressentis envers FF, un dev mozilla qui défends son patron me semble avoir assez peu à dire, au vu de ce que je vois sur DVP.
Après, je suis pas dev web/extensions donc il se peut que je me trompe quand j'ai l'impression que la stabilité des APIs laisse à désirer.
Ensuite, certains points d'intégration ne sont pas complexes à gérer, même sans librairies. (l'emplacement de la conf utilisateur, par exemple, ou il suffit de récup le contenu d'une variable… je serais heureux que plus de logiciels le fassent au lieu de pourrir mon ~/)
J'ignore si FF les respecte, cela dis, cela fait bien longtemps que je ne l'utilise plus. Utiliser une bdd pour stocker des favoris me fais assez tiquer, et de ce que je me souviens c'était un des trucs que FF faisait (sqlite3, ce me semble).
En revanche, pour le côté coup de gueule anti-toolkit… D'une part, je te rejoins, d'autre part je suis pas d'accord.
Les toolkits se sont construits à une époque ou ils étaient nécessaires car tout restait à faire, surtout en C++ qui est un langage (qui me semble) jeune, ayant trop peu d'outils en standard (d'où l'émergence de boost et Qt je dirais).
Donc, ces frameworks, même s'ils subissent les erreurs de leur passé, ont joué, et jouent toujours, un rôle utile, pour créer des logiciels utilisables autant sous windows que d'autres OS. Sans eux, je n'aurais jamais franchi le pas, parce que j'aurai dû découvrir à 100% mon environnement libre, plutôt que de le faire progressivement.
En revanche, je dois admettre que quand j'utilise ces frameworks, je fais mon maximum à utiliser des fonctionnalités standard au maximum: je bannis les XXString, notamment. Et quand c'est possible, j'ai une préférence pour boost, qui est un ensemble de librairies faiblement couplées les unes aux autres.
En gros, je pense que ces frameworks ont eus à trouver des workaround à un langage (C++) trop restreint suffisamment vite pour ne pas être freiné par des normes qui mettent 12 ans à naître (et je n'ai pas parlé d'implémentation).
Mais quand on peut utiliser les normes, je pense qu'il vaut mieux oublier les fonctionnalités équivalentes du framework. Une des raisons majeures pour lesquelles je n'aime pas Qt par exemple, c'est la modification de la chaîne de compilation. Mais je dois admettre qu'un soft Qt est portable et bénéficie de perf correctes… tant qu'il ne s'agit pas d'un truc KDE, qui impose de télécharger VLC-nox pour un émulateur de terminal…
Le problème, ce ne sont pas les frameworks, mais les environnement de bureau qui n'arrivent pas à faire des choses modulaire. Ce n'est pas du tout la même chose. (j'aimerai qu'on m'explique pourquoi un terminal doit installer un module son, qui lui-même dépend de vlc, le tout impliquant finalement d'installer phonon, dépendant de… je parle de Qt, mais gnome est pareil sur ce point)
J'ai dis le problème? En fait, non, c'est la conséquence. Le problème, c'est que l'on veut tout faire à moindre effort. Ce qui inclue l'effort de moindre conception. Ce qui génère un couplage fort d'éléments qui n'ont pas une utilité vitale (sérieux… coupler vlc et un terminal…)