Xtends : la fondation Eclipse sort un nouveau langage compatible Java

Xtends : la fondation Eclipse sort un nouveau langage
Compatible Java, qui allège et enrichit les codes sources



La fondation Eclipse, qui fête son dixième anniversaire, a discrètement lancé un nouveau langage de programmation appelé Xtends.

Certainement en ligne en vue d'une annonce imminente, le site du langage tente de résumer le projet et ses motivations en une seule phrase : « Embrasser Java, mais éliminer le bruit et ajouter un peu de sucre ».

La fondation, satisfaite du langage qui a fait la renommée de son IDE, choisi donc l'approche des compilateurs. Le résultat final reste du « code Java lisible », fait savoir la fondation, mais les développeurs écriront dans une « alternative plus commode dans les situations où Java ne brille pas ».

Cette approche peut donc être assimilée à celle de CoffeeScript pour JavaScript, moins radical que les « java-killer » à profusion, souvent basés sur la JVM (machine virtuelle java).

Le projet de la fondation se présente modestement comme un ensemble de plug-ins qui viennent se greffer à une installation existante de l'IDE Eclipse, embarquant les Java Development Tools (JDT).

L'édition du code Xtends jouit donc des mêmes capacités d'édition de code Java, comme la coloration syntaxique, le renommage de refactorisation, l’organisation des imports, corrections rapides, survol riche...

Il n'y a donc pas de raison de se plaindre de l’absence d'outils dont souffre habituellement chaque nouveau langage. Xtends n'est même finalement presque que ça : « une fine couche autour du JDK qui interagit avec Java exactement de la même manière comme avec Xtends »

Contraint par la nature statique de Java, Xtends revendique tout de même une inférence de type de surface (pour gommer certaines redondances notamment sur les déclarations) et il allège le code de certains mots clés rébarbatifs en les considérant par défaut.
Notons aussi l'introduction des closures, d'accesseurs et mutateurs raccourcis, des points-virgules et des parenthèses optionnels...

[ame="http://vimeo.com/31248257"]Présentation du langage[/ame]




:fleche: Téléchargement et plus d'informations sur le site du langage

Et vous ?

:fleche: Que pensez-vous de Xtends ?
:fleche: Comptez-vous l'utiliser ?

Le code final de la présentation est très peu intuitif je trouve, on perd terriblement en clarté et je pense en vitesse de développement.

J'aime vraiment pas le principe.

Encore un Nieme langage pour remplacer Java.
Un nouveau langage qui n'apporte finalement que bien peu.

Aucun intérêt, surtout si la chaine de compilation dépend d'Eclipse. :aie:

Salut,


Je viens de jeter un coup d'oeil à la doc : http://www.eclipse.org/Xtext/xtend/#

Il y a peut-être quelques idées sympa (final implicite, les String-multilignes, pas de checked-exception, closures, ...) mais il y a aussi beaucoup de choix très discutable :

