[Débat] Avenir des langages : .NET et C# seraient-ils en train de montrer la voie ?
Hello,
Un projet innovant (sur codeplex) -- innovant : je le pense sincèrement -- est en train de tirer grand profit des spécificités "les plus pointues" de C# / .NET à ce jour (i.e, C# 3.0, dernière release) et est peut être en train d'apporter une mini révolution dans la facilité de mise en oeuvre de nouveaux langages pour .NET, justement.
http://www.codeplex.com/irony
Ce [bref résumé historique] (voir plus bas), permettra de "se remettre dans le bain" pour ceux dont la mémoire flanche un peu mais qui n'ont rien contre une petite remise en contexte pour une participation apportée "bien à propos" à ce débat, sans perdre de vue l'enjeu de la question.
En effet, à la différence de la très grande majorité des constructeurs de compilateurs/interpréteurs, Irony ne s'appuie pas sur une méta notation "à la lex/yacc" pour exprimer tout ou partie de la syntaxe et/ou de la sémantique du langage cible, ni ne se propose comme un reconnaisseur / interpréteur générique utilisant la programmation dynamique ;
Irony explore une "troisième" voie, vraisemblablement tout à fait originale, qui consiste à modéliser le langage cible directement dans un sous ensemble du système de types .NET lui même (par des instances de classes Irony ou dérivées), destiné à être directement compilé et exécuté pour obtenir le reconnaisseur du langage ainsi spécifié.
Ainsi :
(approche classique)
specifications lex/yacc (et autres) pour le langage L
--> lex/yacc (autres) -->
--> source du reconnaisseur R(L) pour L (source en C, ou C++, Java, C#, etc)
--> compilation
--> reconnaisseur R(L) exécutable
--> traitement de P par R(L)
(approche Irony)
modèle de L dans un source C# 3.0 (utilisant le toolkit Irony)
--> compilation (par csc)
--> modèle de L compilé
--> exécution du modèle compilé sur un programme P (écrit en L)
--> (a) reconnaisseur R(L) pour L construit "à la volée"
--> (b) traitement de P par R(L)
D'aucuns diront que le principe est connu depuis longtemps avec certains compilateurs / interprètes dont l'analyseur syntaxique par exemple est écrit "à la main" (découpé en fonctions/procédures récursives) selon la "vieille" technique de la "descente récursive" (analyse de type "top-down", pour les langages de type "LL" surtout)
Mais c'est alors manquer le point clé de l'innovation d'Irony : là, on exprime le modèle de L avec les types du toolkit Irony, sans pour autant avoir à exprimer tous les détails d'implémentation du reconnaisseur ; car c'est en fait le fait même de compiler, par csc, ce modèle, puis de l'exécuter, qui construit le reconnaisseur (analyseur syntaxique, d'abord, puis évaluation sémantique complète, pour des langages triviaux, ou partielle, pour des langages plus utiles)
"Magique" ? Allons, rien n'est magique en logiciel, et je ne vous ferai pas l'affront de vous donner une paraphrase maladroite et incomplète des détails plus théoriques sur "le pourquoi ça marche", que vous avez de toute façon sur le site codeplex, ne serait qu'à travers le code source...
Votre avis ?
Bon débat.
PS :
[bref résumé historique]
Fin des années 50, le "FORmula TRANslator" (FORTRAN) fut le premier langage concret, utilisable, à élever le niveau d'abstraction
de l'expression d'une solution algorithmique par une syntaxe dite "de haut niveau" (car proche, même si caricaturale, de l'anglais parlé par ses premiers
utilisateurs programmeurs, ce qui n'était (n'est) pas le cas des langages dits "d'assemblage" ).
Parallèlement à la dichotomie "programmation fonctionnelle" / "non fonctionnelle" observable sur les nombreux autres langages qui ont vu le jour depuis,
une autre dichotomie, portant sur certains d'entre ceux-ci (LOO vs. non-LOO), a introduit l'idée que les données elles mêmes, instances de leurs types
("basiques" ou composites), pouvaient être manipulées comme des entités "actives" et non pas simplement comme des "inertes" totalement soumis
au bon vouloir des algorithmes.
Ce fut bien sûr, dès Simula 67, l'apport majeur du paradigme objet : oser voir les programmes comme des ensembles d'instances de classes,
implémentations de types de données abstraits ("spécifiables", comme la pile, la file, etc) qui coopèrent / collaborent,
à travers les deux relations fondamentales que sont l'héritage (pour, entre autres, la spécialisation des sous types),
et la relation client/fournisseur, qui veut exprimer au niveau de ces mêmes types, entre autres, le caractère plus ou moins déterministe
des échanges de messages entre objets appelants et appelés.
Il n'a pas "fallu longtemps" pour réaliser que le paradigme objet de ces langages de programmation, loin de n'être qu'une "technique"
de programmation algorithmique, était aussi, et de façon peut-être plus importante encore, un faisceau générateur de principes
de conception des plus naturels, puisque reprenant l'idée originelle de Simula 67 : modéliser le problème du monde réel dans
le programme qui s'exécute.
La suite de l'histoire est connue : après l'opération d'abstraction du monde réel dans les programmes, et sous la poussée des avancées
en matière d'architecture des ordinateurs (pour commencer, les micro processeurs, puis, par extension "mi-matérielle, mi-logicielle",
les systèmes d'exploitation eux mêmes), le temps fut venu d'opérer l'opération d'abstraction du langage objet vis à vis de ces mêmes
architecture : chose faite avec Java et .NET, mi-90's / début 21ème, avec leurs "Virtual Machine" / "Runtime" et "byte code" / "Intermediary Language".
Or, un projet récent, reconnu par beaucoup comme significativement novateur en matière de "constructeurs de langages",
passé presque totalement inaperçu pendant ses tout premiers mois, commence maintenant à attirer l'attention : Irony...
Répondre avec citation
Partager