Re: Un nouveau langage

Bonjour Hervé,

On 2 sept. 2010, at 15:50, Hervé Agnoux wrote:

> Quelques remarques rapides :
> 
> 1) J'ai rien compris :-)
> 

lol. Bon, en fait, c'est assez simple à résumer :
Pense à un compilateur : du texte "source" -> un exécutable.
Nous faisons cela avec notre innovation avec l'exécutable = un fichier war déployable.
En ce qui concerne les entrées, nous avons aujourd'hui plusieurs méthodes, dont une à partir d'un document Word et des informations structurées (tableau, paragraphe, ...).
Cette dernière approche correspond bien à un profile "non développeur" et commercialement (plutôt "marketingement") le message passe bien.
Cependant, c'est trop verbeux pour moi et pour des profils développeurs.

Bref, nous voilà à définir un nouveau langage qui sera l'entrée "source" du compilateur.

J'ajoute que nous ciblons des applications type CRUD.

> 2) Si tu veux faire un truc qui ressemble à du java, alors il est préférable 
> que une chose du java ressemble à une même chose dans le nouveau langage, et 
> donc qu'une marque d'annotation java soit une sorte d'annotation dans le 
> nouveau langage.

En fait, c'est une pure analogie.
Pour faire ce langage, l'idée est bien sur de définir quelque chose de simple à apprendre et à manipuler.
Quelque chose de proche de Java pour nous autres développeurs Java.
J'ai donc repris des annotation l'idée de la notation à base d'arobase @.
Une ligne comprenant un @ ne donnera aucunement un annotation dans le code Java exécutable en sortie du compilateur.

> 
> 3) Il existait jadis un "nouveau langage" qui m'avait beaucoup intéressé, et 
> qui ressemble à ton principe de démarrer par une déclaration d'application 
> (c'était block, je crois), qui était le SDL, ou LDS en français. (voir 
> http://en.wikipedia.org/wiki/Specification_and_Description_Language ou 
> http://rangiroa.essi.fr/cours/reseau2/01-SDL.pdf en français). Ça ressemblait 
> bien à ton idée que je crois deviner de reprendre les niveaux fonctionnels 
> d'une appli. Par contre, pour la simplicité, c'était pas gagné. (mais est-ce 
> qu'une appli c'est simple ? )
> 

OK, je vais regarder.

> 4) Que penses-tu du travail autour de Roo ? (http://www.springsource.org/roo 
> et http://www.springsource.org/roo/why) Ce me semble être un projet pour 
> construire le squelette ou maquette d'applications ?
> 

Nous pourrions utiliser Roo comme un des éléments de l'architecture logicielle de ce que nous générons.
Seam aussi par exemple.
Cela étant, il est plus simple pour nous de ne pas faire de la génération à tiroir, c'est déjà assez complexe comme çà.
Nous ne générons donc pas des entrées pour un autre générateur, nous générons donc directement de quoi faire une application JEE.


Voici la stack logicielle de nos "targapp", c'est à dire les applications que nous générons :
Un client Qooxdoo (pure javascript)
Une sérialisation client-serveur JSON
Des classes Java pour le serveur (pas de framework particuier)
Une couche de mapping Objet-Relationnel : OpenJPA.
JDBC
Une base relationnelle.

> Bon ça suffit les questions pour cette fois, bien que j'en ai encore 
> Integer.MAX_VALUE en réserve.
> 

Pas de problème, utilisons plutôt des BigInteger, comme çà plus de limite en dur :-)

