Discussion :

[Mickael Baron]

La société Arolla, cabinet de conseil en technologies de l'information vous propose un article sur une introduction à Ceylon, un Java moderne et sans legacy.


Pour lire le tutoriel, accéder à : http://arolla.developpez.com/tutorie.../introduction/


N'hésitez pas à mettre vos critiques et impressions par rapport à cet article dans ce forum.


L'équipe Java

[Mister Nono]

La société Arolla, cabinet de conseil en technologies de l'information vous propose un article sur une introduction à Ceylon, un Java moderne et sans legacy.


Pour lire le tutoriel, accéder à : http://arolla.developpez.com/tutorie.../introduction/


N'hésitez pas à mettre vos critiques et impressions par rapport à cet article dans ce forum.


L'équipe Java

Marre de nouveaux langages qui sont toujours mieux que les autres.

Résultat : des développements toujours plus morcelés et incompatibles entre eux, un coût de maintenance élevé, une conduite au changement sans cesse, des informaticiens qui doivent toujours apprendre de nouveaux langage (au lieu d'apprendre des principes) mais pas pour mieux travailler, des employeurs qui recherchent toujours des moutons à 5 pattes... et j'en passe.

A côté de cela pour faire avaler la pilule, on sort des normes à gogo pour essayer de fédérer cette pléthore d'outils logiciels hétérogènes à l'excès...

A+

[Mickael Baron]

Marre de nouveaux langages qui sont toujours mieux que les autres.

On peut penser que s'il y a de nouveaux langages c'est pour palier des insuffisances des anciens. Cela ne peut stimuler la compétition, non ?

Mickael

[Mister Nono]

On peut penser que s'il y a de nouveaux langages c'est pour palier des insuffisances des anciens. Cela ne peut stimuler la compétition, non ?

Mickael

Oui mais combien de langages tombent en désuétude au bon de quelques années ? Combien d'applications sont refaites car on ne peut plus les maintenir ?

A+

[Mickael Baron]

Les langages alternatifs Java que je connais sont encore bien vivants (Groovy, Scala, Ceylon...)

Mickael

[_skip]

Extrêmement intéressé pour ma part depuis plusieurs années.

On devrait avoir une version 1.1 de Ceylon qui devrait sortir sous peu. Comme je l'ai expliqué dans d'autres sujets, c'est l'un des rares langages récents qui me donnent l'impression d'avoir été pensé par des gens qui savent ce qu'est la maintenance de gros projets. Il échappe à cette tendance actuelle néfaste qui se caractérise par la recherche de la concision à n'importe quel prix. Dans Ceylon, l'accent est mis sur la lisibilité, lorsqu'on reprend du vieux code fait il y a plusieurs mois ou années par des équipes de niveaux inégaux, ça n'a pas de prix.

[Gugelhupf]

Avoir des alternatives a des avantages (les nouveaux concepts), comme des inconvénients (la maintenance).

Inspiré du C++, le "nouveau langage" Java ("nouveau" pour son époque en 1995) a révolutionné les langages interprétés par une VM, plus de pointeur car les objets sont gérés par un GC, mais après ?
Si le framework Spring n'avait pas existé, est-ce que l'injection de dépendance ferait parti du standard ?
Si les langages JavaScript, PHP (parmi les plus connus) n'avaient pas démocratisé les lambdas, est-ce qu'on les aurait aujourd'hui ?
Il y a tellement d'exemples comme ceux-là.

Java évolue lentement (amha c'est le marché et la transition Sun/Oracle qui veut cela), il aura fallu attendre Java 5 et Java 8 pour voir des évolutions au niveau de la syntaxe, mais Java n'a pas vraiment à envier aux autres langages aujourd'hui.

Le problème : Qu'est ce qu'on va faire de tous ces frameworks et langages une fois en avoir extrait les concepts ? qui va les maintenir ?

[OButterlin]

Un langage de plus... à voir ce qu'il deviendra

Personnellement, sans vouloir le juger (je ne connais pas), je m'en fiche un peu, c'est plus ce qu'il y a autour d'un langage qui m'intéresse que le langage proprement dit. De ce point de vue, Java est tout simplement exceptionnel...

J'ai appris pas mal de langage de programmation, cobol, rpg, c/c++, pascal objet, java (pour les principaux) et ça ne m'a jamais posé de problème, on apprend d'abord un vocabulaire, ensuite le langage va permettre de "penser" autrement (surtout vrai pour les langages objets)

S'il s'agit de créer un nouveau langage pour simplifier une façon de faire, bof, je suis moins intéressé, c'est assimilable à de la flemme...
S'il apporte réellement quelque chose de plus et s'il est largement adopté, alors oui, pourquoi pas...
Même si je n'ai toujours rien à reprocher à Java... surtout la v8

[Traroth2]

Combien d'applications sont refaites car on ne peut plus les maintenir ?

A+

Oui, mais ça, c'est rarement à cause du langage qui a servi à le développer...

[Traroth2]

Concernant Ceylon, j'ai commencé à écrire un article plutôt détaillé sur Wikipédia, si quelqu'un est intéressé pour l'approfondir :

https://fr.wikipedia.org/wiki/Ceylon

[eclesia]

Ceylon ressemble à ce que serait Java s'il était à nouveau écrit aujourd'hui.

ne pas proclamer ce genre de chose comme si c'etait une sacro-sainte vérité, laissez a l'auteur de Java le droit exclusive de faire pareil déclaration.

Je ne crois pas beaucoup a l'avenir de ceylon pour ma part, lorsque je l'ai essayé il y a 2 ans il ne m'a pas accroché plus que ca.
Bon il faut dire que je fais surtout des briques backend, donc pour moi la logique, le typage et l'algorithme doivent etre bien visible et trop de sucre syntaxiquement nuit a cette bonne visibilité.

Je fais du java depuis une bonne dizaine d'années, mais je ne vois que le Ruby et le D qui ont de l'interet parmis les 'nouveaux' languages.

Ceylon n'a pas vraiment de particularité marquante qui le démarque, c'est une salade de pattern/syntaxe des préférences de ceux qui l'ont concu au meme titre que groovy ou scala, comme s'il etait concu pour les besoins du moment, pour expérimenté de nouvelles possibilitées.

Enfin ce n'est que mon avis, mon vote pour ceylon reste : -1

[BugFactory]

Je partage l'avis des participants précédent sur le fait qu'il y a trop de nouveaux langages, mais ça a été assez répété et il est dommage qu'il n'y ait pas davantage de commentaires sur Ceylon lui-même dans ce thread.

En lisant le tutoriel, je vois deux choses qui me sautent aux yeux.

Code :

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

value rndValue = Math.random()

Je déteste. Si on vient par la suite modifier l'expression et qu'on renvoie un type de valeur différente, le compilateur ne se mettra pas à hurler au meurtre comme il le devrait. En règle générale, je fais une allergie totale aux langages qui permettent de déclarer une variable (ou quoi que ce soit) sans préciser son type. 12 + 34 = 1234, mais bien sûr.

Code :

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

1
2
3
4
5
String? name = process.arguments[0];
if (exists name) {
  String notNullable = name;
  print("hello " + notNullable);
}

J'adore. On voit très clairement quelles variables peuvent être null ou non. Permet d'éviter les NullPointerException, évite d'avoir à lire la doc / le code source d'une librairie pour savoir si la valeur de retour ou les paramètres peuvent être null. Le tout avec une syntaxe à la fois concise et lisible. D'autres langages interdisent les valeurs null, ce qui évite aussi les NullPointerException, mais complique l'écriture de valeurs vides.

Sans surprise, il y a du bon et du mauvais. Malheureusement, le mauvais l'emporte. "value" est beaucoup, beaucoup trop dangereux à mes yeux. Il ne peut pas être utilisé pour le type de retour / les paramètres d'une méthode, on évite donc la catastrophe... Mais l'alternative, c'est Java : il va falloir faire mieux pour le concurrencer.

Ce n'est bien sûr que mon opinion personnelle. Je remarque que beaucoup de ces langages qui veulent devenir le successeur permettent cette bouse abominable de déclarer une variable sans préciser son type. Ça peut être adapté pour un langage de script dont les codes ne sont pas destinés à faire plus d'une vingtaine de lignes, mais ça ne convient pas à un langage destiné à créer des applications complexes destinées à être maintenues des années.

[_skip]

Code :

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

1
2
3
4
5
String? name = process.arguments[0];
if (exists name) {
  String notNullable = name;
  print("hello " + notNullable);
}

J'adore. On voit très clairement quelles variables peuvent être null ou non. Permet d'éviter les NullPointerException, évite d'avoir à lire la doc / le code source d'une librairie pour savoir si la valeur de retour ou les paramètres peuvent être null. Le tout avec une syntaxe à la fois concise et lisible. D'autres langages interdisent les valeurs null, ce qui évite aussi les NullPointerException, mais complique l'écriture de valeurs vides.

Effectivement pour moi c'est *LE* gain par rapport à java. Ca rend effectivement les API très lisibles, surtout celles pour lesquelles on se pose la question de la nécessité d'un paramètre. Sans compter les fonctions à effet de bord pouvant retourner null.
Dans java8 ils ont introduit un type Optional<T> mais sans sucre syntaxique c'est assez bof. Je me vois pas écrire Optional<HashMap<String, List<Object>>>, bon en même temps les gros génériques sont souvent réservés aux collections d'objet, et qui diable retournerait NULL à la place d'une Collection vide?

Il y a aussi la distinction entre les valeurs et les variables, les premières étant non assignables (un peu comme si elles étaient déclarées "final" an java) qui sont des plus appréciables. Malheureusement les javaïstes ont peu l'habitude de marquer les références comme constantes, ça peut toujours éviter un autogoal.

Ce n'est bien sûr que mon opinion personnelle. Je remarque que beaucoup de ces langages qui veulent devenir le successeur permettent cette bouse abominable de déclarer une variable sans préciser son type. Ça peut être adapté pour un langage de script dont les codes ne sont pas destinés à faire plus d'une vingtaine de lignes, mais ça ne convient pas à un langage destiné à créer des applications complexes destinées à être maintenues des années.

Tu le sais peut être vu que ton message laisse supposer que tu as de la bouteille, mais je précise quand même que ça a beau être de l'inférence de type, ça reste du typage statique. A savoir que le type de retour n'est pas Wrapper<? extends Object> ou quelque chose de ce genre mais bien le vrai type retourné, et c'est checké à la compilation.

Du coup :

Code :

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

1
2
3
4
5
6
 
value person =  persons.findPersonByName("Jean", "Claude");
 
println( person.name); //compile
println( person * 10 ); //compile pas
println( person.perimetre); //compile pas

Du coup c'est loin d'être aussi casse-gueule qu'en PHP ou tu peux faire par inadvertance une opération totalement illégale avec une variable d'un mauvais type. Je suis obligé de bien me gratter la tête pour trouver un cas où ça pourrait avoir un effet de bord.
C'est justement un des postulats de ceylon que de vérifier statiquement un maximum de choses, justement pour les gros projets qui font plus que 20 lignes.

[adiGuba]

Salut,

Dans java8 ils ont introduit un type Optional<T> mais sans sucre syntaxique c'est assez bof.

Les types nullables sont très pratique en effet, mais difficile à mettre en place en Java.
Enfin disons plutôt qu'en Java tous les types sont déjà "nullables" (en gros le String de Java est égal au String? de Scala).
Il faudrait donc faire l'inverse et définir un type non-nullable...

Mais il faudrait surtout adapter toutes les APIs pour que ce soit utile...

Tu le sais peut être vu que ton message laisse supposer que tu as de la bouteille, mais je précise quand même que ça a beau être de l'inférence de type, ça reste du typage statique.

+@BugFactory : Tout à fait : "value" ne pose aucun problème ici. Enfin en tout cas je n'en vois aucun.

Il ne s'agit pas d'une variable de type dynamique ou autre (comme en PHP ou Javascript).
La variable est typée dès la compilation et toutes les vérifications de type seront effectués comme si tu avais précisé toi même le type.


Mais bon y'a rien d'extraordinaire non plus là dedans...


a++

[BugFactory]

J'ai bien vu que value demande juste au compilateur de déterminer lui-même le type, et qu'un

Code :

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

variable value rndValue = Math.random()

en Ceylon est en tout point identique à un

Code :

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

double rndValue = Math.random()

en Java. Ce qui me gène, c'est que si on change l'expression Math.random par autre chose, cela peut changer le type de rndValue sans que cela soit détecté.

Imaginons par exemple l'on veuille écrire un timestamp dans un fichier.
Ca donne le code (vous m'excuserez si mon Ceylon est bourré de fautes) :

Code :

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

1
2
3
4
5
6
7
8
 
void writeTimestamp(PrintWriter writer, Long? now) {
    if(exists now) {
        value timestamp = now;
        writer.print("timestamp : ");
        writer.print(timestamp);
    }
}

Maintenant imaginons que suite à un refactoring, now devienne une date. Le code précédent compile sans problème, mais le fichier généré est désormais erroné : an lieu d'un entier après timestamp, on a une date au format utilisé par toString() (ou son équivalent en Ceylon).

Voici le code équivalent en Java :

Code :

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

1
2
3
4
5
6
7
8
 
void writeTimestamp(PrintWriter writer, Long now) {
    if(now != null) {
        long timestamp = now;
        writer.print("timestamp : ");
        writer.print(timestamp);
    }
}

Changez le type de now en Date, et le compilateur trouvera très bizarre que vous essayez de l'affecter à timestamp, parce que timestamp est un long. On verra donc tout de suite qu'il faut écrire now.getTime().

Ce n'est que le premier exemple qui me passe par la tête, et pas forcément le meilleur. Est-ce que le Ceylon, comme la Java, utilise le + aussi bien pour l'addition que la concaténation de chaine? Si oui c'est un piège en puissance.

Il y a aussi le fait que je préfère que les débutants en programmation orientée objet soient obligés de réfléchir au type de chaque variable. C'est un mauvais service à rendre à un débutant que de le laisser croire que les variables value sont open bar.

C'est dommage, parce qu'il y a beaucoup de bonnes choses à dire sur Ceylon. La capacité à compiler en Javascript, l'exemple de le structure de données pour le HTML rendent Ceylon intéressant pour le web.

[professeur shadoko]

un Java moderne et sans legacy.

euh ça veut dire quoi "sans legacy" ? (j'ai beau être bilingue il y a des fois où je ne vois pas l'utilité d'emprunts qui n'ont pas un sens bien clair)
ceci dit : on voit des tas de langages fleurir avec un peu plus de sucre ici, un peu plus de sel là ... bon, on peut expérimenter....
mais, pour le moment, je ne vois pas grand chose avec des paradigmes forts qui nous changeraient fondamentalement nos pratiques.

[adiGuba]

Changez le type de now en Date, et le compilateur trouvera très bizarre que vous essayez de l'affecter à timestamp, parce que timestamp est un long. On verra donc tout de suite qu'il faut écrire now.getTime().

Le refactoring peut amener des soucis du même genre même sans cela !
Exemple en Java :

Code :

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

1
2
3
4
5
6
void writeTimestamp(PrintWriter writer, Long now) {
    if(now != null) {
        writer.print("timestamp : ");
        writer.print(now);
    }
}

changer le type du paramètre changera le résultat... mais le problème vient plus du refactoring plus que du langage.

Il y a aussi le fait que je préfère que les débutants en programmation orientée objet soient obligés de réfléchir au type de chaque variable. C'est un mauvais service à rendre à un débutant que de le laisser croire que les variables value sont open bar.

Oui là dessus je suis plutôt d'accord... mais c'est l'éternel problème de la verbosité VS concision.


Un langage verbeux est plus "chiant" à écrire, mais bien plus simple à lire.
Un langage concis peut être plus simple à écrire, mais peut demander plus de travail pour la relecture...


Mais utilisé avec parcimonie cela peut être pratique...


a++

[BugFactory]

[QUOTE=professeur shadoko;7990415]euh ça veut dire quoi "sans legacy" ?[QUOTE]
sans compatibilité ascendante avec du code préexistant. Il y a beaucoup de langages qui trainent des syntaxes compliquées pour rester compatible avec du code écrit à leurs débuts. Le C++ est la principale victime mais pas la seule. ("Legacy" signifie plutôt "héritage", mais la traduction littérale ne convient pas ici.)

[_skip]

Ok donc pour value, je pense aussi comme AdiGuba que c'est un risque qui peut exister en java. En cherchant un cas tordu, je tombais aussi sur l'utilisation de toString() sachant que la confusion n'est possible qu'avec les instances implémentant une interface commune (Object dans ce cas particulier). Par contre j'apprécie le gain de verbosité sur ces petites choses, tout comme le support des property.
Par ailleurs il n'existe pas de conversion implicite en "toString()" en ceylon, faut écrire "string(monObject)"

Pour parler d'une "feature" un peu plus controversée, c'est l'absence de visibilité protected. En gros c'est private ou public, y'a pas d'entre deux.

http://ceylon-lang.org/documentation...ected_modifier

Au sens qu'il n'y aurait pas de justification architecturale à "protected" la non-visibilité externe relative qu'il procure peut se contourner...

Anyway, from the point of view, "protected" totally fails to help
control dependencies. Sure, in another unit I might not be able to
write:

Code :

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

Test().protectedMethod();

But I can trivially just write:

Code :

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

1
2
3
4
5
6
7
 
class MyTest() extends Test() {
         shared void callProtectedMethod() {
             protectedMethod();
         }
     }
     MyTest().protectedMethod();

Thereby _completely_ subverting the supposed control that "protected" provides.

Basically "protected" is useless because it doesn't prevent another
"unit" from depending upon the protected declaration, and any client
can always work around it.

Pour parler en terme de Ceylon, c'est shared ou pas

Code :

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

1
2
3
4
5
class Point(x, y) {
 
    shared Float x;
    shared Float y;
}

En ce sens, tout ce qui n'est pas spécifié comme shared est invisible en dehors de la classe. C'est comme si tout était private sauf ce qu'on spécifie comme public explicitement.
Je suis pas forcément ravi de la disparition de protected mais je me dis que je peux vivre sans.

Ce qui peut sembler vraiment déroutant en revanche c'est l'absence d'overloading.

Bon au niveau des méthodes on s'en fout un peu à la limite parce que écrire

Code :

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

1
2
3
 
Image load(byte[] image)
Image load(File file)

ou :

Code :

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

1
2
3
 
Image loadFromMem(byte[] image)
Image loadFromFile(File file)

ne change pas grand chose. En revanche cette limitation s'applique également aux constructeurs de classe. En ce sens, y'a un seul constructeur possible pour une classe en Ceylon.
Les développeurs pensent qu'avec les varargs et les union type, on peut simuler quasiment tous les cas "valides".

Code :

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

1
2
class Person(String name, int age, String? lang) {
}

Je peux écrire

Code :

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

1
2
value p1 = Person("Jean", 35);
value p2 = Person("Jean", 35, "FR");

Ou encore

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Person(String|Identity info) {
 
    shared String name;
 
    switch (info)
    case (is String) {
        name = info;
    }
    case (is Identity ) {
        name = identity.name;
    }
}

Bon ça reste une limitation mais cela peut quand même pousser les gens à éviter les classes et les constructeurs qui savent trop en faire. Du style l'objet qui sait se charger tout seul depuis 15 sources et 50 formats etc...

PS: J'écris tous les exemples de code sans les vérifier, donc je peux me tromper.

[Logan Mauzaize]

Annoncer qu'il peut y avoir des problèmes dynamique de typage en Ceylon, c'est ne pas connaître le langage (et la micro-plateforme qui vient avec). Comme dit précédemment, "value" n'existe qu'à l'écriture du code et disparaît complètement en "pré-compilation" où l'inférence de type fonctionne selon deux principes :

1. Pour une référence (variable, valeur ou propriété), il s'agit du type de l'expression de la première assignation. Attention une expression peut être complexe, ainsi le type de "foobar" dans value foobar = foo then "maChaine" else 123; est "String|Integer".
2. Pour les fonctions, il s'agit de l'union des types des expression en retour.

L'inférence de type ne peut être utilsé que dans des éléments non publique (shared) garantissant ainsi qu'à la lecteur cela se limite à des unités de compilation bien maîtrisées.
Quand au refactorting, Ceylon s'en prémunie beaucoup en versionnant obligatoirement tous les modules (bibliothèques, jar, etc.).

"value" existe pour faciliter la relecture en évitant d'avoir une déclaration de type longue de trois km qui casse toute la lisibilité au code. Par ailleurs le système de type (moteur d'inférence inclus) est un véritable calculateur qui se simplifie souvent la tâche. Ainsi déclarer une intersection de deux types sans parents communs est traduit par le type Nothing. Qui sert également de type pour l'ensemble vide !
Commencer à jouer avec les unions, intersections et génériques, je peux vous promettre que "value" n'est pas vide de sens. Tant sémantiquement c'est simple à comprendre mais à écrire ca peut vite dévenir illisible.

Il n'y a certes pas de NPE en Ceylon mais il n'y a pas non plus de ClassCastException !

En ce qui concerne l'overloading, je pense que c'est surtout une question de faciliter d'accès au métamodèle. Par exemple pour accéder à une référence de méthode, il suffit d'utiliser le nom de la fonction sans parenthèse. Et côté utilisation comme indiqué il suffit de faire varier le nom des méthodes (ce qui ajouté plus de sémantique et de lisibilité aux APIs) et pour les constructeurs, les "builder pattern" continueront à s'appliquer mais on peut éventuellement définir des méthodes "statiques" (c-à-d des méthodes déclarées au niveau des packages.
Les propriétés du constructeur étant souvent à utiliser comme propriétés de la classe. Ce que je reproche par contre au niveau de la syntaxe des constructeurs c'est qu'il n'y a pas de blocs bien définis, tout le corps de la méthode sert de bloc au constructeur. C'est une syntaxe trop proche du JavaScript à mon goût.

On le met beaucoup en concurrence avec Java mais la JVM n'est pas son seul terrain de jeu. Il se transpile également en JavaScript !


Pour information, la version 1.1.0 est disponible ! Et beaucoup de nouveautés sont arrivées.

Concernant le côté legacy, c'est que l'équipe (et Gavin King en particullier) ne s'est donné aucune contrainte en termes de rétrocompatibilité. Quit à casser beaucoup de code 1.0 avec la 1.1. Même si de l'avis de Gavin King la mise en production à grande échelle de Ceylon n'aura surement pas lieu avant les versions >1.2