Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Responsable Java

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    13 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 13 275
    Points : 64 331
    Points
    64 331

    Par défaut Tutoriel sur une introduction à Ceylon, un Java moderne et sans legacy

    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
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de cours : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : keulkeul.blogspot.com
    LinkedIn : https://www.linkedin.com/in/mickaelbaron

  2. #2
    Membre expérimenté
    Homme Profil pro
    Informaticien
    Inscrit en
    septembre 2002
    Messages
    1 980
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Informaticien
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2002
    Messages : 1 980
    Points : 1 482
    Points
    1 482

    Par défaut

    Citation Envoyé par Mickael Baron Voir le message
    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+
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  3. #3
    Responsable Java

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    13 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 13 275
    Points : 64 331
    Points
    64 331

    Par défaut

    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
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de cours : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : keulkeul.blogspot.com
    LinkedIn : https://www.linkedin.com/in/mickaelbaron

  4. #4
    Membre expérimenté
    Homme Profil pro
    Informaticien
    Inscrit en
    septembre 2002
    Messages
    1 980
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Informaticien
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2002
    Messages : 1 980
    Points : 1 482
    Points
    1 482

    Par défaut

    Citation Envoyé par Mickael Baron Voir le message
    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+
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  5. #5
    Responsable Java

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    13 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 13 275
    Points : 64 331
    Points
    64 331

    Par défaut

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

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de cours : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : keulkeul.blogspot.com
    LinkedIn : https://www.linkedin.com/in/mickaelbaron

  6. #6
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 413
    Points
    7 413

    Par défaut

    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.

  7. #7
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 233
    Points : 3 178
    Points
    3 178
    Billets dans le blog
    12

    Par défaut

    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 ?
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  8. #8
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 809
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 809
    Points : 8 665
    Points
    8 665
    Billets dans le blog
    1

    Par défaut

    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
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 169
    Points
    2 169

    Par défaut

    Citation Envoyé par Mister Nono Voir le message
    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...

  10. #10
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 169
    Points
    2 169

    Par défaut

    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

  11. #11
    Rédacteur
    Avatar de eclesia
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    2 089
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 2 089
    Points : 3 087
    Points
    3 087

    Par défaut

    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
    Systèmes d'Informations Géographiques
    - Projets : Unlicense.science - Apache.SIS

    Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons

  12. #12
    Membre expérimenté
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    851
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 851
    Points : 1 303
    Points
    1 303

    Par défaut

    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.

  13. #13
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 413
    Points
    7 413

    Par défaut

    Citation Envoyé par BugFactory
    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.

  14. #14
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 922
    Points : 22 964
    Points
    22 964
    Billets dans le blog
    1

    Par défaut

    Salut,

    Citation Envoyé par _skip Voir le message
    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...

    Citation Envoyé par _skip Voir le message
    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++

  15. #15
    Membre expérimenté
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    851
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 851
    Points : 1 303
    Points
    1 303

    Par défaut

    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.

  16. #16
    Membre expérimenté
    Avatar de professeur shadoko
    Homme Profil pro
    consultant/formateur Java SE
    Inscrit en
    juillet 2006
    Messages
    1 099
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 70
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : consultant/formateur Java SE

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 099
    Points : 1 550
    Points
    1 550

    Par défaut

    Citation Envoyé par Mickael Baron Voir le message
    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.
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (un peu de pub pour mon site: http://scrountch.info/java )

  17. #17
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 922
    Points : 22 964
    Points
    22 964
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par BugFactory Voir le message
    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.


    Citation Envoyé par BugFactory Voir le message
    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++

  18. #18
    Membre expérimenté
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    851
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 851
    Points : 1 303
    Points
    1 303

    Par défaut

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

  19. #19
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 413
    Points
    7 413

    Par défaut

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

    Citation Envoyé par Gavin King
    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.

  20. #20
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 205
    Points
    7 205

    Par défaut

    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
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

Discussions similaires

  1. Réponses: 0
    Dernier message: 31/10/2014, 10h37
  2. Réponses: 0
    Dernier message: 09/01/2005, 13h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo