Voici un concept intéressant à partager avec vous. Je vais vous parler aujourd’hui de LOP, Language Oriented Programming. Sergey Dmitriev est le cofondateur et CEO de JetBrains Inc., l’éditeur de l’excellent éditeur Java : IDEA IntelliJ. Il propose une nouvelle manière d’envisager notre travail de développeurs pour les années à venir. En quelques sortes, pour lui le futur ne sera plus au développement orienté objet, mais bien au développement orienté par le langage. Jusqu’ici vous ne comprenez rien, c’est normal. Bienvenue à bord.
Tout d’abord nous allons parler des raisons puis des moyens de la programmation LOP, à l’issue de l’article vous aurez une idée des concepts, et des liens vers des articles complémentaires.
Cet article est librement adapté de l’article original en anglais de Sergey Dmitriev.
L’origine de LOP : nous ne sommes pas libres
Sergey Dmitriev part de ce constat : aujourd’hui lorsque nous programmons, nous ne sommes pas libres. Nous devons nous adapter au langage Java. Malgré sa puissance, il n’est pas possible pour vous, en tant que développeur de sortir d’une zone délimitée par le langage, ses concepts et sa syntaxe.
Ne serait-il pas intéressant de réduire la dépendance de la même manière que Java nous a libéré de la contrainte de la plateforme ? Il est naturel de coder sur Windows et de déployer sur Solaris. Pourquoi ne pas poursuivre vers cette liberté ?
Les langages classiques (Java, C#, C++) se basent sur la modélisation objet, ce qui devient trop vague lorsqu’il faut modéliser des concepts métiers compliqués. L’alternative s’appelle DSL, mais ce concept donne un langage qui est trop fortement typé au problème. Exemple de DSL que vous connaissez tous : le SQL. Ce n’est pas un langage de programmatin mais d’expression dynamique.
Aujourd’hui nous vivons très bien avec ces contraintes. Pour cette raison on voit surgir des langages dynamiques ou plus réactif comme Groovy. Mais il n’y a pas de moyens pour un développeur d’exprimer son besoin de A à Z.
Sergey pour obtenir cette indépendance que je vais vous expliquer, propose un système qui permet de créer, modifier et utiliser le langage et son environnement. Pour que cela fonctionne, le système est simple, et son idée est que cela soit vraiment la prochaine révolution du monde du développement informatique… Tout un programme.
Le passage vers le code texte
Il faut faire le constat suivant pour comprendre la suite : aujourd’hui entre l’idée pour résoudre un problème que vous avez en tête et le langage Java, il y a un pont que l’on traverse. Sur ce pont, nous commençons par utiliser la syntaxe du langage pour exprimer notre idée. Ensuite nous utilisons la programmation orientée objet avec des Classes, des Interfaces. Enfin en Java nous sommes particulièrement bien outillés : nous utilisons Spring, Hibernate, Struts…
Entre l’idée que vous avez en tête et le programme final en Java, il y a donc bien un pont. Un bon développeur lisant votre code va se forger une représentation de ce que fait votre code. Mais en aucuns cas il ne pourra voir du premier coup ce que fait exactement votre programme. Merci la modélisation, nous cherchons aujourd’hui des palliatifs afin de représenter sous forme de diagramme ce que fait notre code.
Nous ne sommes pas libres car nous devons adapter à la conception objet un problème qui n’a peut-être pas besoin de classes ou d’interface. Nous ne sommes pas libres car nous devons nous en tenir à la syntaxe initiale. Enfin nous avons aujourd’hui de plus en plus de soucis avec le fait qu’il soit devenu indispensable d’être un expert en Spring, Hibernate ou autre…
L’éditeur et le format texte
Depuis des années sans même y faire attention, le résultat de notre travail n’est qu’un fichier texte portant une extension java. Certes nous nous amusons aussi avec le XML ou autre… mais au final nous laissons à nos suivants du code qui se lit avec un éditeur de texte.
Grâce aux IDE puissants, ce texte reprend son sens, l’éditeur reconnaît la syntaxe et lui donne vie. Dans ce cas, pourquoi continuer à travailler sur des fichiers plats ?
Prenez Microsoft Excel : l’outil le plus utilisé par le métier de la Finance par les analystes. Ceux-ci ne sont pas des programmeurs. Pourtant ils expriment des concepts financiers et le tout avec Excel… Et jusqu’à preuve du contraire, un fichier XLS n’est pas un fichier texte.
Supprimons cette contrainte d’avoir un fichier texte.
Comment perdre du temps
Nous perdons beaucoup de temps. Je vais faire plaisir à mon meilleur ami qui est un fan de C. Il n’a jamais traversé le pont pour venir du côté de Java. Je me place de son point de vue : nous sommes une communauté très active, qui au fil des années s’est inventée des outils, des frameworks, des logiciels afin de résoudre toutes sortes de problème. Et il est vrai que c’est une énorme force que d’avoir une communauté libre aussi active. Mais d’un autre côté, est-ce que cela vous éclate toujours de tapoter du XML pour configurer vos beans ? de bidouiller un fichier hbm.xml afin qu’Hibernate s’excite correctement sur votre classe ? de bidouiller avec Wicket là où parfois une JSP fait aussi bien et plus vite ? Est-ce que finalement nous nous sommes pas sur-outillés pour le plaisir ?
Est-ce que le développeur Java n’est pas devenu un Jacky roi du tuning ?
Je ne me moquerai plus des Clio Super Sport avec « The Sport Touch » sur la vitre arrière. Après tout je dors bien avec un tee-shirt « SpringSource » et j’avais un sweet SUN vendredi dernier…
Nous nous éclatons à perdre notre temps avec nos outils (Hibernate, Spring, Struts2) là où nous devrions bosser sur le code métier de nos applications.
J’adore Spring et consors, mais je pense qu’il est temps de passer la seconde. Continuons à examiner la programmation orientée langage.
A quoi ressemble un programme LOP alors ?
Sergey explique clairement que dans son concept, un programme LOP n’est PAS une suite d’instruction. Déroutant non ? Pour lui un programme est la solution à un problème. Vous devez implémenter une machine à café ? Imaginez une syntaxe qui vous permet de construire votre machine, d’assembler les parties, de définir les règles, sans trop utiliser d’instruction.
La programmation orientée langage devient simple : vous écrivez avec un langage que vous inventez ce que doit faire votre programme. Expression du besoin, rien de technique. C’est un story-board de cinéma qui raconte une histoire. Mais vous ne serez pas obligé de parler éclairage, prise de son, script, mise en scène, décor, habillage, dialogue… comme vous le feriez en Java « classique ».
Un langage LOP
Un langage LOP n’est donc pas forcément exprimé avec du texte. Il y a bien une structure pour définir ses concepts et comment ceux-ci s’arrangent. Il dispose d’un éditeur pour exprimer comment il doit être rendu et arrangé. Sa sémantique, comme la grammaire française, exprime les règles et les exceptions.
II. Comment maintenant modéliser son langage ?
Dans la première partie j’ai expliqué les idées de Sergey. Il explique en résumé qu’entre l’idée que vous avez en tête et son expression au final en Java, il y a un gouffre. Son point de vue est donc qu’il faut une alternative. Nous allons voir maintenant comment.
Le langage de structuration
Aussi compliqué que cela puisse paraître, LOP travaille avec plusieurs langages basés sur la syntaxe Java pour vous laisser créer votre langage. Dans un premier temps, le langage de Structuration permet d’exprimer la représentation de votre langage. Ainsi vous allez exprimer ce qu’est une méthode, une classe, pour peu que votre langage en ait besoin. Souvenez-vous : vous êtes entrain de créer votre langage. Vous pouvez ainsi inventer une « MethodeSimple » et une « MethodeAvecArguments » si cela vous semble utile. Oui vous pouvez inventer une « Closure » ou une « Annotation ».
Tout ceci ne se fait pas magiquement mais via un logiciel afin de vous aider : MPS (Meta Programming Model) est un logiciel de JetBrains encore à l’état de prototype. Il vous guide et vous permet donc d’écrire chacune des parties nécessaires pour modéliser votre langage. Je sais, je n’ai pas encore décrit toutes ses parties. On y reviendra.
La Structuration est donc la phase où vous sélectionnez dans votre grosse boîte de Lego les types de briques.
Définition de l’Editeur
Une fois votre Structure en place, il est temps de définir comment nous allons éditer et donc écrire du Machin avec un Editeur. Si vous vous souvenez du début : le texte n’est pas indispensable. De même que la modélisation utilise UML, nous allons utiliser un concept simple afin de définir et programmer… l’éditeur de votre langage.
Il faut savoir qu’au final un programme écrit avec votre langage sera stocké sous la forme d’un graphe d’objets. Donc que ce soit un programme texte ou un diagramme avec des boîtes, cela n’a pas d’importance. On conserve bien la notion de graphe d’objet, les objets étant vos briques Lego, l’Editeur c’est tout simplement l’outil qui va nous aider à assembler ces briques.
Concrètement vous allez définir un EditeurDeMethode, un EditeurDeClasse ou par exemple un EditeurDeClosure. Visuellement dans le logiciel MPS cela ressemble à du code. Des zones éditables vous laissent définir l’enchainement de l’édition, afin que lorsque l’utilisateur final puisse s’y retrouver. Vous venez donc d’écrire maintenant des choses pour éditer la Structure de votre langage.
Sergey voit l’édition d’un langage comme un ensemble de cellules. Il explique qu’un éditeur est structuré afin de suivre une suite d’opération. La première cellule par exemple contiendra la portée (public, private, protected). La deuxième cellule pourra contenir un modificateur comme static. La troisième cellule sera le nom de la méthode… etc. Imaginez vous entrain de préparer un formulaire de saisie pour qu’un développeur code avec votre langage.
Cela permettra à MPS d’aider le développeur avec de la coloration syntaxique. J’ai du mal à expliquer ce concept. Mais c’est en quelques sortes le moyen utilisé aujourd’hui pour justement valider votre code Java dans Eclipse : il utilise un moteur d’édition afin d’analyser et de vous signaler au moment de la saisie les boulettes dans le code. Là il s’agit donc d’écrire cet éditeur.
Le langage de Transformation
Nous avons la structure, l’éditeur. Voici le Transformateur ou générateur. Concept similaire à MDA, il s’agit maintenant d’exprimer avec un langage les systèmes de transformation de votre langage. Comment allons nous passer de ce que l’utilisateur a édité précedemment à du code exécutable ?
Il existe 2 systèmes : l’interprétation et la compilation. Soit votre transformateur va interpréter le code, soit nous allons vraiment le compiler en un langage classique comme Java, une fois pour toute. La première démarche fait penser à Groovy, là où la seconde me fait penser à la modélisation MDA.
La compilation va s’exprimer avec le langage de Transformation. Je m’explique : votre objectif est d’utiliser l’une des 3 techniques de LOP afin d’expliquer comment transformer la Structure vers du code standard. Vous pouvez tout d’abord travailler par approche itérative : votre langage de Transformation sera donc du style : « Pour toutes les Briques Rouges LEGO tu me donnes tel bout de code ». Cela consiste à introspecter le programme.
Il y a ensuite l’approche par modèle et macro. Nous pourrions imaginer 2 Briques Rouges et une Brique Jaune, cela donne automatiquement tel bout de code, une Hashmap par exemple. Les modèles sont très souvent utilisés, mais il faut alors définir de manière exhaustive les assemblages de code supportés.
Le troisième moyen est de se baser sur de la reconnaissance. Je regarde la Structure de ton langage et je suis alors capable de le compiler. Par exemple je vois une boucle « For ».. je peux alors décider de faire de l’inline code pour toi lecteur… Je vois une Annotation, je me débrouille alors pour t’ajouter un comportement dans le code généré…
Les Templates dans MPS sont des templates type Velocity ou Freemarker. Cela permet d’écrire rapidement du code de transformation. Les Patterns se basent sur votre propre langage, c’est donc un peu compliqué à expliquer ici en quelques lignes.
La boîte à outil
On sait que le succès de la plateforme Java est dû à son API qui, dès le départ, permet de gagner un temps fou et de ne pas réinventer la roue. Qui a encore la prétention d’écrire une Stack ou une FIFO ? c’est un peu comme ne pas reconnaître que ce problème a déjà été résolu et souvent de manière élégante. Dans ce cas, si nous parlons d’inventer un langage et d’avoir une approche de développement piloté par le Langage, n’y-a-t-il pas un risque de perdre ces bibliothèques ?
Sergey n’hésite pas à parler de « Base Language » et de « Collections Language ».
Le Base Language offre des structures de bases comme les boucles, les itérations, les opérateurs mathématiques. Car il serait lourd et stupide de devoir inventer son « Addition » par exemple. Vous pouvez donc vous en servir comme socle de départ afin d’écrire votre langage. Mais ce n’est pas une obligation. Si vous pensez que les variables, les itérations ne sont pas nécessaires pour modéliser votre idée, libre à vous de ne pas vous en servir.
Le Collection Language ressemble plutôt à une librairie pour moi. De même qu’en Java vous disposez du package java.util ou de la lib STL en C++, là il s’agit plus d’une librairie qu’autre chose.
Enfin il parle aussi de « User Interface Language » destiné à exprimer l’interface utilisateur. Là j’avoue je me suis repris un café et j’ai continué ma lecture.
MPS Meta Programming System
Cet outil de JetBrains est en cours de développement, il se destine à offrir un support pour la programmation orientée Langage (LOP). Je cherche un exemple simple pour vous montrer quelques concepts et essayer de voir si vraiment nous sommes face à une révolution… ou pas.
Conclusion
A travers cette traduction des idées de Sergey Dmitriev, j’ai essayé de présenter d’une part pourquoi cette démarche apparaît, puis ensuite comment elle se concrétise. Je pense en effet que dans un avenir proche, même si cela vous dérange, nous arrêterons d’écrire du code « tuyau ». Par code tuyau je parle bien de la soupe technique qui permet de mettre en marche correctement les outils du marché que sont Spring, Hibernate et Struts2.
Avec la Crise nous aurons moins de temps. Nos clients vont réduire les budgets, la demande du client reste la même mais en moins de temps. Nous pensons que les outils nous font gagner du temps. C’est vrai. Mais il faut voir qu’aujourd’hui l’apprentissage et la maîtrise du langage et des frameworks demande de plus en plus de temps. Il y a même une certaine fracture entre l’expert formé sur les dernières technologies et le développeur qui débute. Comment bien choisir le framework afin de rester sur le marché de l’emploi ?
Je me demande si nous aurons le temps d’enseigner correctement Hibernate ou Spring à l’université ou dans une école. Ces outils avancent plus vite que nous, et nous produisons de plus en plus de déchets, de code qui ne sert à rien…
L’approche LOP est à mon avis un peu trop compliquée pour l’instant. Je suis pragmatique : je ne vois pas demain un cas précis où je pourrai m’en servir. D’un autre côté cela fait 10 ans que je vis, pense, travaille, respire avec Java. Comment alors pourrais-je voir par le trou de la serrure si cette initiative a un avenir ou pas ?
A vous le micro…
Qu’en pensez-vous ?
Ressources
Blog de Sergey Dmitriev
Language Workbenches: The Killer-App for Domain Specific Languages? article très intéressant de Martin Fowler
Article Wikipedia sur Software Factory
Web Software Software Factory by Microsoft
Le Générateur Celerio de Jaxio propose une approche basée sur le modèle astucieuse.
VideoCast de Sebastien Arbogast dans lequel il explique comment créer un langage très simple.
Excellent article Nicolas.
Ce concept de LOP est vraiment ce qui a le meilleur potentiel pour combler les lacunes de la POO. Alors certes c’est encore très expérimental mais les gars de Jetbrains sont très intelligents et je suis sûr que leur implémentation évoluera vers quelque chose d’hyper productif.
Dommage qu’ils n’en parlent pas plus sur des events comme Devoxx.
Je pense qu’en ce moment nous voyons les lacunes du POO et que de plus en plus nous entendons parler des languages dynamiques comme closure par exemple.
Du nouveau à venir.
Salut Nicolas,
Je suis pour ma part très sceptique quand à cette approche/techno, probablement parceque que je sais pas où la « ranger ». Est-ce un DSL factory, un méta DSL, une sorte de MDA, un transformateur, un éditeur de langage ?
J’ai également un sentiment fort de « remballe » : les gens de jetbrain ont une techno très avancée pour la gestion de concepts et des langages. C’est certainement la raison pour laquelle une si petite équipe arrive à intégrer un support d’un nombre si conséquent de technos dans IntelliJ.
J’ai l’impression que Jetbrain a voulu faire du « plus » avec leur techno (ce qui est tout à fait louable). Toutefois je n’arrive pas vraiment à voir le bénéfice que peux retirer le développeur « de tous les jours ».
Pour ma part, si je doit réaliser un DSL, -pour l’instant- je me contenterai de technos plus rustiques 🙂
Florent.
Ca m’a l’air quand même très fumeux, et d’autant plus quand « The Next Programming Paradigm » est argumentée avec des exemples boiteux par un type qui veut avant tout revendre sa camelote.
Désolé, je suis pas acheteur, ou alors je suis en train de passer à côté de l’avenir, et je vais m’en mordre les doigts.
Mais bon, faut que je vous laisse, faut que j’aille développer tout en graphique avec des beans, et je dois définir la logique de mon programme en traçant à la souris des traits entre les beans… ha non pardon, ça c’était la programmation du futur d’il y a 10 ans… Décidemment, les futurologues sont toujours aussi bons ! 🙂
Salut nogunner,
pourquoi le futur d’il y a 10 ans ? Il y a 10 ans cela existait déjà et cela existe encore ! Labview en est un fameux exemple.
J’ai pu voir d’ailleurs voir ce que ca donnait sur un projet de microscope atomique au sein d’un labo du CEA: on arrive à faire tourner le bazar, mais c’est une *horreur*.
Et dire que pour que ca aille plus vite j’ai été obligé de refaire des composants … en assembleur ! Du grand n’importe quoi …
Comme quoi l’enfer est pavé de bonnes intentions.
Florent
@florent: Il y a dix ans, on essayait de nous faire croire que c’était le futur de la programmation, tout comme notre bon serguey essait de nous faire croire que son LOP c’est le futur de maintenant…
Je ne vais pas décortiquer son argumentation, ce serait laborieux, mais vraiment je suis totalement en désaccord avec lui. D’abord, parce que développer un DSL représente un travail très important en développement et maintenance, mais surtout parce que se pose en plus le problème de sa testabilité et de sa validation. Tester un langage, c’est un boulot énorme, on doit vérifier un maximum de cas de figure, et c’est sans commune mesure avec le test de quelques objets métiers.
Pour moi, mettre en place un DSL quand c’est nécessaire, oui, mais le généraliser un peu partout, sûrement pas, et c’est même dangereux. Remarque, gardons l’idée sous le coude, ça peut relancer l’industrie informatique si jamais ça va mal, parce qu’il faudra du manpower pour maintenir tout ça 🙂
Cela dit, son idée ne vas pas totalement et intégralement dans le sens d’un DSL généralisé, puisqu’il conclue son article en évoquant le pattern consistant à intégrer un langage de script et à coller des objets métiers dans le contexte, voire à y rajouter quelques structures syntaxiques spécifiques. Ca par contre, c’est beaucoup plus raisonnable et beaucoup plus intéressant, mais on n’est plus du tout dans le révolutionnaire, en revanche.
Et pour la petite histoire sur la programmation graphique à base de traits qui relient des composants, c’est bel et bien mort, malgré les quelques exemples anecdotiques qu’on peut encore trouver de ci de là. Avant de se suicider, l’idée a malheureusement eu le temps de faire des dégats 🙂
Je rejoins le cohorte des sceptiques. La solution proposée ressemble à un marteau-pilon d’éditeur d’atelier de génie logiciel.
Il y a certainement des classes de problèmes ayant un intérêt à passer par un langage spécifique « from scratch » mais si on reste pragmatique, on s’en sort dans de nombreux cas avec des solutions intermédiaires. Définir un (bon) langage en partant d’une page presque blanche n’a rien de trivial.
Ce que l’on cherche avant tout avec un DSL, c’est un moyen d’exprimer de manière plus claire des concepts propres à un domaine donné. Pour cela, il n’est pas forcément utile de réinventer la roue. On peut aussi s’appuyer sur les possibilités offertes par les langages existants. Je pense par exemple à LINQ pour lequel tout était déjà dans C# 2.0 si ce n’est les lambda expressions et un peu de sucre syntaxique sous la forme de quelques mots-clefs.
Avec un langage « générique » suffisamment évolué (il en existe plusieurs aujourd’hui : java, ecmascript, C#, …), on peut créer un simili DSL au sein du langage lui-même. Tout ce qu’il peut manquer c’est la possibilité de rajouter des mots-clefs pour simplifier l’écriture.
Par ailleurs, certains frameworks ont atteint un niveau d’expression tel que je ne vois pas trop de différence avec un DSL. Je pense par exemple à jQuery qui est un vrai langage spécifique à la manipulation de documents HTML interactifs.
Bref, je crois plutôt à une évolution progressive des langages génériques pour permettre le rajout de constructions spécifiques à un domaine plutôt qu’à des outils un peu trop magiques pour définir de « nouveaux » langages.
L’article de Sergey Dmitriev date de Novembre 2004 !, je pense donc que le produit n’a jamais vu le jour.
Ou alors es-tu au courant de nouvelles évolutions ?
Le produit a été mis à jour et les derniers mouvements datent de juillet 2008. Je l’ai installé et testé, mais c’est un outil un peu trop compliqué…
Florent a proposé de regarder Qi4J qui semble plus réalise et surtout qui a été fait par Rickard Öberg le bonhomme qui a bossé sur XDoclet, JBoss, WebWork et l’architecte de SiteVision.
Regardez
http://www.infoq.com/articles/Composite-Programming-Qi4j