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 ?

[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

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

[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

[adiGuba]

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

En fait il ne parlait pas de problèmes de typage, mais plutôt de l'ambiguité que cela peut avoir à la lecture du code, qui n'est plus autosuffisant :

Code :

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

1
2
// Quel est le type exact de "list" ???
value list = dao.create();

Mais on retrouve des cas similaire en Java...

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.

L'overloading complexifie la résolution de méthode, que ce soit à la compilation ou à l'exécution, et pose problème pour la gestion de paramètres optionnels.
Bref ce n'est pas un mal de s'en passer (bien au contraire).


a++