Xtends : la fondation Eclipse lance un nouveau langage compatible Java
Qui allège et enrichit les codes sources
Le 2011-11-08 16:36:19, par Idelways, Expert éminent sénior
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]
Téléchargement et plus d'informations sur le site du langage
Et vous ?
Que pensez-vous de Xtends ?
Comptez-vous l'utiliser ?
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]
Et vous ?
-
adiGubaExpert éminent séniorSalut,
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++le 08/11/2011 à 17:44 - 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
-
BugFactoryMembre chevronné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...le 09/11/2011 à 11:22 -
gilwathMembre confirmépour moi ça ressemble à un affreux mixe de la syntaxe java avec celle de rubyle 08/11/2011 à 21:05
-
Robin56ModérateurOui oui j'ai bien compris mais j'imagine bien l'équipe projet après. Voici un exemple un tout petit peu exagéré
:
<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>le 09/11/2011 à 11:35 -
Robin56ModérateurQue 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.le 09/11/2011 à 10:31
-
JoeChipMembre éclairé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 personnecomme tout le reste le 09/11/2011 à 11:36 -
adiGubaExpert éminent sénior@ratomms : sans parler des modifications "par erreur".
C'est à dire que tu modifies la valeur retournée et cela modifie implicitement le type déclaré de la méthode (au lieu de te générer une erreur en Java standard).
Attention le type-inférence n'est pas à jeter totalement, mais dans ces exemples-là il est particulièrement mal utilisé et potentiellement dangereux !
Il est surtout utile pour les closures/lambdas, où l'impact est bien moins important et le gain en lisibilité bien meilleurs...
a++le 09/11/2011 à 13:50 -
adiGubaExpert éminent sénior@santana2006 : on ne doute pas des qualités d'XText... juste des choix de syntaxe d'Xtends.
Et si j'ai bien compris XText sert plutôt à générer de nouveaux langages. C'est un autre besoin.
Xtends a plutôt pour objectif de remplacer Java, en "améliorant" sa syntaxe. Mais, selon mon opinion, les "améliorations" apporter serait plutôt des régressions.
La qualité d'un langage ne se fait pas uniquement selon sa verbosité
a++le 09/11/2011 à 14:41 -
adiGubaExpert éminent séniorJe n'ai pas dit que le type-inference n'est pas fiable. Ca marche très bien tant que tu l'utilises dans ton programme. Mais si tu développes une API public cela peut s'avérer trompeur !
La moindre modification de code peut modifier le type de retour d'une méthode, et dans le cas d'une API destiné à d'autre développeurs cela peut engendrer diverses incompatibilités !
Au niveau des closures/lambdas il n'y a pas de soucis à l'utiliser car la porté est faible. Au contraire même dans ce cas c'est même fortement utile.
Mais au niveau des méthodes c'est trop contraignant
La plupart des syntaxes de Xtends visent à gagner quelques caractères par-ci par-là, mais cela rend le tout moins strict... C'est dommage car à mon sens c'est une des grosses qualité de Java...
@santana2006 : Il n'est pas question de soucis de performance ou autres.
XTends est présenté comme un remplaçant de Java, alliant ses qualités et gommant ses défauts. Mais pour moi ce n'est pas le cas...
a++le 09/11/2011 à 16:32 -
thelvinModérateurPersonnellement je vois toujours pas pourquoi c'était pas juste Java + XText, mais bon...le 09/11/2011 à 18:55