Découvrir Xtend, un langage extension de Java

Posté par  . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
17
7
nov.
2011
Java

Xtend est un langage sous licence Eclipse qui est compilé en Java, afin d’être exécuté sur la JVM. C’est un langage se basant sur Java, sa syntaxe, son système de type et son typage statique, tout en étendant ses capacités. Xtend ne vise pas à remplacer Java, mais à être utilisé dans des situations où son ancêtre ne brille pas.

Xtend facilite l’utilisation de Java en supprimant le « bruit » inutile, rendant le code plus facile à écrire et à lire :

  • l’inférence de type (sur les variables, les types de retour, les boucles for()) ;
  • l’accès aux propriétés d’un objet de la même manière que les champs ;
  • les points‐virgules optionnels ;
  • les parenthèses optionnelles lors d’appels de méthodes sans arguments ;
  • l’utilisation du return optionnel (la dernière expression étant la valeur de retour).

Xtend étend Java en lui apportant les closures, les méthodes d’extension, le multiple dispatch, la surcharge des opérateurs, un switch() bien plus puissant que celui provenant du C, les chaînes de caractères multi‐lignes et un système de templates permettant d’avoir une indentation correcte du template, mais aussi du texte généré.

Xtend est intéressant car il apporte à Java des capacités assez similaires aux dernières versions de C#, tout en allant au‐delà. Il dispose déjà d’une prise en charge avancée dans Eclipse : coloration syntaxique, aide au contenu, quelques ré‐usinages (refactoring), la navigation, etc.. Enfin, le fait qu’il soit compilé en Java et non en bytecode permet de l’utiliser avec Android et GWT, par exemple.

Aller plus loin

  • # Retour positif :) et puis Scala

    Posté par  . Évalué à 3.

    Pour avoir utilisé Xtend conjointement à Xtext (un outil d'aide à la création de DSL sur Eclipse, et par ailleurs utilisé pour faire Xtend lui-même), je peux dire que son utilisation est très agréable.

    Pas aussi agréable que Scala à mon goût, mais il se différencie de ce dernier par le fait qu'il génère du Java et non du bytecode, ce qui a ses avantages je pense.

    Les plugins Eclipse pour l'utiliser son pas mal du tout (j'imagine qu'ils ne sont pas au top de leur maturité, mais à mon avis c'est déjà pas mal).

  • # mouais

    Posté par  . Évalué à 2. Dernière modification le 07 novembre 2011 à 21:19.

    les point-virgules optionnels ;
    les parenthèses optionnelles lors d'appels de méthodes sans arguments ;

    2 méga features [:benou], ça me fait penser à un mec qui voulait franciser le C et
    qui avait défini des tonnes de macros genre

    #define SI if
