Discussion :

[_skip]

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



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

[Paul TOTH]

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.

[vintz72]

C'est bon, mais Ceylon.

Désolé...

[thelvin]

Encore un ? Mais ils sont numéro combien, dans la liste des langages qui cherchent à faire exactement ça ? #3 ? #4 ?

[jayfaze]

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 ....

[adiGuba]

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 :

#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 :

#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++

[_skip]

#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.

#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.

[_skip]

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...

[adiGuba]

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

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...

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

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++

[tchize_]

Ce qu'il y a de biens avec les Ceylon, c'est que les versions prévues sont déjà numérotées

[Philippe Bastiani]

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 ?

[Philippe Bastiani]

Et vous ?

La syntaxe amenée par Ceylon ne m'enthousiaste guère...
La possible incompatibilité avec Java ne m'enthousiaste pas du tout...

Pourquoi un nouvel langage généraliste qui ne semble pas révolutionner la programmation ? N'y a-t'il pas, la place pour des DSL ? la persistance des objets en base de données ne pourrait-elle pas être le domaine d'un tel langage ?

[_skip]

Ce qu'il y a de biens avec les Ceylon, c'est que les versions prévues sont déjà numérotées

j'étais sûr que quelqu'un allait dire ça, moi aussi ça m'a fait le même coup au début.

La syntaxe amenée par Ceylon ne m'enthousiaste guère...
La possible incompatibilité avec Java ne m'enthousiaste pas du tout...

Pourquoi un nouvel langage généraliste qui ne semble pas révolutionner la programmation ?

Je trouve qu'il y a des idées qui sont valables. Perso un genre de C# amélioré sur JVM ça me dirait pas mal. Le truc c'est que l'intérêt de la JVM sans le JDK et donc sans tous les projets de librairies très variés qui sont basés dessus semble tout de même un peu moins évident, c'est indéniable.

Ou alors on peut espérer une couche "ciment" pas trop lourde permettant l'utilisation de code java sans trop de douleur.

[Philippe Bastiani]

Ou alors on peut espérer une couche "ciment" pas trop lourde permettant l'utilisation de code java sans trop de douleur.

Pour JavaFX, le bridge on l'attend encore un pont avec Java devrait être une exigence de base voire essentielle pour un langage qui repose sur la JVM !

[Godestiny]

Bel effort mais je ne pense pas qu'il remplacera java. Déjà pour les libs, java en aura assimilé beaucoup trop (en 15 ans d'existence) que Celion qui vient de voir le jour. Je ne voit pas trop l'utilité d'un langage pareil si ce n'est que de se prémunir contre une éventuelle "mauvaise action" sur le langage Java par Oracle. En même temps les gens disaient la même chose sur Java à ses débuts, comparé à C++. Et maintenant Java est bien plus utilisé que C++ alors qui sait pour celion?

[tchize_]

si ça a du succès, je m'y mettrais.... dans 15 ans :aie

[air-dex]

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.

C'est d'ailleurs bizarre qu'il ne parle pas du typage fort ou faible. Beaucoup se plaignent du typage fort de Java, non ?

Donc un langage qui n'aura que des qualités ?
C'est pas la premiere fois que j'entends ca ....

Toujours sur le typage fort ou faible :

• En Java, le typage fort est mal considéré.
• En JavaScript, le typage faible est mal considéré aussi.

Donc même en prenant parti pour l'un ou l'autre, ça n'ira pas quand même et ce sera un défaut.

Encore un ? Mais ils sont numéro combien, dans la liste des langages qui cherchent à faire exactement ça ? #3 ? #4 ?

+1. Un seul de ces langages suffirait (Groovy par exemple).

[Uther]

La présentation de ce langage ne m'a pas convaincu. il alterne les bonne idéees(contrôle des null, immutabilité par défaut, pas de primitifs, ...), les incompatibilités avec la syntaxe java qui n'apportent rien(propriétés, méthodes top niveau, changement de certains mots clés,...) et de vraies mauvaises idées (pas de surcharge, ...)

C'est d'ailleurs bizarre qu'il ne parle pas du typage fort ou faible. Beaucoup se plaignent du typage fort de Java, non ?

Au contraire, ils précisent bien que le typage statique est à leurs yeux un des plus gros avantage de Java.
Je suis tout a fait d'accord avec eux. Pour moi le typage dynamique devrait être réservé aux langages de script (et encore).

A part quelques débutants qui ne comprennent pas a quoi sert le typage, je n'ai jamais entendu personne se plaindre du typage statique de Java.

[adiGuba]

et de vraies mauvaises idées (pas de surcharge, ...)

Au niveau des constructeurs c'est une très mauvaise idée. J'ai du mal à comprendre ce que cela peut apporter si ce n'est des limitations inutiles...





Mais au niveau des méthodes c'est différent, puisque cela simplifie grandement la résolution des appels de méthode.

Actuellement on utilise la surcharge dans 3 principaux cas :

• Pour simuler les paramètres optionnels (chaque méthode rajoute un paramètre supplémentaire), comme par exemple avec String.indexOf() :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  public int indexOf(String str)
  public int indexOf(String str, int fromIndex)

• Pour accepter aussi bien les objets que les types primitifs (une méthode pour Object et une pour chaque type primitif), comme par exemple avec println() :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  public void println(boolean b)
  public void println(char c)
  public void println(int i)
  public void println(long l)
  public void println(float f)
  public void println(double d)
  public void println(Object obj)

• Pour accepter un certains nombres de types différents et bien précis, comme par exemple pour ImageIO.read() :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  public static BufferedImage read(File input)
  public static BufferedImage read(ImageInputStream stream)
  public static BufferedImage read(InputStream input)
  public static BufferedImage read(URL input)

En supprimant les types primitifs et la surcharge, on peut utiliser les paramètres optionnels pour couvrir les 2/3 des cas :

• On ne simules plus les paramètres optionnels puisqu'on peut les utiliser directement :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  public int indexOf(String str, int fromIndex=0)

  Et c'est plus propre au niveau de l'API (une seule méthode à définir et documenter). Et comme il n'y a pas de surcharge c'est bien plus facile à gérer et à faire évoluer...
  
  
• On peut se contenter d'une seule et unique méthode pour accepter tout :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  public void println(Object obj)

  En effet comme il n'y a plus de type primitif, plus besoin de les gérer à part
  

En fait il n'y a que le dernier cas qui ne soit plus possible directement (méthode de même nom mais avec paramètre différent). Mais dans ce cas là il est tout à fait correct de renommer les méthodes sans que ce ne soit choquant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static BufferedImage readFile(File input)
public static BufferedImage readImageStream(ImageInputStream stream)
public static BufferedImage readStream(InputStream input)
public static BufferedImage readURL(URL input)

a++

[Uther]

En effet je parlais de la surcharge en général.

L'absence de surcharge sur les méthodes est en effet surmontable, mais si on gère la surcharge pour les constructeurs, je ne vois pas pourquoi ne pas le faire sur les méthodes.