Cet engouement pour les langages interprétés est-il :
- Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
Non, car il n'y aurait aucun intérêt à ce que GNOME et KDE soient codés en langage script, et la première raison est la réactivité du desktop.
Je pense que c'est une grosse erreur de mettre face à face desktop et applications. Le desktop se doit d'être réactif donc codé avec des langages compilés bas niveaux, mais proposant un certain nombre de binding.
L'intérêt des binding est de permettre aux développeurs de coder une application desktop très rapidement en utilisant un langage de plus haut niveau, comme les langages scripts.
Ensuite tout dépend de l'application, et certaines sont codées en C ou C++. Mais pour la plupart un langage script suffit largement, avec au pire une extension C ou C++ ajoutée au langage script (swig aide bien pour cela) pour un fonctionnalité particulière.
Certe, un desktop est composé d'applications, et l'on peut se dire que si celles-ci finissent par être toutes codées en script, cela reviendra à avoir un desktop lent.
Cependant pour moi la base du desktop c'est tout d'abord les biblitohèques de base, GTK+, Glib, Gstreamer, QT, etc, et les lib GNOME et KDE. Ensuite tous les démons associés au desktop (gconf, session, etc...). Tout cela se doit de rester en C ou C++ pour des raisons de perf.
Ensuite un Evolution codé en python ? Pourquoi pas, même s'ils utiliseront surement plus GTK# et mono.
Donc non il n'y a pas de lutte entre les langages de niveaux différents, le C et le C++ trouveront leur place dans les bibliothèques, binding et les services desktop.
Quant à définir un langage script dédié à un desktop je ne suis pas convaincu. Un développeur attaché à perl, python, ruby ... ne changera pas comme ça. Et je n'en vois pas l'intérêt tant qu'il existe un bon binding supportant toute l'API du desktop.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait". http://freedesktop.org
Pour me répéter je ne vois pas l'intérêt d'avoir un standard au niveau langage, il faut laisser le choix aux développeurs, autant que l'on laisse le choix aux utilisateurs pour leur desktop. Il faut avoir un standard au niveau desktop et c'est le but de freedektop.
Si les desktop finissent par utiliser les mêmes bibliothèques, comme Gstreamer par exemple, peu importe ensuite le langage utilisé.
Au contraire je reste persuadé que si l'on veut attirer les développeurs VB, Windev, Delphi, etc, leur laisser le choix d'un langage haut niveau est important.
Certe le prix à payer est la multicité des interpréteurs, mais ceux-ci se dirigent vers des VM. Et l'évolution du matériel compense pas mal.
# avis
Posté par fredix . En réponse au journal Langages pour desktop. Évalué à 8.
- Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
Non, car il n'y aurait aucun intérêt à ce que GNOME et KDE soient codés en langage script, et la première raison est la réactivité du desktop.
Je pense que c'est une grosse erreur de mettre face à face desktop et applications. Le desktop se doit d'être réactif donc codé avec des langages compilés bas niveaux, mais proposant un certain nombre de binding.
L'intérêt des binding est de permettre aux développeurs de coder une application desktop très rapidement en utilisant un langage de plus haut niveau, comme les langages scripts.
Ensuite tout dépend de l'application, et certaines sont codées en C ou C++. Mais pour la plupart un langage script suffit largement, avec au pire une extension C ou C++ ajoutée au langage script (swig aide bien pour cela) pour un fonctionnalité particulière.
Certe, un desktop est composé d'applications, et l'on peut se dire que si celles-ci finissent par être toutes codées en script, cela reviendra à avoir un desktop lent.
Cependant pour moi la base du desktop c'est tout d'abord les biblitohèques de base, GTK+, Glib, Gstreamer, QT, etc, et les lib GNOME et KDE. Ensuite tous les démons associés au desktop (gconf, session, etc...). Tout cela se doit de rester en C ou C++ pour des raisons de perf.
Ensuite un Evolution codé en python ? Pourquoi pas, même s'ils utiliseront surement plus GTK# et mono.
Donc non il n'y a pas de lutte entre les langages de niveaux différents, le C et le C++ trouveront leur place dans les bibliothèques, binding et les services desktop.
Quant à définir un langage script dédié à un desktop je ne suis pas convaincu. Un développeur attaché à perl, python, ruby ... ne changera pas comme ça. Et je n'en vois pas l'intérêt tant qu'il existe un bon binding supportant toute l'API du desktop.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
http://freedesktop.org
Pour me répéter je ne vois pas l'intérêt d'avoir un standard au niveau langage, il faut laisser le choix aux développeurs, autant que l'on laisse le choix aux utilisateurs pour leur desktop. Il faut avoir un standard au niveau desktop et c'est le but de freedektop.
Si les desktop finissent par utiliser les mêmes bibliothèques, comme Gstreamer par exemple, peu importe ensuite le langage utilisé.
Au contraire je reste persuadé que si l'on veut attirer les développeurs VB, Windev, Delphi, etc, leur laisser le choix d'un langage haut niveau est important.
Certe le prix à payer est la multicité des interpréteurs, mais ceux-ci se dirigent vers des VM. Et l'évolution du matériel compense pas mal.