Perso, j’aime bien Xtend. Et au fond, c’est (rétrospectivement ;-) logique d’une communauté de développeurs spécialisées dans le tooling définisse un nouveau langage faisant usage d’inférence de type...
Ce que j’aime bien dans Xtend, c’est que j’arrive aisément à imaginer comment les nouvelles fonctionnalités seront compilées en Java et donc, j’arrive facilement à me faire une idée du cout de ces nouvelles fonctionnalités.
Et les autres langages ont aussi des défauts :
- Groovy est associé à des couts d’exécution « cachés » (cf. points plus hauts).
- etc.
Bref, Xtend me semble combler un manque, et améliorer effectivement Java (+/- certaines fonctionnalités dont je n’ai pas encore bien vu l’utilité, ou pu estimer le cout induit, comme les « Create Functions » que je cite ici de mémoire).
Ce serait bien que le JCP (qui gouverne l'évolution de Java) en prenne de la graine. Cela semble d’ailleurs un peu arriver, timidement, avec la JEP 101 http://openjdk.java.net/jeps/101 listée ici http://blog.joda.org/2011/11/future-is-in-jeps.html
Il est dit que les processeurs RISC sont arrivés sur le devant de la scène en conjonction avec la maturité des compilateurs permettant d’optimiser le code produit. Java existe depuis plus de 10 ans, et ceux qui écrivent des compilateurs ont progressé, et ont montré, par ex, que l’inférence de type avait sa place dans des langages d’importance, comme C# ou Scala. Bref, il serait temps IMHO que le monde Java se réveille pour suivre un dépoussiérage à la façon de Xtend.
PS : je ne vois pas trop l'intérêt de rendre les ";" optionnels. Cela complexifie la règle : il peut y avoir 2 cas (";" présent ou non) au lieu d'un seul (";" obligatoire). Bref, cela demande IMHO plus de travail au cerveau des développeurs et, donc, je ne vois pas cette évolution aller dans le bon sens.
[^] # Re: Où est le regard critique ?
Posté par ddevito (site web personnel) . En réponse à la dépêche Découvrir Xtend, un langage extension de Java. Évalué à 3.
Perso, j’aime bien Xtend. Et au fond, c’est (rétrospectivement ;-) logique d’une communauté de développeurs spécialisées dans le tooling définisse un nouveau langage faisant usage d’inférence de type...
Ce que j’aime bien dans Xtend, c’est que j’arrive aisément à imaginer comment les nouvelles fonctionnalités seront compilées en Java et donc, j’arrive facilement à me faire une idée du cout de ces nouvelles fonctionnalités.
En gros, je suis d’accord avec Stephen Colebourne http://blog.joda.org/2011/07/kotlin-and-search-for-better-java_9066.html :
- Scala est trop complexe pour devenir le prochain mainstream language qui va détrôner à coup sûr Java
- Kotlin est associé à des choix syntaxiques en rupture avec Java et pour lesquels on se demande quelle est la valeur ajoutée : http://blog.joda.org/2011/07/reversed-type-declarations_4524.html
- Ceylon est dans le vapoware space
Et les autres langages ont aussi des défauts :
- Groovy est associé à des couts d’exécution « cachés » (cf. points plus hauts).
- etc.
Bref, Xtend me semble combler un manque, et améliorer effectivement Java (+/- certaines fonctionnalités dont je n’ai pas encore bien vu l’utilité, ou pu estimer le cout induit, comme les « Create Functions » que je cite ici de mémoire).
Ce serait bien que le JCP (qui gouverne l'évolution de Java) en prenne de la graine. Cela semble d’ailleurs un peu arriver, timidement, avec la JEP 101 http://openjdk.java.net/jeps/101 listée ici http://blog.joda.org/2011/11/future-is-in-jeps.html
Il est dit que les processeurs RISC sont arrivés sur le devant de la scène en conjonction avec la maturité des compilateurs permettant d’optimiser le code produit. Java existe depuis plus de 10 ans, et ceux qui écrivent des compilateurs ont progressé, et ont montré, par ex, que l’inférence de type avait sa place dans des langages d’importance, comme C# ou Scala. Bref, il serait temps IMHO que le monde Java se réveille pour suivre un dépoussiérage à la façon de Xtend.
PS : je ne vois pas trop l'intérêt de rendre les ";" optionnels. Cela complexifie la règle : il peut y avoir 2 cas (";" présent ou non) au lieu d'un seul (";" obligatoire). Bref, cela demande IMHO plus de travail au cerveau des développeurs et, donc, je ne vois pas cette évolution aller dans le bon sens.