#define afficher printf

    Pour l'inférence de type, ça peut-être une bonne chose :)

    • [^] # Re: mouais

      Posté par  (Mastodon) . Évalué à 6.

      A priori, je ne vois pas trop l'intérêt majeur de rendre les point-virgules optionnels. Est-ce problématique de s'astreindre à bien comprendre et séparer ce qui est codé, avec ces fameux point-virgules ? Leur disparition partielle est-elle vraiment une « killer feature » ?
      Peut-être y a-t-il une bonne raison de vouloir en être débarrassé, mais je n'arrive pas à la trouver. Quelqu'un peut m'expliquer ?

      NB : de même pour les parenthèses, ma première réaction a été de me dire que, visuellement, on ne distinguera plus certains appels de méthodes et les références à des attributs, ce qui ne me semblait pas une grande avancée. Quelqu'un peu développer et m'expliquer l'intérêt majeur (hormis le gain de temps pour aller mouler plus tôt) ?

      • [^] # Re: mouais

        Posté par  (site web personnel) . Évalué à 6.

        L'absence de parenthèses est justement un truc que je n'aime pas dans l'Ada : pas évident de savoir au premier coup d'oeil s'il s'agit d'une variable ou d'une fonction. Est-ce que son coût sera en O(1) ou est-ce qu'il faut se méfier ? Est-ce que je peux faire une affectation ?

        • [^] # Re: mouais

          Posté par  . Évalué à 1.

          Je trouve que dans des langages comme caml, on mesure bien l'inintérêt des parenthèses sur les fonctions.

          Dans caml, les parenthèse délimitent les expressions, et donc un appel de fonction à plusieurs arguments n'a pas besoin de ses parenthèses, sauf éventuellement à parenthèser l'expression entière, nom de la fonction incluse.

          En pratique, dans des langages comme Xtend ou Scala, la suppression de ces parenthèse permet parfois d'avoir un code lisible plus naturellement, mais ça dépend du contexte je trouve...

        • [^] # Re: mouais

          Posté par  . Évalué à -1.

          pas évident de savoir au premier coup d'oeil s'il s'agit d'une variable ou d'une fonction.

          Moui enfin coté IDE afficher un style différent pour distinguer les 2, ça ne me parait pas très compliqué.

          Est-ce que je peux faire une affectation ?

          Ça n'est pas forcément lié a la différence variable/fonction puisqu'il y a pas mal de langages qui ont du sucre syntaxique "x.foo = ..." remplacé par un appel de fonction "x.set_foo(...)"

      • [^] # Re: mouais

        Posté par  (site web personnel) . Évalué à 9.

        Peut-être y a-t-il une bonne raison de vouloir en être débarrassé, mais je n'arrive pas à la trouver.

        Tu poses la question à l'envers : y a-t-il une bonne raison de vouloir mettre obligatoirement des points-virgules à la fin des lignes ?

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: mouais

            Posté par  (site web personnel) . Évalué à 3.

            Deux réponses à mon avis :

            • les ; sont optionnels, pas supprimés. Donc ton ; tu peux toujours le mettre. Mais pas besoin lorsque ça ne sert à rien.

            • mais ce que c'est moche ton premier exemple. D'ailleurs on m'a toujours appris un truc : "quand un code ne fait rien, il est nécessaire de le dire"

            De la même manière, si on a un

            try {
  plop();
} catch(Exception e) {
}

            Ce n'est pas bon. Il doit toujours y avoir quelque chose dans le catch. Même si c'est juste pour dire "je me fiche de ce cas". L'absence est problématique car on perd totalement l'information permettant de savoir si le cas est volontairement laissé de côté ou non.

            Et pour revenir au premier cas, tu pourrais très bien écrire

            if (toto) {
} else if(tata) {
  plopTata();
} else if (titi) {
  plopTiti();
}

            Pas besoin de ; pour ça.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 1.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: mouais

                Posté par  (site web personnel) . Évalué à 1.

                Ou alors tu indente correctement ton code et ça donne quelque chose de lisible.

                Bien que je déteste le style de python - quelle horreur - j'ai toujours beaucoup apprécié l'information donnée par l'indentation, qui est bien plus visible qu'un ; par exemple

                sprintf(bufCommand, "%s%-5s%s - %s", bufCommand, capitalize(dir_name[door]),
    room_is_dark(pexit->u1.to_room) ? get_acolor_ch(ch, C_GRY) : get_color_ch(ch, NORMAL_COLOR),
    room_is_dark(pexit->u1.to_room) ? "Too dark to tell" : pexit->u1.to_room->name);

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 1.

                  Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: mouais

        Posté par  . Évalué à 0.

        C'est peut-être pas une "killer feature", mais c'est tout de même agréable.
        Vu le nombre de fois où j'ai eu des problèmes de compilation, juste parce que j'avais oublié de mettre un point virgule à la fin d'une ligne...
        Donc oui ça un intérêt. On peut prendre le problème à l'envers: pourquoi obliger à mettre un point virgule à la fin de chaque ligne, alors que ça ne sert à rien ?

        Pour les parenthèses, je ne peux pas me prononcer pour Xtend, mais avec Scala cela permet dans certaines situations de rendre le code nettement plus lisible.

        Exemple: au lieu de d = a.add(b.multiply(c)), tu peux écrire a add (b multiply c).
        Et comme Scala permet d'utiliser des opérateurs pour nommer une méthode(ce n'est pas de la surcharge d'opérateur!), tu te retrouves à faire: d = a + b * c.
        (À noter que la méthode * est bien prioritaire par rapport à '+' et que le résultat est bien celui auquel on s'attend).

      • [^] # Re: mouais

        Posté par  . Évalué à 2.

        À vue de pif, retirer les parenthèses et point-virgules et tout juste bon à casser la grammaire LALR(1), mais je peux me planter sur ce coup là. En tout cas, ça ne va pas servir à rendre le code plus lisible ; Mais bon, si ça peut faire plaisir aux amateurs de Perl qui sont obligés de faire du Java...

        Pour l'inférence de type et les retours implicites, faut voir comment c'est codé. À priori c'est résolu statiquement et pas à coup de java.lang.Object et checkcast dans tous les sens.

    • [^] # Re: mouais

      Posté par  . Évalué à 3.

      En ce qui me concerne, a chaque fois que j'ai un point virgule, j'ai une nouvelle ligne tout de suite après, alors pour moi les point virgules sont inutiles.

      Pour l'absence de parenthèses lors d'appels de méthodes sans arguments, on m'avait vendu que cela permettait de passer facilement d'un champ a une méthode et vice versa sans changer le code. A la réflexion, vu que l'on ne doit pas accéder aux champs de toute manière, je ne vois pas bien l’intérêt. Si quelqu'un peut me l'expliquer?

      • [^] # Re: mouais

        Posté par  . Évalué à 3.

        Pour l'absence de parenthèses lors d'appels de méthodes sans arguments, on m'avait vendu que cela permettait de passer facilement d'un champ a une méthode et vice versa sans changer le code. A la réflexion, vu que l'on ne doit pas accéder aux champs de toute manière, je ne vois pas bien l’intérêt. Si quelqu'un peut me l'expliquer?

        Alors, je vois plusieurs cas où ça peut aider.

        1. Tu accèdes à tes champs depuis une classe dérivée/amie/etc. (par exemple si tes champs/attributs sont déclarés protected¹).
        2. Il y a des fois où tu veux vraiment que l'attribut soit public (une constante, ou bêtement une classe qui sert plus de « structure » qu'autre chose)
        3. Pour aller un peu plus loin sur le point précédent: si au final, il y a « insertion en ligne » (inlining) des accesseurs, il est plus simple d'avoir un champ qui dit toto.a plutôt qu'avoir à coder un lourd toto.getA², surtout si le résultat est le même est que l'encapsulation est préservée.

        [1] Je sais que certains prêchent le « private ou public, mais pas de visibilité intermédiaire » (par exemple Scott Meyer dans Effective C++). Comme toutes les bonnes pratiques (par exemple pour un goto), c'est vrai en général. Et parfois, dans un cas particulier, suivre aveuglément ces bonnes pratiques casse plus les pieds qu'autre chose, pour un résultat pas forcément super impressionnant.
        [2] Oui je sais, tout IDE digne de ce nom peut générer les accesseurs. Mais faut quand même taper les getA/setA ensuite. Bref.

      • [^] # Re: mouais

        Posté par  (site web personnel) . Évalué à 7.

        La principale raison pour laquelle il est déconseillé de ne pas accéder directement aux champs est justement parce qu'il n'est pas possible d'en faire des méthodes par la suite sans changer la signature, et donc devoir modifier tous les appels. À partir du moment où l'accès se fait de manière indifférencié, accéder directement aux champs devient acceptable, et si par la suite, on veut refactorer et transformer les champs en méthodes, on peut le faire sans problème si on peut appeler des méthodes sans mettre de parenthèses.

        • [^] # Re: mouais

          Posté par  (Mastodon) . Évalué à 4.

          L'accès est indifférencié au niveau de la syntaxe, mais ce n'est pas le cas au niveau du bytecode généré. Ça sera donc compatible au niveau source, mais pas au niveau binaire, on peut donc pas passer de l'un à l'autre de façon transparente.

          • [^] # Re: mouais

            Posté par  (site web personnel) . Évalué à 1.

            En effet, c'est pour ça qu'en Scala on passe toujours (au niveau du bytecode) par des setters et getters pour l'accès aux attributs d'une instance.

          • [^] # Re: mouais

            Posté par  . Évalué à 3.

            Si tu peux recompiler ton code, tu n'as donc pas a changer la moindre ligne de code. Cela me semble tout de même intéressant pour ce cas la. Quoique... (voir ma future réponse a Nono - Merci IPoT)

        • [^] # Re: mouais

          Posté par  (site web personnel) . Évalué à 3.

          Ah, en Python tu peux passer une variable en "property", et à ce moment avoir un passage par des getters/setters sans que l'utilisateur n'ait à changer son code (c'est le fait que la variable soit une property qui fait que les accesseurs sont appelés).

          Avantage: tu peux coder normalement et si besoin ultérieurement ajouter de façon transparente des méthodes d'accès.
          Inconvénient: tu ne sais a-priori pas que tu as à faire à un accesseur, donc un appel de méthode, qui peut être coûteux.

          (cf Python property et descriptor protocol)

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: mouais

            Posté par  . Évalué à 2.

            En C#, les properties sont une construction particulière du langage qui permet d’utiliser la même syntaxe pour écrire et lire dans des champs, alors qu'en fait on travaille avec des méthodes.

        • [^] # Re: mouais

          Posté par  . Évalué à 2.

          La principale raison pour laquelle il est déconseillé de ne pas accéder directement aux champs est justement parce qu'il n'est pas possible d'en faire des méthodes par la suite sans changer la signature, et donc devoir modifier tous les appels.

          Non, ce n'est pas la raison. La raison est qu'un accès direct aux champs n'est pas polymorphique (c'est même statique comme le précise Buf) et bloque donc toute réutilisation de ce code avec de la programmation objet, ce qui peut être très gênant et conduire a des copier coller (quelle monstruosité!).

          • [^] # Re: mouais

            Posté par  . Évalué à 1.

            j'ai jamais fait autant de copier/coller qu'avec des get et des setters.

            La bonne façon, c'est ce que fait le C#, une variable public, et si tu as envie de restreindre la portée, tu la transforme en property, c'est transparent pour le reste du code.

  • # Groovy

    Posté par  (site web personnel) . Évalué à 3.

    ça fait penser (d'assez loin) à Groovy. Groovy ne nécessite que d'avoir un jar supplémentaire dans le classpath pour être utilisé.

    La grosse différence, Groovy à un typage dynamique, les regexp sont incluses dans le langage, le default package est plus riche que celui du java classique (ce qui facilite l'écriture des scripts) et les classes de base sont enrichies.

    Exemples de code :
    JAVA
    [. . .]
    List names = new ArrayList();
    for (String name : persons) {
    names.add(name);
    }
    [. . .]
    GROOVY
    [. . .]
    def names = persons*.name
    [. . .]

    JAVA
    String s = "toto "+tutu;
    GROOVY
    def s = "toto ${tutu}"

    Par contre pas de super switch ou de Multiple dispatch en groovy .

    • [^] # Re: Groovy

      Posté par  . Évalué à 3.

      Groovy dispose bel et bien d'un "super switch". Là, comme ça, à la va-vite, ça m'a même l'air un rien plus costaud. Ils ont par contre fait le choix de conserver le fall-through, mais c'est un choix qui se défend.

      Quant au "multiple dispatch", je ne vois pas bien ce que le metaprogramming à la sauce groovy a à lui envier.

      • [^] # Re: Groovy

        Posté par  (site web personnel) . Évalué à 1.

        Je sais pas si on peut différencier le métaprogramming du typage dynamique.
        Voila ce que l'on peut faire en Groovy :

        class Toto {
    def tutu = { println "tutu" }
}

Toto.metaClass.tutu << {println "toto ${delegate.class.name}"} {}
Toto.metaClass.titi << {println "titi ${delegate.class.name}"}
Toto toto = new Toto()
toto.tutu()
toto.titi()

        ce qui affiche

        toto metaclass3 <- nom du fichier sans l'extension...
tutu
titi Toto

        j'ai encore jamais utilisé le switch du groovy :) le fall-through est error prone, mais j'ai tendance à l'utiliser (en commentant soigneusement), donc c'est plutôt une bonne chose pour le Groovy.

      • [^] # Re: Groovy

        Posté par  . Évalué à 2.

        Switch supports the following kinds of comparisons

        • Class case values matches if the switchValue is an instanceof the class
        • Regular expression case value matches if the string of the switchValue matches the regex
        • Collection case value matches if the switchValue is contained in the collection. This also includes ranges too (since they are Lists)
        • if none of the above are used then the case value matches if the case value equals the switch value

        Et comment je teste si la valeur que je teste est égale à [1,2] ? Je mets la collection [[1,2]] ?

        Encore un truc mal fichu; sans parler du breaktrough qui, non, ne se défend pas, c'est juste une mauvaise idée, surtout quand on a une syntaxe pour tester plusieurs cas d'un coup.

        • [^] # Re: Groovy

          Posté par  . Évalué à 0.

          J'ai du mal à comprendre ce qui est une mauvaise idée dans le fall-through, tu peux éclairer ma lanterne ? Je rappelle, au cas où tu ne l'aurais pas compris, qu'en groovy tu as bien la directive "break", qui permet donc au choix de mutualiser le code de traitement de plusieurs cas (par son absence), ou non. Ça m'a déjà été utile, donc je suis curieux.

          Pour tester une collection, tu peux aussi utiliser une closure :

          switch ([1,2]) {
  case { it == [1,2] }:
    //OK
}

          • [^] # Re: Groovy

            Posté par  . Évalué à 6.

            Un bon design fait la chose courante et sûre par défaut, et permet les choses surprenantes, rarement utiles et plus avancées en les demandant explicitement (mais sans les rendre plus difficiles que nécessaire). Il faut que le choix le plus facile soit aussi le plus correct (parce que c'est celui qui sera fait naturellement).

            Le fallthrough n'est pas le bon choix par défaut pour les utilisations usuelles de switch. Est-ce que tu peux montrer un bon exemple en Groovy où le fallthrough est utile ? En C, la classe d'exemple principale est le fait de chaîner plusieurs alternatives à la suite, chacune ayant un code vide sauf la dernière; mais on peut faire ça avec les listes de tests en Groovy.

            Le fallthrough par défaut est la source de nombreuses erreurs dans les programmes. Il est courant d'oublier un break (beaucoup plus que d'en rajouter sans faire exprès) et cela change le comportement du programme d'une façon difficile voire impossible à repérer statiquement (contrairement par exemple à une typo dans le nom d'une variable ou l'oubli d'un paramètre à une fonction, erreurs plus courantes encore mais généralement faciles à détecter automatiquement).

            Go n'a pas de fallthrough par défaut, mais le permet avec un mot-clé explicite fallthrough (documentation). C'est le bon choix pour une construction switch.
            Le choix de Groovy est objectivement mauvais; et le fait qu'ils ne soient pas les seuls à se tromper n'est qu'une maigre consolation.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 1.

              Ce commentaire a été supprimé par l’équipe de modération.

  • # Groovy...

    Posté par  . Évalué à 2.

    Pour ceux que ça pourrait intéresser, la description m'a quand même foutrement rappelé Groovy, qui possède sauf erreur toutes les fonctionnalités décrites et bien d'autres (dont la notion de métaprogrammation, qui peut s'avérer très utile), jusqu'à ce que je comprenne que le compilateur Xtend ne produisait pas du bytecode mais du code java.

    Du coup, c'est vrai que pour l'aspect Android, sur lequel groovy me manque terriblement, ça peut être intéressant.

    • [^] # Re: Groovy...

      Posté par  . Évalué à 6.

      Groovy n'est-il pas dynamiquement typé ?
      Contrairement à Xtend qui serait statiquement typé mais avec inférence de type (ce qui évite d'expliciter les types, mais ils sont bien présents :)

  • # Où est le regard critique ?

    Posté par  . Évalué à 4.

    La news est précise, technique et sobre, c'est bien; par contre j'aurais bien aimé un poil plus de regard critique, on ne cite que des points positifs. Il existe de nombreuses alternatives à Xtend; je ne parle pas des langages JVM "avancés" comme Scala ou Clojure, mais des "Java-like en mieux" qui se veulent simples, incrémentaux et pas trop innovants,
    Ceylon de RedHat. Kotlin de JetBrains.

    Quand on présente un nouveau langage je pense qu'il serait intéressant de ne pas citer que des points positifs, mais aussi des points négatifs (il y en a toujours). Au moins, citer les alternatives me semble indispensable.

    • [^] # Re: Où est le regard critique ?

      Posté par  (site web personnel) . Évalué à 3.

      Perso, j’aime bien Xtend. Et au fond, c’est (rétrospectivement ;-) logique d’une communauté de développeurs spécialisées dans le tooling définisse un nouveau langage faisant usage d’inférence de type…

      Ce que j’aime bien dans Xtend, c’est que j’arrive aisément à imaginer comment les nouvelles fonctionnalités seront compilées en Java et donc, j’arrive facilement à me faire une idée du cout de ces nouvelles fonctionnalités.

      En gros, je suis d’accord avec Stephen Colebourne http://blog.joda.org/2011/07/kotlin-and-search-for-better-java_9066.html :
      - Scala est trop complexe pour devenir le prochain mainstream language qui va détrôner à coup sûr Java
      - Kotlin est associé à des choix syntaxiques en rupture avec Java et pour lesquels on se demande quelle est la valeur ajoutée : http://blog.joda.org/2011/07/reversed-type-declarations_4524.html
      - Ceylon est dans le vapoware space

      Et les autres langages ont aussi des défauts :
      - Groovy est associé à des couts d’exécution « cachés » (cf. points plus hauts).
      - etc.

      Bref, Xtend me semble combler un manque, et améliorer effectivement Java (+/- certaines fonctionnalités dont je n’ai pas encore bien vu l’utilité, ou pu estimer le cout induit, comme les « Create Functions » que je cite ici de mémoire).
      Ce serait bien que le JCP (qui gouverne l'évolution de Java) en prenne de la graine. Cela semble d’ailleurs un peu arriver, timidement, avec la JEP 101 http://openjdk.java.net/jeps/101 listée ici http://blog.joda.org/2011/11/future-is-in-jeps.html

      Il est dit que les processeurs RISC sont arrivés sur le devant de la scène en conjonction avec la maturité des compilateurs permettant d’optimiser le code produit. Java existe depuis plus de 10 ans, et ceux qui écrivent des compilateurs ont progressé, et ont montré, par ex, que l’inférence de type avait sa place dans des langages d’importance, comme C# ou Scala. Bref, il serait temps IMHO que le monde Java se réveille pour suivre un dépoussiérage à la façon de Xtend.

      PS : je ne vois pas trop l'intérêt de rendre les ";" optionnels. Cela complexifie la règle : il peut y avoir 2 cas (";" présent ou non) au lieu d'un seul (";" obligatoire). Bref, cela demande IMHO plus de travail au cerveau des développeurs et, donc, je ne vois pas cette évolution aller dans le bon sens.

      • [^] # Re: Où est le regard critique ?

        Posté par  . Évalué à 7.

        Java existe depuis 20 ans, pas 10, mais l'inférence de type existait déjà à l'époque. Ce ne sont pas "ceux qui écrivent des compilateurs" qui ont progressé, ils étaient déjà au niveau (sur l'inférence de type en tout cas, en 1990 l'état de l'art était très satisfaisant), ce sont les programmeurs "mainstream" qui sont un peu moins ignares qu'avant, et donc les décideurs qui conçoivent des langages pour leur plaire qui ont fait des efforts.

        Ce n'est pas de ta faute, mais c'est un peu agaçant cette tendance à ré-écrire l'histoire en imaginant que les choses se sont déroulées comme les ont perçues la majorité, souvent sous-informée. À en croire certains, l'inférence de types a été inventée par Scala, la compilation JIT par Javascript, la métaprogrammation par Ruby, et la pizza par les américains.

        • [^] # Re: Où est le regard critique ?

          Posté par  . Évalué à 3.

          les décideurs qui conçoivent des langages pour leur plaire qui ont fait des efforts.

          Je ne pense pas que ce soit forcément la raison, je pense que Java a été conçu "à l'arrache" avec un minimum d'effort, ça se voit à pas mal de simplifications abusives dans le langage..

          • [^] # Re: Où est le regard critique ?

            Posté par  . Évalué à 4.

            Ce n'est pas du tout une critique de ton commentaire (très respectable bien qu'à mon avis faux historiquement, Java a été le fruit d'un véritable design, tu confonds peut-être avec l'histoire de Javascript), mais le troll sur la conception de Java j'ai déjà donné et je ne souhaite pas m'y remettre pour l'instant; je ne répondrai donc pas aux prochains commentaires à ce sujet.

            Ce que je voulais dire dans mon message initial c'est que quand on présente un nouveau langage il faut un regard critique qui cherche à la fois les avantages et les inconvénients. Si on n'a pas des deux, ou si on ne mentionne pas les alternatives existantes (Related work, Related work, Related work), on a une dépêche pas équilibrée, non neutre, et donc nettement moins intéressante.

            La réponse de ddevito allait dans mon sens puisqu'il compare Xtend aux alternatives et c'est intéressant, mais j'ai l'impression qu'elle est quand même passée à côté de ce que je voulais dire : c'était un commentaire général sur les dépêches de ce genre, et pas sur Xtend en particulier (sur lequel je n'ai pas grand chose à dire à part "marrant, des développeurs d'IDE qui conçoivent un langage").

            • [^] # Re: Où est le regard critique ?

              Posté par  . Évalué à 2.

              très respectable bien qu'à mon avis faux historiquement, Java a été le fruit d'un véritable design

              Tu as raison: j'ai regardé et effectivement Java a eu une longue gestation (de 91 à 95), c'est le manque de générique et de property au départ qui m'a fait penser que Java a été conçu "à l'arrache" mais apparemment je me suis trompé..

              Pour la comparaison entre les langages, je trouve dommage que ce ne soit pas les concepteurs d'Xtend eux même qui nous expliquent pourquoi leur langage est intéréssant par rapport aux langages existant..

      • [^] # Re: Où est le regard critique ?

        Posté par  . Évalué à 2.

        Kotlin est associé à des choix syntaxiques en rupture avec Java

        Scala a fait grosso-modo le même choix..
        Et personellement je préfère cette façon là YMMV.

    • [^] # Re: Où est le regard critique ?

      Posté par  . Évalué à 2.

      Oui, tu as raison, je ne me suis pas trop penché sur les cotés négatifs, car je ne les connais pas (je n'ai pas essayé le langage) et j'ai suivi le conseil des admodérolecteurs qui demandent que l'on soumette des dépêches, même incomplètes, même imparfaites pour engager la discussion, et c'est ce que j'ai fait en une heure (je ne suis pas Gavin King moi!). D'ailleurs, je me félicite de l'avoir fait puisque les liens que tu as posté dans ton commentaire sont extrêmement intéressants. Merci de l'avoir posté d'ailleurs.
      Pour le moment, je n'ai fait que lire des pages sur Ceylon (pas encore Kotlin), mais alors quelle claque! Vivement qu'ils sortent quelque chose d'utilisable! Je ne connaissais pas ces langages donc merci encore.

      En ce qui concerne la critique / les comparaisons / les alternatives, j'ai juste esquissé un début de comparaison avec C# sans trop aller dans le détail car je ne connais pas assez C# pour en parler avec certitude.

  • # "compilé en Java", abus de langage ?

    Posté par  . Évalué à 3.

    J'ai lu cette formulation dans le post et me suis dit que c'était un abus de langage et que l'auteur voulait dire "compilé en bytecode java".

    Mais en allant sur le site, ils parlent bien de "compiles to readable Java code" et montre un exemple ou ils passent d'un fichier en syntaxe xtend à un fichier en syntaxe java.

    Est ce que l'on peut parler de compilation ou est ce en effet un abus de langage et devrait-on dire "transformation" ?

    (IMHO, c'est un abus de langage)

    • [^] # Re: "compilé en Java", abus de langage ?

      Posté par  . Évalué à 4.

      Selon wikipedia:

      Un compilateur est un programme informatique qui traduit un langage (appelé le langage source) en un autre (le langage cible), généralement dans le but de créer un exécutable.

      Ici, le langage source c'est Xtend et le langage cible c'est java. Donc, non, ce n'est pas un abus de langage.

    • [^] # Re: "compilé en Java", abus de langage ?

      Posté par  . Évalué à 2.

      Compiler, c'est transformer un programme écrit dans langage de départ en un autre programme dans un langage d'arrivée, qui a le même sens que le programme de départ. Il n'y a pas tellement de définition plus raisonnable (souvent on veut aussi que le langage d'arrivée soit plus "bas niveau" que le langage de départ, mais de nos jours on compile vers Javascript...) et l'utilisation ici est donc acceptable.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.