Ceylon : un nouveau langage pour la JVM
Par Red Hat, destiné à reprendre les points forts de Java sans ses défauts

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux


 Discussion forum

Sur le même sujet
Le , par _skip, Expert Confirmé Sénior
Lors d'une récente conférence à Beijing, Davin King de Red Hat, connu dans le monde Java comme étant l'auteur d'Hibernate et du framework Seam a annoncé qu'il travaillait sur un nouveau langage de programmation destiné à la JVM.

Ce langage, baptisé Ceylon, s'inspire fortement de Java. Selon les dires de son créateur, son objectif est d'en reprendre les points forts, tout en gommant certaines lourdeurs dues entre autres à son âge avancé (environ 15 ans). Il avoue par ailleurs s'inspirer notamment de certains éléments de C# et de Scala.

Parmi les points clefs de Ceylon, il est question de :

  • Typage statique
  • Support des closures
  • Pseudo-surcharge d'opérateur (mappage vers des fonctions)
  • Sucre syntaxique pour les propriétés
  • Support d'une forme de covariance pour les listes génériques
  • Gestion du NULL comparable à celle des Nullable value type de C# (Optional<String>))
  • Sucre syntaxique divers pour les collections, initialiseurs etc...


Et bien plus encore.

Il faut noter qu'à ce jour, aucun compilateur Ceylon n'est disponible, mais King estime que sa réalisation sera relativement « rapide » en raison de la forte ré-utilisation du code « Javac ».

Les documents PDF suivants offrent plus de détails sur les différentes idées et syntaxes prévues.

Introduction au langage Ceylon
Système de typage de Ceylon

Et vous ?

Donneriez-vous une chance à un tel langage ?
Pensez-vous qu'après l'annonce de Java 7 et 8, puis l'existence de Scala, Groovy, JRuby ou encore Jython, ce projet ait encore un avenir ?

Source : Blog de Davin King


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Paul TOTH Paul TOTH
http://www.developpez.com
Expert Confirmé Sénior
le 14/04/2011 6:51
l'effort est louable, mais je ne pense pas que ce langage apporte suffisamment de nouveauté (de fait il ne fait que récupérer des idées à droite et à gauche) pour percer.
Avatar de vintz72 vintz72
http://www.developpez.com
Membre confirmé
le 14/04/2011 13:37
C'est bon, mais Ceylon.

Désolé...
Avatar de thelvin thelvin
http://www.developpez.com
Modérateur
le 14/04/2011 13:53
Encore un ? Mais ils sont numéro combien, dans la liste des langages qui cherchent à faire exactement ça ? #3 ? #4 ?
Avatar de jayfaze jayfaze
http://www.developpez.com
Membre confirmé
le 14/04/2011 14:22
destiné à reprendre les points forts de Java sans ses défauts

Donc un langage qui n'aura que des qualités ?
C'est pas la premiere fois que j'entends ca ....
Avatar de adiGuba adiGuba
http://www.developpez.com
Expert Confirmé Sénior
le 14/04/2011 14:34
Salut,

J'ai jeté un coup d'oeil rapide au document et donné mes premières impressions sur mon compte twitter, que je copie-colle ci dessous :
Citation Envoyé par adiGuba sut twitter
#ceylon : plus de méthode static mais des méthodes "toplevel". Beurk
#ceylon : Aucune surcharge = des paramètres optionnels efficace. Mais en même temps c'est parfois bien pratique la surcharge...
#ceylon : Pas de checked-exceptions (yes !) mais des "type optional" pour éviter les NPE. A voir à l'usage si c'est pas trop lourd...
#ceylon : Attributs et variables locales sont des références immuables par défaut ! Très bon point
#ceylon : Visibilité "shared" ou "block local" seulement. C'est un peu trop simpliste à mon gout...
#ceylon : heu... c'est moi ou les getters/setters sont aussi lourd qu'en Java !?!
#ceylon : Pas de "new"... c'est moche je trouve
#ceylon : deux syntaxes d'affectations ( = ou := ) selon que le référence soient immuable ou pas ! Mais pourquoi ???
#ceylon : Un seul constructeur, avec le code directement dans le bloc de la classe... C'est pas très joli tout ca
#ceylon : Un type Sequence (collection immuable) avec une syntaxe intégré au langage. Pourquoi pas...
#ceylon : Des références de méthode ! Cool mais le syntaxe n'est pas très jolie
#ceylon : Je n'ai pas trop compris l'intérêt des méthodes à multiples listes de paramètres...
#ceylon : Et vlan toutes les méthodes ont des paramètres nommées... avec toutes les contraintes que cela impose