> Le jeudi 2 septembre 2010, Jean-Baptiste BRIAUD -- Novlog a écrit :
>> Bonjour à tous,
>> 
>> Après une période d'expérimentation et de consolidation de notre
>> innovation, nous ouvrons le chantier d'une version textuelle de notre
>> langage. Pour moi, c'est un retour aux sources car j'ai commencé par une
>> version textuelle il y a quelques années.
>> 
>> Bref, je voulais partager avec vous au début de ce chantier quelques
>> options pour ce langage et avoir votre avis. Toute les suggestions sont
>> les bienvenues, même si en apparence elles semblent saugrenues  :-)
>> 
>> La syntaxe générale sera de type C/Java/Javascript.
>> Un grand classique et une justification qui n'a pas changé : tout le monde
>> la connait cette syntaxe. L'effort d'apprentissage sera donc en principe
>> simplifié.
>> Inconvenient : çà n'est pas une syntaxe générique comme XML ou LISP.
>> Cela peut aussi être perçu comme un avantage par certains :-)
>> 
>> Donc, nouveau concept = nouveaux éléments de syntaxe, contrairement à XML
>> par exemple : <personne name="blabla"/>
>> Si on souhaite ajouter un prénom, c'est simple :
>> <personne name="blabla" prénom="blibli" />
>> Evidement, il y a un prix : c'est une syntaxe verbeuse et horrible, enfin à
>> mon avis ... Car l'objectif est bel et bien un langage que nous
>> utiliserons (moi le premier), alors il faut que des développeurs puissent
>> avoir envie de programmer avec.
>> 
>> Donc, une syntaxe à la C pour résumer.
>> 
>> Nous fabriquons une application complète, le premier élément sera donc
>> <application> Les symboles > et < sont à comprendre comme une espèce de
>> BNF, çà n'est pas de l'XML. Par exemple :
>> 
>> application test1 {
>> 	lang = fr;
>> }
>> 
>> Il faut identifier la langue dans laquelle les spécifications sont faites,
>> c'est donc une sorte d'attribut de l'application. Je préfère lang = fr
>> plutôt que lang : fr, histoire que cela ressemble à un attribut comme en
>> Java. Qu'en pensez-vous ?
>> 
>> test1 est le nom, disons "technique" de l'application, mais il y a un nom
>> plus "end user". Comment le spécifier ? Je propose 2 options, laquelle
>> préférez-vous et pourquoi ?
>> 
>> option 1 :
>> application test1 "C'est mon premier test" {
>> 	lang = fr;
>> }
>> 
>> option 2 :
>> @name("C'est mon premier test")
>> application test1 {
>> 	lang = fr;
>> }
>> 
>> option 3 :
>> application test1 {
>> 	lang = fr;
>> 	name = "C'est mon premier test";
>> }
>> 
>> Le nom long doit avoir des guillemet, pas le nom technique qui du coup ne
>> doit pas avoir d'espace ou de caractères trop "exotiques", comme le nom
>> d'une classe en Java.
>> 
>> Evidement, à part une ressemblance bien réelle avec une annotation, çà
>> n'est pas une annotation. En conséquence, je voix ne doit jamais se faire
>> par rapport à des considérations techniques. Seule la "beauté", la
>> simplicité de la grammaire compte.
>> 
>> L'option 2 est plus verbeuse, mais permettra d'ajouter facilement d'autres
>> éléments qui vont arriver. L'option 1 est plus sobre et moins connoté
>> Java.
>> L'option 3 est un peu trop JSON à mon gout, nous envisageons un langages,
>> pas une sorte de fichier properties ...
>> 
>> 
>> D'une manière générale, à la Java/C, les éléments dans les {} ne sont pas
>> ordonnés. Ainsi :
>> application nom {
>> 	a;
>> 	b;
>> }
>> 
>> est équivalent à
>> application nom {
>> 	b;
>> 	a;
>> }
>> 
>> 
>> En revanche, en dehors des {}, l'ordre est important comme par exemple pour
>> l'option 1. application nom "nom long".
>> 
>> 
>> Il y a tout de même une contrainte technique : une grammaire doit pouvoir
>> se définir pour fabriquer un lexer/parser avec SableCC ou Tatoo (pas
>> encore décidé lequel mais on utilise déjà SableCC à plusieurs reprise dans
>> notre compilo) Bref, vos commentaires sont les bienvenus !
>> 
>> JBB.
>> 
>