• L'amélioration du Type inference n'apporte pas grand chose. Je préfère de loin préciser un type que de ne rien mettre ou utiliser un nouveau mot-clef comme val ou def qui ne sont pas intuitif du tout :(
  
  
• La simulation des property n'est pas terrible non plus : person.name équivalent à person.getName() !
  Comment je sais si j'accède directement à l'attribut ou pas ??? Le principe est bien, mais une autre syntaxe aurait été préférable !
  
• Les parenthèses sont optionnels si la méthode ne prend pas de paramètre (youpi je gagne 2 caractères !!)
  Non seulement c'est totalement inutile mais cela fait perdre en lisibilité !
  
• Les Closures c'est très bien mais ils adoptent une syntaxe très différente de celle de Java 8 :(
  
• Le switch sur Object ? Sympathique mais une simple Map peut faire l'affaire en mieux (grâce aux hashCode).
  Surtout que contrairement aux int/enum/String il est impossible d'optimiser cela à la compilation...
  
• Les Extension methods je ne suis pas trop pour. Ca cache l'appel réel et cela peut générer des surprises.
  
• Les checked-exceptions remontées implicitement dans une runtime-exception... C'est le meilleur moyen de les louper :(

Bref pas vraiment convaincus :(


a++

Je suis pas convaincu.
Y'a des trucs affreux, genre le return implicite, à quoi çà sert / qu'est ce que çà fait gagner, éviter de taper le mot "return" ?
J'aime vraiment l'écosytsème Java mais certains langages dérivés sont quand même assez discutables (même groovy je suis agacé / déçu de certains changements du langage par rapport à du java qui n'apportent rien ou pas grand chose)

pour moi ça ressemble à un affreux mixe de la syntaxe java avec celle de ruby

En gros c'est scala en moins bien. A tous les dev java sceptiques, essayer Scala c'est l'adopter.

Il faut un peu de temps pour passer du paradigme impératif à fonctionnel mais au final on écrit beaucoup moins de lignes de codes, et on rajoute pas mal de fonctionnalités (trait, closure, actors, etc.)

On peut au moins saluer l'effort. :ccool:
dommage qu'ils ne sortent pas un fork de jvm avec.

Citation:

---

Envoyé par gilwath

pour moi ça ressemble à un affreux mixe de la syntaxe java avec celle de ruby

---

Pour moi ça ressemble à du Groovy.

Je vais l'essayer, ça me semble beaucoup plus intéressant que Groovy, Scala, et autres langages.

Les amis, faut pas le prendre comme étant un langage dédié a remplacer java ou bien a être un langage de programmation "classique".

En fait xtend est couplé avec xtext, ce dernier est un langage de programmation de DSL (Domain specific langage).

L'un des buts principaux de xtend est la génération de code, a base d un DSL.

J ai travaille avec xtext est xtend pour la génération de code d'architecture 3tiers JEE. C est un outil super et tres innovant, qui n a rien a avoir avec les outils classiques de MDA (Style Andro MDA).

Je vous encourage vivement a l essayer.

L'idéal ce serait un truc pleinement configurable, genre qu'on puisse choisir de supprimer les accolades et de les remplacer par des indentations, etc. Et qu'on puisse bien sûr aussi remettre tout en Java pur, et que les sources soient automatiquement corrigées...

ça revient à l'usage dont tu en fais.

Si tu utilises xtend en tant que langage de programmation proprement dit, tu vas pas sentir l'apport de l'outil.

Si tu l'utilises en conjonction avec xtext, tu vas t'apercevoir des facilités énormes que xtend propose (et que xtext le fait aussi).

la vocation de DSL est justement de créer des langages, qui peuvent être fonctionnels ou techniques.

les plugings eclipse du framework te permettent de bénéficier de trucs genre : la coloration syntaxique, l'auto-complete, et la validation (sorte de compilation de ton langage).

avec xtend, tu as la possibilité, entre autres, de traduire ton langage en un langage de programmation (style ce que fait les MDA), et là c toi qui spécifie les règles du jeu (c à d tu controle à 100%) la manière de générer le code.

De mon coté j'ai eu des difficultés à bien assimiler la façon de faire des deux outils, mais en faisant de l'effort au niveau de la documentation j'ai découvert tout un autre monde.

Citation:

---

Envoyé par BenWillard

L'idéal ce serait un truc pleinement configurable, genre qu'on puisse choisir de supprimer les accolades et de les remplacer par des indentations, etc. Et qu'on puisse bien sûr aussi remettre tout en Java pur, et que les sources soient automatiquement corrigées...

---

Que chacun code à sa sauce ? Même si les sources seraient identiques au final, j'imagine le bordel à communiquer entre développeurs. La customisation à outrance, je n'en vois pas l'intérêt. Il faut tout de même une certaine structure commune.

@santana2006 : Hum, mais c'est pas ce qui est dit dans l'article ni dans la page de présentation.
Tu aurais un lien, qui expliquerait comment voir Xtend de cette façon ? Ou bien tu es juste en train de nous vendre qu'on peut prendre Xtend et le modifier comme on veut avec xtext ?

Ce n'est pas en rendant Java moins explicite et moins rigoureux qu'on va l'améliorer.

Au vu des codes abominables que j'ai dû maintenir, l'inférence de type en particulier est une horreur. On tape def au lieu de int, autant de lettres, sauf que maintenant il faut aller lire chaque instruction return pour savoir quel est le type de retour de la méthode. Attendez non, il n'y a plus de return. En fait on ne sait même plus si la méthode retourne quelque chose sans la lire entièrement. Résultat : on ne peut plus utiliser une classe en lisant uniquement les prototypes de ses méthodes, il faut la lire entièrement.

Ce n'est qu'un exemple et il y a bien d'autres chose à dire sur Xtend, y compris des choses bien, mais mon commentaire concerne davantage l'évolution de Java et ses dérivés en général.

Essentiellement, le coté bavard de Java est une qualité : il contraint les développeurs à exprimer clairement leur pensée. Toute tentative d'en simplifier l'écriture a 90% de chance d'être une régression.

Quand je dois corriger un code, je passe davantage de temps à comprendre ce qu'il est censé faire qu'à comprendre pourquoi il ne le fait pas. En fait, quand j'ai compris quelle était l'intention de l'auteur, le bogue apparaît généralement immédiatement. Les deux secondes gagnées lors de l'écriture du code ne justifient pas les deux semaines perdues lors de sa correction.

Heureusement, la plupart des DSI l'ignorent, c'est ce qui permet aux prestataires de service comme moi de faire leur beurre. Peut-être que je devrais encourager l'usage de Xtend...

Citation:

---

La customisation à outrance, je n'en vois pas l'intérêt. Il faut tout de même une certaine structure commune.

---

La structure commune serait Java, mais je pourrais adapter à fond l'éditeur à mes besoins et à ma manière de faire.

Pouvoir taper "MonObjet objet = new(param);" (quand le constructeur appelé est celui de la même classe), par exemple, ne rendrait pas Java moins rigoureux...

Un peu comme le "sysout" suivi de <Ctrl><Space>, etc. Personne n'a besoin de savoir si j'ai tapé ça ou "System.out.println", et après tout ça pourrait aussi bien rester orthographié "sysout" dans mon éditeur...

@thelevin rassure toi, Je suis expert/architecte en technologies java, et je parle bien par connaissance de cause ;)

Je suis actuellement entrain justement d'écrire un moteur de génération de code (à base de XTend) à partir de DSL rédigée à l'aide de XText

Tu peux trouver des réponses à tes questions dans la documentation de XText : http://www.eclipse.org/Xtext/documentation/. Il y a des tutoriels rapide pour commencer, ainsi que la documentation de référence.

Voici également de la doc sur XTend : http://www.eclipse.org/Xtext/documen...troduction.php

Citation:

---

Envoyé par BenWillard

La structure commune serait Java, mais je pourrais adapter à fond l'éditeur à mes besoins et à ma manière de faire.

Un peu comme le "sysout" suivi de <Ctrl><Space>, etc. Personne n'a besoin de savoir si j'ai tapé ça ou "System.out.println", et après tout ça pourrait aussi bien rester orthographié "sysout" dans mon éditeur...

---

Oui oui j'ai bien compris mais j'imagine bien l'équipe projet après. Voici un exemple un tout petit peu exagéré :P :

<Débutant>Ça compile pas !
<Expert technique>Attends je vais voir sur ton poste comment tu as fais pour voir s'il y a une erreur
<Débutant>Ok
<Expert technique>Ah mais attend t'as pas la même custo. Java que moi
<Débutant>Bah euh peut être
<Expert technique>Bah je peux rien pour toi, je trouve ma conf. plus lisible, désolé.
<Débutant>:cry:

santana2006: Ah, j'avais pas lu ta réponse, mais ça m'a l'air sérieux, en effet. Ca peut faire ce que je dis, donc ? Générer du Java à partir d'une source bidouillée à ma sauce ? genre un mod qui vire les accolades ?

Robin56: bah, on ne passerait que par Java pur sucre, avec 2 modes pour l'éditeur, donc l'expert se pointe et passe en mode normal, et puis voilà. Et puis c'est pas parce que ce ne serait pas pratique pour tout le monde que ce n'est pratique pour personne :D comme tout le reste