En résumé en ce qui me concerne :
Citation Envoyé par adiGuba sut twitter
#ceylon : de bonne intentions mais je ne suis pas vraiment convaincu pour l’instant. En tout cas pas en tant que "Java-Killer" !


Tout ceci s'éloigne un peu trop du langage Java pour "pas grand chose" au final IMHO.

a++
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 14/04/2011 15:15
Citation Envoyé par adiGuba  Voir le message
#ceylon : Pas de checked-exceptions (yes !) mais des "type optional" pour éviter les NPE. A voir à l'usage si c'est pas trop lourd...

Pour ma part, j'admet que les checked exception peuvent être gonflantes bien souvent, principalement quand on ne sait pas que faire d'une exception qui, on le sait à l'avance, n'arrivera jamais.
J'aurai préféré la possibilité de pouvoir simplement à l'aide d'une annotation, briser l'obligation de déclarer pour plus de souplesse.

Par contre, pouvoir différencier entre une instance nullable ou non d'une autre me paraît un bon point. Du moins pour éviter l'ambiguïté des méthodes pouvant retourner des NULL... Même chose lors du passage d'objet en argument, l'acceptation ou non d'un paramètre NULL saute aux yeux.

Citation Envoyé par adiGuba  Voir le message
#ceylon : Un seul constructeur, avec le code directement dans le bloc de la classe... C'est pas très joli tout ca

C'est un choix incompréhensible pour moi. grâce aux paramètres optionnels je peux vivre sans surcharge de méthode. Au pire si les arguments sont sans rapports je peux nommer ma méthode de façon légèrement différente:

Ainsi je pourrai avoir :
drawRectangleAtCoord(x1 , y1 , x2, y2);
drawRectangleAtPoints( Point a, Point b);

au lieu d'une méthode drawRectangle surchargée, en conservant toutes les fonctionnalités.

En revanche, si je devais me limiter à un seul constructeur utilisant soit des points, soit des entiers, ce serait plus gênant. Peut être pas dans mon exemple puisqu'il me suffirait de construire des points, mais par contre si les arguments étaient de nature différentes :

new Parser(String text)
new Parser(File file)
new Parser(XmlSource source)

ça commencerait à devenir délicat de se débrouiller avec un seul constructeur sans avoir recours à des bricolages ringards. A cela on me dira que la solution c'est plus d'héritage.
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 14/04/2011 15:37
Citation Envoyé par Paul TOTH  Voir le message
l'effort est louable, mais je ne pense pas que ce langage apporte suffisamment de nouveauté (de fait il ne fait que récupérer des idées à droite et à gauche) pour percer.

En tant que langage basé sur la JVM, il pourrait être une alternative séduisante pour ceux qui jugent Java un peu chiant sans vouloir tomber dans un Scala ou un Ruby-like.
Là ou c'est inquiétant, c'est cette phrase dans une interview (slashdot):

Because we're planning a whole new SDK, Ceylon doesn't make as many concessions in the type system to Java interoperability. In some cases, Java interoperability is going to suffer as a result of that. (Hopefully not too much!) For example, there's no overloading. There are no existential types. And there's no Java-style "null" hidden anywhere in the language specification. All these things would be useful for the interoperability scenario. But they're all otherwise quite harmful in terms of complexity. Oh and, generic type arguments are going to be reified! This opens up some very cool possibilities, but also slightly harms interoperability.

