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

Le , par _skip

23PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de vintz72
Membre actif https://www.developpez.com
Le 14/04/2011 à 13:37
C'est bon, mais Ceylon.

Désolé...
6  1 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 15/04/2011 à 11:01
Citation Envoyé par air-dex Voir le message
C'est d'ailleurs bizarre qu'il ne parle pas du typage fort ou faible. Beaucoup se plaignent du typage fort de Java, non ?

[*]En Java, le typage fort est mal considéré...


Je soupçonne certains de ces gars qui reprochent à un langage d'être fortement typé de ne jamais avoir bossé en équipe sur de très grosses bases de code. Par ailleurs, les gains d'un typage fort et statique en terme de sécurité du code et d'outils IDE (complétion, refactoring) outrepassent largement cette pseudo flexibilité qui sert à se prendre des autogoals.

Désolé de ne pas être plus ouvert. Autant je comprend que pour des scripts vite faits d'import/export de données one-shot c'est agréable de pouvoir jouer sur l'ambiguïté du type des variables, autant pour des grosses choses durables j'estime que ce n'est qu'un filet de sécurité en moins et des chances supplémentaires d'avoir des codes faux qui fonctionnent juste par bol en dév et qui pètent en production.

Enfin voilà, c'est que mon avis, mais moi ça me convient pas.
6  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
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++
5  0 
Avatar de jayfaze
Membre actif https://www.developpez.com
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 ....
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/04/2011 à 8:17
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, ...)

Citation Envoyé par air-dex Voir le message
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.
3  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
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
2  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 15/04/2011 à 11:11
Je ne suis pas d'accord avec toi adiguba. En surcharge, il m'arrive régulièrement d'avoir à écrire des méthode qui prennent plusieurs paramètres, chaque paramètre pouvant avoir deux types différents. Je me vois mal remplacer ceci

faitQuelqueChose(Model modele, Personne personne, Region region);
faitQuelqueChose(Model modele, String personne, String region)
faitQuelqueChose(Model modele, Personne personne, String region)
faitQuelqueChose(Model modele, String personne, Region region)

en
faitQuelqueChosePersonneRegion(Model modele, Personne personne, Region region);
faitQuelqueChoseStringString(Model modele, String personne, String region)
faitQuelqueChosePersonneString(Model modele, Personne personne, String region)
faitQuelqueChoseStringRegion(Model modele, String personne, Region region)

Ensuite, les valeur par défaut, c'est bien gentil, mais parfois, la valeur par défaut n'est pas immédiate et nécessite un calcul. Certe on pourrait mettre null, suivi d'un if et dedans calculer. Ce qui ne ferait qu'aboutir à des méthodes plus longue et donc plus difficiles à suivre.

Enfin, il arrive que des méthodes on le même nom car elles ont le même but et un résultat final similaire, mais elles doivent avoir un code différents car les paramètres supplémentaires influencent leur comportement et tout mettre dans une même méthode rendrait la maintenance compliquée et les performances problématiques.

Pour moi, avec une absence de surcharge, les pertes sont sèches. Le code sera pluq dur à lire, l'indépendances des méthodes surchargées n'est plus possible facilement.
2  0 
Avatar de _skip
Expert éminent https://www.developpez.com
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.
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 15/04/2011 à 10:34
Citation Envoyé par Uther Voir le message
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
    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
    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
    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
    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
    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
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++
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/04/2011 à 10:54
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.
1  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web