Riviera Dev : Ceylon

Stéphane Epardaud présente Ceylon, un nouveau langage porté par RedHat, qui tourne sur la JVM. Il travaille sur le projet en tant que salarié de JBoss Redhat depuis mi-2011. C’est la première vrai présentation du langage et des outils. Stéphane fait partie de l’équipe du Riviera JUG, c’est l’un des organisateurs principal de la conférence Riviera Dev. Il a aussi contribué sur des projets comme RESTeasy, des modules pour Play! et il est contributeur sur Ceylon depuis le 13 mai 2011. Il travaille sur le compilateur et ceylondoc.

Avant tout, je ne vais pas vous donner mon avis, mais simplement vous faire partager ce que j’ai vu. Ce qui suit est donc plus une simple retranscription de la présentation.

Ceylon est un langage inventé par Gavin King, salarié de Red Hat, qui a lancé Hibernate, Seam et CDI avec d’autres développeurs comme Emmanuel Bernard. C’est un langage sur la JVM. Il a pour but d’être facile à apprendre, moins verbeux et plus lisible que Java. Par exemple, quelques principes comme se débarrasser de tout ce qui est XML, promouvoir un style plus fonctionnel, supporter la méta-programmation, et la modularité.

class Rectangle() {
 Integer width = +0;

 Integer height = +0;

 Integer area() = {
  return width * height;
 }
}

Voyons cela avec un peu plus de Ceylon :

shared class Rectangle(Natural height) {
  shared Natural height = height

  shared Natural area() {
   return height;
  }

}

Notez tout d’abord que le constructeur est dans le corps de la classe, principe que l’on retrouve aussi sur les case class en Scala.
Les opérateurs de portée sont plus simples. shared est public, le défaut est scope-private. Pas de protected, package, private. Le type Natural est utilisé pour les entiers positifs. Les attributs sont par défaut immuables. En pratique, pareil que des propriétés Java Bean. Ceylon encourage aussi les objets immuables.

On peut faire des abstractions, avec attributs, méthodes et classes redéfinissantes. Il n’y aura pas de surcharge de méthodes en Celyon contrairement à Java. La surcharge de méthode est utilisée habituellement pour 2 raisons : gérer le cas des paramètres optionnels et gérer les différentes types. Prenez une méthode sum(int a, int b) et sum(float a, float b) en Java, il faudra trouver un nom différent à chaque méthode en Ceylon. Avec les paramètres par défaut, il n’est pas nécessaire de prévoir de la surcharge de méthode. Si vous voulez utiliser une méthode différente par type de paramètre, vous pouvez aussi simplement utiliser des noms différents. Ce principe est aussi en perte de vitesse avec Scala, car il rend très compliqué l’utilisation des fonctions, qui sont des objets dans une classe comme n’importe quel type. Ce ne sera donc pas révolutionnaire si vous codez déjà en Scala (voir ce bon article sur StackOverflow).

Ceylon offre donc un support des valeurs par défaut pour les paramètres, ce qui évite de devoir déclarer plusieurs signatures de méthodes.

Ceylon proposera de l’héritage multiple, plus proche cependant d’un héritage de type mixin. Sans état, l’ordonnancement et la gestion des super-types est réalisable. Ceylon aura aussi de l’inférence de type.

Une idée intéressante aussi : par défaut il n’est pas possible d’affecter une valeur null sur un type. Si vous voulez qu’un type puisse contenir null, vous devez explicitement utiliser un point d’interrogation comme sur la photo ci-dessous. Ceylon me fait penser à l’Elvis operator en Groovy.

Voici quelques exemples de type en Ceylon :

Les listes et séquences :

Certains opérateurs sont polymorphes, mais on ne peut pas utiliser de symboles comme nom de méthodes, contrairement à Scala. C’est un point qui évitera peut-être d’avoir des APIs trop complexes, une critique que l’on entend parfois sur Scala.

La modularité est très importante dans Ceylon. Chaque unité de code fait partie d’un fichier. Chaque package fait partie d’un module. Les modules Ceylon se distribuent à la Maven.

Une autre idée intéressante est l’intersection de type (ou union de type) démontrée avec cet exemple :

Pour terminer, Stéphane nous laisse avec un dernier slide sur ce qui sera aussi présenté dans les mois qui viennent petit à petit :

Le compilateur ceylonc prend du code java et ceylon et génère des .class. Vous pouvez aussi créer une archive, des fichiers .car.
Stéphane nous a montré une belle démonstration du plugin Eclipse, codé en partie par David Festal de SERLI. Bien entendu d’autres outils sont prévus comme un générateur de documentation. Stéphane n’a pas parlé pour l’instant des APIs comme par exemple une API collections. Mais j’imagine que cela sera prévu aussi plus tard.

Enfin Stéphane montre en avant première mondiale le futur site et la documentation de Ceylon, qui devrait être prêt pour la mi-novembre au moment de Devoxx 2011. Y’a encore du travail mais la documentation est assez complète. Nous devrions avoir cela d’ici un mois ou deux.

Conclusion

En cette fin d’année 2011, Ceylon c’est déjà un compilateur bien avancé, une documentation, une spécification et bientôt quelques outils. J’ai compté 3 Français sur le projet : Stéphane Epardaud, Emmanuel Bernard de JBoss RedHat, et David Festal de SERLI, qui a travaillé sur le plugin Ceylon pour Eclipse. Gavin King est basé au Mexique pour l’instant, il se charge de la définition des bases du langage. Stéphane travaille sur les outils, l’équipe est constitué au total d’environ 10 personnes pour l’instant.