En gros, un nouveau SDK, ce qui signifie que Ceylon ne pourra peut être pas profiter du gigantesque écosystème de librairies disponibles pour java. Et souvent, à mon sens, le choix d'un langage n'est pas dicté par les simples préférences syntaxiques du développeur mais aussi par la présence de middleware et de briques réutilisables...
Avatar de adiGuba adiGuba
http://www.developpez.com
Expert Confirmé Sénior
le 14/04/2011 16:07
Citation Envoyé par _skip  Voir le message
J'aurai préféré la possibilité de pouvoir simplement à l'aide d'une annotation, briser l'obligation de déclarer pour plus de souplesse.

Ca revient a peu près au même : l'idée étant de pouvoir traiter ou pas une exception. Actuellement c'est possible avec les unchecked-exception mais ca reste impossible avec les checked

Citation Envoyé par _skip  Voir le message
Par contre, pouvoir différencier entre une instance nullable ou non d'une autre me paraît un bon point. Du moins pour éviter l'ambiguïté des méthodes pouvant retourner des NULL... Même chose lors du passage d'objet en argument, l'acceptation ou non d'un paramètre NULL saute aux yeux.

Oui tout à fait le gain est indéniable dans les signatures des méthodes.
Je crains juste que cela ne devient un peu trop contraignant à l'usage...

Les checked-exceptions semblait parfaite dans l'idée mais à mon sens cela aboutit trop souvent à des inepties. J'ai peur que ce soit le cas pour les types nullables.

Je n'ai pas assez de recul par rapport à cela...

Citation Envoyé par _skip  Voir le message
En revanche, si je devais me limiter à un seul constructeur utilisant soit des points, soit des entiers, ce serait plus gênant.

+1 je ne comprend pas trop pourquoi ils ont touchés aux constructeurs

Citation Envoyé par _skip  Voir le message
En gros, un nouveau SDK, ce qui signifie que Ceylon ne pourra peut être pas profiter du gigantesque écosystème de librairies disponibles pour java.

L'idée est louable car cela permet d'avoir une API plus propre, qui utiliserait toutes les nouveautés du langage. Déjà en Java il y a beaucoup de chose que l'on pourrait "nettoyer" (généraliser les enums à la places des constantes, etc.)

Mais en effet comme tu l'indiques cela pose en effet problème quand à l'écosystème.

Une étape primordiale passerait via la modularisation du JDK qui permettrait éventuellement de faire tourner plusieurs API en parallèle (si c'est possible).

a++
Avatar de tchize_ tchize_
http://www.developpez.com
Expert Confirmé Sénior
le 14/04/2011 17:10
Ce qu'il y a de biens avec les Ceylon, c'est que les versions prévues sont déjà numérotées
Avatar de Philippe Bastiani Philippe Bastiani
http://www.developpez.com
Membre Expert
le 14/04/2011 17:21
Donc en gros ils remettent en cause le passage de paramètres des constructeurs et methodes et, pourquoi pas en faire de même avec les variables... et, réinventer JavaScript

Au final, un code qui devient illisible avec l'impossibilité de documenter le passage de paramètre... Bref, du code impossible à maintenir...

Non franchement, quitte à revenir sur le passage des paramètres, ne serait-il pas plus juducieux de s'orienter vers une nouvelle syntaxe pour la programmation par contrat ?
Offres d'emploi IT
ARICHITECTE .NET/ SHAREPOINT
CDI
SQLI Entreprise - Ile de France - Saint-Denis (93210)
Parue le 21/11/2014
Intégrateur webdesigner
Alternance
IP-FORMATION - Rhône Alpes - Lyon (69000)
Parue le 18/11/2014
INGENIEUR COMMERCIAL CLOUD (H/F)
CDI
Hardis - Rhône Alpes - Grenoble (38000)
Parue le 11/11/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula