Je rebondis sur le journal "Quel langage pour quel utilisation" ( http://linuxfr.org/~hrod/20037.html ) pour m'interroger sur les raisons et la pertinence du choix de langages interpretés pour des applications de "desktop".
Je pense en particulier à des applications comme :
- Perlpanel, une barre de taches proposant une trentaine de plugins, écrite en Perl.
- Pypanel, une barre de taches plus modeste, écrite en Python.
- L'environnement Rox, ou de nombreux plugins sont écrit en Python, et au moins un en Ruby
- Les environnements d'applet de bureau gdesklets et adesklets
Pour les environnements traditionnellement développés en C ou C++ comme XFCE, Gnome ou KDE, on voit murir des bindings Python, Perl, Ruby, voire Mono ou Java.
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++" ?
- Une critique de la complexité des librairies de ces environnements ?
- Une critique du cycle de développement sous ces mêmes environnements (et Klik serait une autre réponse à ce problème) ?
On peut déplorer la dilution des performances et l'occupation mémoire accrue de ces applications face à des langages compilés. Cependant, le principal "gaspillage" réside à mon sens, plus dans la multiplicité des interpreteurs utilisés que dans l'usage, en soi d'un interpréteur.
La multiplicité des interpréteurs se conjugue avec la multiplicité déjà contre-productive des librairies graphiques, ce qui fait qu'on peut craindre un appauvrissement du desktop linux face à l'homogénéité de Windows.
On peut aussi se réjouir que la marche d'entrée pour développer sa propre applet, sa propre extension de bureau, s'abaisse au cours du temps, et constitue en soi un avantage du desktop linux face à Windows.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
Je pense en particulier à des applications comme :
- Perlpanel, une barre de taches proposant une trentaine de plugins, écrite en Perl.
- Pypanel, une barre de taches plus modeste, écrite en Python.
- L'environnement Rox, ou de nombreux plugins sont écrit en Python, et au moins un en Ruby
- Les environnements d'applet de bureau gdesklets et adesklets
Pour les environnements traditionnellement développés en C ou C++ comme XFCE, Gnome ou KDE, on voit murir des bindings Python, Perl, Ruby, voire Mono ou Java.
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++" ?
- Une critique de la complexité des librairies de ces environnements ?
- Une critique du cycle de développement sous ces mêmes environnements (et Klik serait une autre réponse à ce problème) ?
On peut déplorer la dilution des performances et l'occupation mémoire accrue de ces applications face à des langages compilés. Cependant, le principal "gaspillage" réside à mon sens, plus dans la multiplicité des interpreteurs utilisés que dans l'usage, en soi d'un interpréteur.
La multiplicité des interpréteurs se conjugue avec la multiplicité déjà contre-productive des librairies graphiques, ce qui fait qu'on peut craindre un appauvrissement du desktop linux face à l'homogénéité de Windows.
On peut aussi se réjouir que la marche d'entrée pour développer sa propre applet, sa propre extension de bureau, s'abaisse au cours du temps, et constitue en soi un avantage du desktop linux face à Windows.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
> Lire le journal (93 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #651980.



avis
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.
RubyFrance
[^]Re: avis
Tout a fait, comme Perl avec son futur parrot http://www.parrotcode.org/ , que pense utiliser aussi les developpeurs de PHP, et qui sera certainement utilisé par d'autres langages de scripts. (parrot est une machine virtuelle, executant donc du bytecode, avec garbage collector et tout le toutim)
[^]Re: avis
parrot ? pour l'instant c'est plus du vaporware non ?
manatlan.com
[^]Re: avis
Disons du vaporware que tu peux télécharger et essayer, quoi: ftp://ftp.cpan.org/pub/CPAN/authors/id/L/LT/LTOETSCH/parrot-(...)
Avec même pleins des vraies choses qui marchent, sisi !
[^]Re: avis
> que pense utiliser aussi les developpeurs de PHP
Source ? pour suivre le développement de PHP je peux t'assurer que ce n'est pas du tout le cas.
Il y a certes deux personnes qui ont fait un jet pour s'amuser mais c'est resté du domaine de l'anecdote.