Deux nouveaux langages qui commencent fort
Lors de ce Devoxx 2011, une catégorie de sessions était consacrée aux différents langages de la JVM.
Etaient présents Scala, Phantom, Groovy, JRuby, Clojure et les deux petits nouveaux révélés cette année par leur sponsor : Kotlin (JetBrains) et Ceylon (JBoss/Redhat)
Personnellement, ce sont ces deux nouveaux langages qui m’intéressaient le plus : j’adore la concision de Groovy mais le fait qu’il ne soit pas statiquement typée m’empêche de l’utiliser pour un projet avec un minimum d’envergure. Peut-être que l’un de ces deux langages pourra amener le meilleur de ces deux mondes…
Ces deux langages sont tout nouveaux et toujours en cours d’implémentation. Il n’est pas encore question de les utiliser sur de vrais projets mais nous avons pu voir durant les sessions de Devoxx que chacun avait déjà un compilateur fonctionnel et un IDE pouvant faire la démonstration de complétion, refactoring, debugging, … De quoi commencer à jouer avec a priori.
Caractéristiques
Ces deux langages ont une bonne partie de leurs objectifs en commun :
- langage s’exécutant sur la JVM
- statiquement typé
- compilateur permettant de détecter plus d’erreurs
- avoir une syntaxe plus simple et plus expressive que Java sans être aussi compliqué que Scala
- complètement interopérable avec Java
Il en ressort un grand nombre de caractéristiques communes, comme par exemple :
- inférence de type étendue
- null safety (cf ci-dessous)
- smart cast ou plus généralement des optimisations de syntaxe locale (cf ci-dessous)
- constructeur primaire dans la syntaxe
Par contre, durant la présentation de Ceylon la notion de closure n’a pas du tout été évoquée, il n’est pas clair pour moi si elle sera supporté ou non. Kotlin de son côté les supportera très bien, avec en particulier la possibilité de mettre en oeuvre des “higher-order function”.
Je ne peux pas faire de comparaisons précises sur la base de ces deux présentations, mais au dire de Stéphane Epardaud qui nous a présenté Ceylon avec Emmanuel Bernard : Ceylon et Kotlin ont beaucoup en commun en termes de fonctionnalités. Pour lui, Ceylon se distingue par un système de typage plus abouti ( avec en particulier les union type, intersection type, … ).
Syntaxe
Au niveau de la syntaxe, les deux langages restent assez accessibles aux programmeurs Java, mais s’éloignent tout de même de la syntaxe Java.
Pour citer deux exemples :
- dans Kotlin : le type des paramètres est écrit après son nom, et le type de retour après la définition d’une fonction. Par exemple :
fun main(args : List
- dans Ceylon : de nouveaux keywords sont introduits qui remplacent une partie de ceux utilisés en Java ( abstract => formal, @Overide => actual, public/protected remplacé par “shared”, …), du code peut être associé à des properties (pour implémenter le getter ou le setter associé), …
Documentation
Jetbrains a très rapidement mis en place un wiki pour son langage avec pas mal de documentation et des discussions sur les choix effectués et leurs objectifs : http://confluence.jetbrains.net/display/Kotlin/Welcome
Pour Ceylon, c’était plutôt le brouillard en terme de doc, la plupart des références se trouvaient dans des blogs, des présentations, … rendant difficile la création d’un communauté.
Jusqu’à ce matin en fait, où ils nous ont révélé une “One more thing” à la fin de la présention : le tout nouveau site de ceylon : http://www.ceylon-lang.org/ et le github des développements en cours https://github.com/ceylon
Un petit focus sur deux des caractéristiques communes
Null safety
Dans les deux langages : les références ne peuvent pas être null par défaut.
Un type Integer (par exemple) correspondrait à un objet entier non null.
Un type Integer? correspondrait à un objet entier pouvant être null
Pour accéder à un champ ou une méthode sur une référence pouvant être null, il faut absolument utiliser ?. au lieu de simplement . sans quoi le compilateur génère une erreur. Si l’objet est null : l’opérateur ?. aura pour effet d’ignorer la suite de l’expression et de renvoyer simplement null
Exemple en Kotlin :
Int? x = getAnIntegerOrNull() print (x?.times(2)) // ici, x peut être null : il est nécessaire d'utiliser ?. // pour appeler la méthode times qui correspond à l'opérateur * if(x!=null) { print(x * 2) // ici, le compilateur sait que x n'est pas null, // on peut utiliser x * 2 qui est équivalent à x.times(2) )
Exemple en Ceylon :
Cube? cube = getCubeOrNull() print cubs?.area() if(exists cube) { // permet de tester que la référence n'est pas null print cube.area() } else { print "Cube is null" }
Smart Cast
En Kotlin :
Object object = ... if(object is String) { object.substring(1) // pas besoin de caster l'objet en String, // le compilateur le déduit de la clause if }
En Ceylon :
Apple|Snail food = ... // union type : food référence un objet soit de type Apple soit de type Snail. if(is Apple food) { // on s'assure que food est de type Apple food.eat() // la méthode eat() n'existe que sur Apple, et pas sur Snail // dans le bloc du if, il n'est pas nécessaire de caster food en Apple pour l'appeler }
On peut aussi considérer les deux exemples du paragraphe “null safety” comme des smarts cast : où le compilateur change le type de la référence d’un type nullable à un type non nullable.
Conclusion
Plus simple que Scala, ces langages pourraient répondre aux attentes de ceux qui veulent un langage sur la JVM qui soit plus expressif que Java.
Mais attention, Groovy les attend au tournant : la vérification statique du typage est en cours d’implémentation pour la prochaine version du langage : http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking
Il permettrait d’indiquer au compilateur d’effectuer un contrôle de type strict sur certaines classes : tout compte fait c’est peut-être juste ça que j’attendais moi ! 😉
