Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
Je ne pense pas que l'on puisse parler de « modèle monolithique », en tout cas pas par idéologie.
Il est logique que :
- le langage soit répandu, pour avoir un maximum de contributeurs et une plus grande chance de survivre ;
- le langage permette d'écrire des bibliothèques « de base » (c'est-à-dire des .so pour ELF), pour être utilisables par un max. de programmes, en tout ou partie, et de manière optimale ;
- le projet ne s'éparpille pas en utilisant quarante langages.
À partir de là, les langages possibles sont le C (plus utilisé) et le C++ (un peu moins).
Ensuite, si les contributions sont d'utilisation générale, il est logique de demander que celles-ci s'intègrent dans l'existant, c'est-à-dire qu'elles puissent être utilisées depuis le langage choisi par le projet et qu'elles puissent aussi être intégrées dans des .so.
De plus, il est aussi bon de rappeler que Gnome a, dès le début, proposé une interaction via CORBA, et KDE via DCOP, permettant ainsi à une communication à la fois dynamique et ouverte (multi-langage).
Ça, c'était pour le côté « mono-langage ». En ce qui concerne l'aspect monolithique, rappelons encore que le modèle de KDE est compentiel (toujours DCOP) et que celui de Gnome ne l'est pas beaucoup moins. Ils sont largement plus modulaires que monolithiques.
Voilà pour ce point. Pour les autres points, complexité et cycle de développement, la complexité est inhérente à la nature de ce genre de projet et je ne vois pas trop ce que le cycle de développement peut poser comme problèmes au développeur d'applications Gnome ou KDE ou en quoi l'utilisation d'un langage interprété viendrait modifer ce cycle.
# monolithe ?!
Posté par Sylvain Sauvage . En réponse au journal Langages pour desktop. Évalué à 4.
Je ne pense pas que l'on puisse parler de « modèle monolithique », en tout cas pas par idéologie.
Il est logique que :
- le langage soit répandu, pour avoir un maximum de contributeurs et une plus grande chance de survivre ;
- le langage permette d'écrire des bibliothèques « de base » (c'est-à-dire des .so pour ELF), pour être utilisables par un max. de programmes, en tout ou partie, et de manière optimale ;
- le projet ne s'éparpille pas en utilisant quarante langages.
À partir de là, les langages possibles sont le C (plus utilisé) et le C++ (un peu moins).
Ensuite, si les contributions sont d'utilisation générale, il est logique de demander que celles-ci s'intègrent dans l'existant, c'est-à-dire qu'elles puissent être utilisées depuis le langage choisi par le projet et qu'elles puissent aussi être intégrées dans des .so.
De plus, il est aussi bon de rappeler que Gnome a, dès le début, proposé une interaction via CORBA, et KDE via DCOP, permettant ainsi à une communication à la fois dynamique et ouverte (multi-langage).
Ça, c'était pour le côté « mono-langage ». En ce qui concerne l'aspect monolithique, rappelons encore que le modèle de KDE est compentiel (toujours DCOP) et que celui de Gnome ne l'est pas beaucoup moins. Ils sont largement plus modulaires que monolithiques.
Voilà pour ce point. Pour les autres points, complexité et cycle de développement, la complexité est inhérente à la nature de ce genre de projet et je ne vois pas trop ce que le cycle de développement peut poser comme problèmes au développeur d'applications Gnome ou KDE ou en quoi l'utilisation d'un langage interprété viendrait modifer ce cycle.