J’ai le sentiment que Ceylon est d’abord fait pour adresser la frustration et la complexité de Java. Ce qui est intéressant, c’est que le langage est d’abord markété par rapport à Java, alors qu’en voyant la présentation je n’ai cessé de le comparer à Scala. J’ai forcément du mal à me projeter et à imaginer un développeur Java entrain d’apprendre Ceylon, alors qu’il s’intéresse déjà mollement à Scala.

Je trouve que Scala continue à être présenté comme un langage universitaire par les personnes qui en parlent lors des conférences. Ceylon parle tout de suite au développeur en entreprise avec une approche plus pragmatique. Scala vient de l’enseignement, Ceylon est porté par un éditeur présent dans notre industrie depuis quelques années. Il y a forcément une approche différente.

Ce n’est pas une petite montagne mais une véritable chaîne montagneuse qui attend les développeurs de Ceylon. Lorsque le compilateur sera stabilisé, il faudra attaquer l’écriture de différentes API comme les collections ou la gestion du réseau. Il faudra ensuite prévoir des frameworks pour faciliter la vie des développeurs, aider à l’écriture des tests, permettre d’écrire une application web. Enfin nous pourrons imaginer des logiciels d’entreprise pour proposer des services avancés comme du Cloud ou du Grid Computing. Mais pouvons-nous attendre autant ? Est-ce que ce créneau n’est pas déjà pris par Java, qui monopolise le monde de l’entreprise ? Par ailleurs, lorsque l’on voit Scala, les livres, l’écosystème, le support de la société TypeSafe et les différents frameworks déjà disponibles, est-ce que finalement Scala n’est pas le pire concurrent de Ceylon et Kotlin ?

Mon oeil de geek est intéressé par l’effort et le travail. Mon oeil de développeur d’entreprise est forcément plus réservé sur les chances de réussite. Il faut se concentrer non pas sur ce que propose le langage, mais sur les raisons de son existence. Si le débat tourne autour du choix de l’héritage multiple ou non, cela n’est pas intéressant. Le langage doit pouvoir répondre à la question « Pourquoi » avec par exemple 2 ou 3 phrases chocs. Java ne s’est pas vendu sur ses caractéristiques en tant que langage, mais sur les problèmes qu’il adressait : multi-plateforme, pensé pour le développement web, fonctionne pour le monde du mobile et de l’embarqué, évite de gérer les problèmes d’allocation mémoire, facile à enseigner. Bref si Java est un langage, c’est aussi une plateforme, une machine virtuelle, une communauté, un bon paquet de livres… Quelque chose qu’aucuns langages ne pourra remplacer.

Ceylon, ton ennemi c’est Scala. Ce n’est pas Java.

English version:
At the end of 2011, Ceylon already has a good compiler, some documentation, a specification and some tools such as the Eclipse plugin. I counted three French developers on this project: Stéphane Epardaud, Emmanuel Bernard of JBoss RedHat, and David Festal of SERLI, who worked on the Ceylon plugin for Eclipse. Gavin King is based in Mexico for now, he is responsible for defining the bases of language. Steph has worked on the tools, the team consists of a total of about 10 people for now.

I had the feeling during the presentation that Ceylon is first made to address the frustration and the complexity of Java. What is interesting is that the language is first marketed as a better solution than Java, but while I was watching this presentation I could not stop to compare Ceylon with Scala. I also thought that it won’t be that easy for a lazy Java developer, that has no clue about Scala and does not want to move his ass, to learn Ceylon. However, my general feeling is that it was interesting and still worth to look at it, cause it’s well designed.

For those who regularly attend a conference, and have the opportunity to see a Scala presentation, it’s somehow still presented with a lot of « universitary keywords », as if it was an obscure language that no Java developer could learn. Ok, this is a bit strong. But you see what I mean, if you had a Scala presentation recently. Ceylon on the other side speaks clearly to the Java developer in a company, with a more pragmatic approach. And this is good. Scala’s roots are in the Universitary, whereas Ceylon is proposed to the community by a software editor, RedHat. This is, I’m sure, something that will have an impact on how Ceylon is presented to the community. More pragmatic. Less « monad-type inference-functional-kick my ass » and more « this is how it works ».

This is not a small mountain but a real Everest that awaits Ceylon’s developers. When the compiler will be ready, they will have to start to write some nice API’s such as Collections or network management. They will have to provide some frameworks to ease developers’s life such as testing framework, web application framework or [your_favorite_use_case]-framework. Maybe, with the help of JBoss RedHat, some application software, but I doubt so.
But can we wait 1 or 2 years to wait for a stable and nice API ? To build frameworks, you need a community. Something you cannot buy. You need a lot of passionated developers. Maybe also you need good books, a lot of presentation in various conferences… Something we already have with Scala. Maybe Scala (and not Java) is the most serious competitor for Ceylon and Kotlin all in all…

Me as a geek, is interested by the effort and the work, by the clever ideas that Gavin King had in the language. On the other side, me as an enterprise developer is more skeptical about the Ceylon’s chances to succeed. To succeed, a language and the associated marketing materials have to focus not on the « What » but on the « Why ». When you present a new language, it’s really easy to explain « WHAT » it does, it’s harder to explain « WHY ». I think you need 3 or 4 « WHY » to succeed.

Java for instance is easy to explain : it’s a language that solves the multi-platform issue with a write once/run everywhere solution. It has been designed for the web development with a network api. It also removed from the developers’s hands the memory management issue, with a Garbage Collector. So it provides more solutions and less problems.

Ceylon, maybe Scala is your enemy, but not Java.

Articles similaires:

Conférence Riviera DEV à Sophia-Antipolis Riviera DEV en direct Riviera Dev, Introduction à Apache Hadoop Riviera DEV, DevOps par Henri Gomez