Lisaac se veut un langage de très haut niveau comme Smart Eiffel et Self, tout en gardant un accès bas niveau au hardware et de bonne performance. Il se veut clairement un concurrent du C.
mmm, là j'ai du mal.
J'ai du mal parce que ça donne l'impression que Lissac veut cumuler les avantages du haut niveau avec les avantages du bas niveau. Je stigmatise mais y'a de ça. Or l'expérience montre que c'est loin d'être simple. C'est ultra ambitieux, on ne peut certes pas démontrer que c'est impossible, mais quelques décennies d'informatique nous montrent que bon, y'en a qui ont essayé, ils ont eu des problèmes.
Ma vision de la chose, c'est qu'au contraire il vaut mieux laisser C là où il est, tranquille, le conserver en tant qu'interface de base pour les bibliothèques. Ca n'empêche pas de s'extraire ensuite de toute cette plomberie avec un langage de plus haut niveau. C'est ce qui est fait pour la plupart des applications web d'ailleurs, vous avez un moteur en C (un mod_python, un PHP, voire une machine virtuelle JAVA) et par-dessus quelque chose de plus haut niveau qui tourne. Le cloisonnement bas niveau / haut niveau n'est pas quelque chose dont il faut essayer de se débarasser AMHA. Au contraire... Ca permet d'y voir clair. Au langage C le traitement de tableaux, de matrices de flottants agencés tout bien comme il faut pour que ça arrive tout près tout chaud dans un pipeline graphique. A un autre langage la tâche plus "noble" de décider si oui ou non on va exécuter telle ou telle chose, de savoir si oui ou non il faut afficher ou pas telle ou telle chose à l'écran. En clair: quand on fait du bas niveau, ce qui compte, c'est de savoir ce qu'on fait, et à ce jeu là C gagne à tous coups. Après, si on veut faire de l'orienté objet, on extrait une API (avec SWIG par exemple), et on s'amuse dans un vrai langage type Python, Perl, Ruby, voire Java pour ceux qui pensent que c'est souple (*sigh*).
Les exemples d'applications construites sur ce modèle sont légions, déjà, le site même sur lequel vous lisez ces pages, c'est un gros moteur C (PHP) qui lance des scripts. Et accessoirement le tout génère du HTML, à partir de requêtes SQL. 4 langages impliqués au minimum. Chacun son job.
Ensuite, en vrac : Quake, Emacs, Mozilla, Gimp -> tous utilisent à des degrés divers des langages différents pour chacune des tâches à exécuter. Quake en C avec de l'assembleur pour le "très bas niveau" et un langage de plus haut niveau ad-hoc (Quake-C) pour faire des mods et articuler tout ça. Emacs, c'est le plus vieux dans les exemples que je cite, et ça n'est jamais rien qu'une grosse machine virtuelle (Emacs)Lisp... codée en C. Mozilla et XPFE, dans le genre multilangage c'est une caricature... Et Gimp, hé ben yet another example.
Tout ça pour dire qu'autant je pense que l'évolution des langages n'est pas terminée, autant le créneau "du C en plus joli" est bouché. Si c'est pour damer C sur son créneau, il faut faire mieux sur son créneau. Et pas ailleurs. Donc faire "plus facile de contrôler soi-même la mémoire", "plus rapide", et "plus de bibliothèques supportées". Voyez avec les gens qui continuent à développer en C aujourd'hui, je ne suis pas sûr qu'ils pensent "C n'est pas assez haut niveau". En tous cas pas moi. Si tel était le cas, ils seraient passés à autre chose... Le cas C++ est bâtard, et je suis certain que nombre de spécialistes C++ trouveraient leur pied bien plus facilement côté C#, Java, voire même plus simplement en langage de script. L'orienté object en C++, j'ai donné, c'est à chier. Tous les inconvénients du C alliés à la lourdeur d'un formalisme ultra-rigide.
Pour moi le truc qui pourrait révolutionner quelque chose, c'est un modèle, un framework, une façon de faire, un "truc" qui me permette de faire de l'assembleur, du C, du SQL, du Python, du HTML de manière transparente sans avoir à me soucier de rien. C'est là-dessus que j'ai besoin de simplicité. Il y a bien des efforts, .Net de Microsoft va dans ce sens, mais reste très limité car le principe de bytecode intermédiaire est très limitatif (pas trivial de représenter tous les paradigmes de tous les langages avec une fidélité parfaite, on ne veut pas le plus petit dénominateur commun de tous, sinon Perl ou Scheme perdent toute saveur une fois rentrés dans le moule), SWIG fait gagner un temps précieux mais la plomberie reste présente. Dans l'ensemble je pense qu'on n'a pas fini de réfléchir sur le problème.
Donc voilà, en tant que programmeur, ce qui me ferait triper c'est d'avoir "quelque chose" qui me permette d'utiliser *simplement* le langage le plus adapté à chaque problème. Et certainement pas qu'on me dise "j'ai trouvé le langage Y qui va remplacer le langage X".
Je ne vois pas trop qui mieux que Perl 6 pourra supplanter Perl 5, et avant de s'attaquer à l'assembleur ou à C, il faut se poser la question de savoir "dans quel but?". L'assembleur, pour ne prendre que cet exemple, a toujours ses applications. On s'en sert toujours. On s'en sert de moins en moins mais par définition il est irremplaçable. Ce qu'il faut, c'est simplifier l'interface entre l'assembleur et les candidats de plus haut niveau, mais en aucun cas on ne peut s'en débarasser. Le C ne l'a en fait d'ailleurs pas "remplacé", il a simplement remplacé l'assembleur dans les cas où ce dernier n'avait aucun intérêt, aucune valeur ajoutée. Pour qu'un candidat au "remplacement de C" aujourd'hui ait une chance, il faudrait que C soit utilisé dans un cas où il n'a aucune valeur ajoutée par rapport à un autre langage existant (de plus haut niveau par exemple). Sachant qu'aujourd'hui il y a 40 manières de faire une "base" en C et une sur-couche de plus haut niveau (regardez Lua, c'est excellent), ceux qui ne le font pas le font AMHA pour 4 raisons:
- ils ne connaissent pas et n'ont pas envie de connaître (depuis le temps...);
- ils ont un tel passif, une telle somme de code existant, que bon ils sont forcés de continuer en C;
- ils obéissent à une norme (cas typique en entreprise) qui dicte de manière plus ou moins arbitraire "ici les développements se font en XYZ";
- ils ont une vraie bonne raison, C leur convient parfaitement, alors...
Pour motiver ces gens-là à changer, bon courage.
Ceci étant, dans le cadre de recherches scientifiques, il est tout à fait compréhensible et souhaitable qu'on ne vise pas l'application directe et immédiate, donc Lisaac, bah très bien, faut continuer!
# One size fits all
Posté par ufoot . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 8.
mmm, là j'ai du mal.
J'ai du mal parce que ça donne l'impression que Lissac veut cumuler les avantages du haut niveau avec les avantages du bas niveau. Je stigmatise mais y'a de ça. Or l'expérience montre que c'est loin d'être simple. C'est ultra ambitieux, on ne peut certes pas démontrer que c'est impossible, mais quelques décennies d'informatique nous montrent que bon, y'en a qui ont essayé, ils ont eu des problèmes.
Ma vision de la chose, c'est qu'au contraire il vaut mieux laisser C là où il est, tranquille, le conserver en tant qu'interface de base pour les bibliothèques. Ca n'empêche pas de s'extraire ensuite de toute cette plomberie avec un langage de plus haut niveau. C'est ce qui est fait pour la plupart des applications web d'ailleurs, vous avez un moteur en C (un mod_python, un PHP, voire une machine virtuelle JAVA) et par-dessus quelque chose de plus haut niveau qui tourne. Le cloisonnement bas niveau / haut niveau n'est pas quelque chose dont il faut essayer de se débarasser AMHA. Au contraire... Ca permet d'y voir clair. Au langage C le traitement de tableaux, de matrices de flottants agencés tout bien comme il faut pour que ça arrive tout près tout chaud dans un pipeline graphique. A un autre langage la tâche plus "noble" de décider si oui ou non on va exécuter telle ou telle chose, de savoir si oui ou non il faut afficher ou pas telle ou telle chose à l'écran. En clair: quand on fait du bas niveau, ce qui compte, c'est de savoir ce qu'on fait, et à ce jeu là C gagne à tous coups. Après, si on veut faire de l'orienté objet, on extrait une API (avec SWIG par exemple), et on s'amuse dans un vrai langage type Python, Perl, Ruby, voire Java pour ceux qui pensent que c'est souple (*sigh*).
Les exemples d'applications construites sur ce modèle sont légions, déjà, le site même sur lequel vous lisez ces pages, c'est un gros moteur C (PHP) qui lance des scripts. Et accessoirement le tout génère du HTML, à partir de requêtes SQL. 4 langages impliqués au minimum. Chacun son job.
Ensuite, en vrac : Quake, Emacs, Mozilla, Gimp -> tous utilisent à des degrés divers des langages différents pour chacune des tâches à exécuter. Quake en C avec de l'assembleur pour le "très bas niveau" et un langage de plus haut niveau ad-hoc (Quake-C) pour faire des mods et articuler tout ça. Emacs, c'est le plus vieux dans les exemples que je cite, et ça n'est jamais rien qu'une grosse machine virtuelle (Emacs)Lisp... codée en C. Mozilla et XPFE, dans le genre multilangage c'est une caricature... Et Gimp, hé ben yet another example.
Tout ça pour dire qu'autant je pense que l'évolution des langages n'est pas terminée, autant le créneau "du C en plus joli" est bouché. Si c'est pour damer C sur son créneau, il faut faire mieux sur son créneau. Et pas ailleurs. Donc faire "plus facile de contrôler soi-même la mémoire", "plus rapide", et "plus de bibliothèques supportées". Voyez avec les gens qui continuent à développer en C aujourd'hui, je ne suis pas sûr qu'ils pensent "C n'est pas assez haut niveau". En tous cas pas moi. Si tel était le cas, ils seraient passés à autre chose... Le cas C++ est bâtard, et je suis certain que nombre de spécialistes C++ trouveraient leur pied bien plus facilement côté C#, Java, voire même plus simplement en langage de script. L'orienté object en C++, j'ai donné, c'est à chier. Tous les inconvénients du C alliés à la lourdeur d'un formalisme ultra-rigide.
Pour moi le truc qui pourrait révolutionner quelque chose, c'est un modèle, un framework, une façon de faire, un "truc" qui me permette de faire de l'assembleur, du C, du SQL, du Python, du HTML de manière transparente sans avoir à me soucier de rien. C'est là-dessus que j'ai besoin de simplicité. Il y a bien des efforts, .Net de Microsoft va dans ce sens, mais reste très limité car le principe de bytecode intermédiaire est très limitatif (pas trivial de représenter tous les paradigmes de tous les langages avec une fidélité parfaite, on ne veut pas le plus petit dénominateur commun de tous, sinon Perl ou Scheme perdent toute saveur une fois rentrés dans le moule), SWIG fait gagner un temps précieux mais la plomberie reste présente. Dans l'ensemble je pense qu'on n'a pas fini de réfléchir sur le problème.
Donc voilà, en tant que programmeur, ce qui me ferait triper c'est d'avoir "quelque chose" qui me permette d'utiliser *simplement* le langage le plus adapté à chaque problème. Et certainement pas qu'on me dise "j'ai trouvé le langage Y qui va remplacer le langage X".
Je ne vois pas trop qui mieux que Perl 6 pourra supplanter Perl 5, et avant de s'attaquer à l'assembleur ou à C, il faut se poser la question de savoir "dans quel but?". L'assembleur, pour ne prendre que cet exemple, a toujours ses applications. On s'en sert toujours. On s'en sert de moins en moins mais par définition il est irremplaçable. Ce qu'il faut, c'est simplifier l'interface entre l'assembleur et les candidats de plus haut niveau, mais en aucun cas on ne peut s'en débarasser. Le C ne l'a en fait d'ailleurs pas "remplacé", il a simplement remplacé l'assembleur dans les cas où ce dernier n'avait aucun intérêt, aucune valeur ajoutée. Pour qu'un candidat au "remplacement de C" aujourd'hui ait une chance, il faudrait que C soit utilisé dans un cas où il n'a aucune valeur ajoutée par rapport à un autre langage existant (de plus haut niveau par exemple). Sachant qu'aujourd'hui il y a 40 manières de faire une "base" en C et une sur-couche de plus haut niveau (regardez Lua, c'est excellent), ceux qui ne le font pas le font AMHA pour 4 raisons:
- ils ne connaissent pas et n'ont pas envie de connaître (depuis le temps...);
- ils ont un tel passif, une telle somme de code existant, que bon ils sont forcés de continuer en C;
- ils obéissent à une norme (cas typique en entreprise) qui dicte de manière plus ou moins arbitraire "ici les développements se font en XYZ";
- ils ont une vraie bonne raison, C leur convient parfaitement, alors...
Pour motiver ces gens-là à changer, bon courage.
Ceci étant, dans le cadre de recherches scientifiques, il est tout à fait compréhensible et souhaitable qu'on ne vise pas l'application directe et immédiate, donc Lisaac, bah très bien, faut continuer!