Sortie de Haxe 3.2.0

Posté par  (site web personnel) . Édité par palm123, Benoît Sibaud et tuiu pol. Modéré par tuiu pol. Licence CC By‑SA.
Étiquettes :
28
17
juin
2015
Technologie

Haxe est un langage de programmation orienté objet, open source, basé sur un système de classes comme C# ou Java.
Il permet de mettre en place des types abstraits, des metadatas, des Generics, des Enums, ou encore faire de la programmation fonctionnelle comme en F#.
C’est une solution robuste, multi-paradigme, parfaitement adaptée au développement d’applications web, au jeu et au mobile.

Logo Haxe

Il y a quelques jours, la version 3.2.0 est sortie avec son lot de nouveautés et de corrections.
Cette dépêche présente les principaux changements et profite de l'occasion pour refaire un tour des possibilités offertes par ce langage.

Sommaire

Haxe

Un peu d'histoire

Le développement de Haxe a été commencé fin 2005 par Nicolas Cannasse alors qu'il travaillait pour Motion Twin, un éditeur de jeu indépendant.
Haxe a toujours été open source mais en 2013, la gouvernance du projet est offerte à la fondation Haxe.

Cette année, il va donc fêter ses 10 ans.

Le langage

Haxe est un langage de programmation moderne, capable de tenir la comparaison avec du C# ou du Java, en matière de fonctionnalités.
Sa syntaxe est également très proche de ces derniers mais rappelle également le JavaScript.

class HelloWorld {
        static public function main() {
            trace("Hello World");
        }
    }

Voici une petite liste des possibilités offertes par le langage :

  • Classes, Types(Strict ou dynamique), Interfaces et Héritages
  • les Abstract Types : utiles pour exemple pour étendre un type primitif et surcharger ses opérateurs. On peut imaginer ainsi créer les types Kilomètre, Mètre, et Millimètre, et faire des opérations comme 12500mm / 10km
    abstract Kilometer(Float) {
        public function new(v:Float) this = v;
    }

    abstract Mile(Float) {
        public function new(v:Float) this = v;
        @:to public inline function toKilometer():Kilometer return (new Kilometer(this / 0.62137));
    }

    class Test {
      static var km:Kilometer;
      static function main(){
        var one100Miles = new Mile(100);
        km = one100Miles;

        trace(km); // 160.935
      }
    }
  • Structures anonymes
    var point = { x: 0, y: 10 };
    point.x += 10;
  • Enums, Accesseurs, programmation fonctionnelle, et inférence de type
  • Pattern Matching, Inlining, Array Comprehension, Compilation conditionnelle
  • Generics, Type Parameters, Constraints et Variance :
class Main<A:B> {
    static function main() {
        new Main<String>("foo");
        new Main(12); // use type inference
    }

    function new(a:A) { }
}
  • Les macros : sans doute l'une des plus puissantes fonctionnalités de Haxe. Elles permettent de "programmer" le comportement du compilateur. macros

Le compilateur

Haxe n'est pas un langage propre à une technologie comme Java avec la JVM. Son compilateur (ou transpileur) va convertir le Haxe dans un autre langage. Aujourd'hui il supporte le JavaScript, le PHP, le C++, le C#, le Java, l'AS3, Neko, et le Python.

Il ne s'agit absolument pas d'une solution pour faire du cross-plateforme, mais bien de remplacer un langage par un autre. Il n'est pas (directement) possible de compiler un même code pour du Java et du PHP par exemple.
Un framework open source basé sur Haxe existe pour faire du cross-plateforme, c'est OpenFL.

Le compilateur est très rapide, un sentiment qui se renforce si on a l'habitude de compiler du Java ou du Dart.
Sur le code généré, il se montre particulièrement efficace. Il profite de la compilation pour nettoyer et optimiser le code. C'est particulièrement notable par rapport à du JavaScript.
decoding time

Pour quoi faire ?

Utiliser Haxe à la place d'un autre langage peut apporter beaucoup de choses. TypeScript, Dart, ou encore CoffeeScript font la même chose pour JavaScript, et Scala et Groovy pour Java.

Haxe permet également de profiter d'un même langage coté client et coté serveur, de partager les mêmes objets et de s'affranchir d'un contrat d'interface.
Par contre il ne dispense pas de connaitre la technologie pour laquelle on compile. Il est important de connaitre le PHP, pour faire du Haxe pour PHP.

Enfin Haxe permet de profiter d'un même langage sur des typologies de projets différentes comme par exemple JS/PHP, ou Android/NodeJS , etc…

Qui fait du Haxe ?
Le jeu vidéo est le premier domaine où brille ce langage. Que ce soit pour du jeu web, mobile, ou desktop.
Sa présence au Ludum Dare est notable.
L'utilisation d'OpenFL pour faire des jeux cross plateforme favorise son adoption. OpenFL va prochainement exporter pour XBox PS4 et WiiU.
OpenFL 3

Sans surprise, le développement d'application web est également un domaine propice à l'utilisation de Haxe.

Les nouveautés de la 3.2.0

Après la sortie de la version majeure 3.0.0, cette nouvelle version est surtout focalisée sur la correction de bugs et la robustesse.

Python

La grosse nouveauté c'est le support de Python 3.

En Haxe :

package;

class Main {

    static function main() {
        for (projectile in ['apples', 'oranges']) trace( 'I threw $projectile!' );
    }

}

En Python :

class Main:

    @staticmethod
    def main():
        _g = 0
        _g1 = ["apples", "oranges"]
        while (_g < len(_g1)):
            projectile = (_g1[_g] if _g >= 0 and _g < len(_g1) else None)
            _g = (_g + 1)
            print(str((("I threw " + ("null" if projectile is None else projectile)) + "!")))


class python_internal_ArrayImpl:

    @staticmethod
    def _get(x,idx):
        if ((idx > -1) and ((idx < len(x)))):
            return x[idx]
        else:
            return None


class HxOverrides:

    @staticmethod
    def stringOrNull(s):
        if (s is None):
            return "null"
        else:
            return s



Main.main()

Rest, EitherType, @:selfCall and @:callable

La gestion des "external type definitions" est améliorée avec l'ajout de deux types haxe.extern.Rest et haxe.extern.EitherType, et aussi deux nouveaux "metadata", @:selfCall and @:callable.

Typed Arrays

Haxe 3.2.0 ajoute le support cross-plateforme des Typed Arrays dont l’implémentation a été fortement inspirée par celle de Javascript.

Compiler.addGlobalMetadata

Pour ceux qui utilisent les macros, Compiler.addGlobalMetadata permet d'attacher un metadata à n'importe quel type ou méthode qui n'a pas été traité par le compilateur.

NodeJS support

L'extern type definitions de NodeJS est maintenant directement supporté par la Foundation Haxe.

Pour une liste complète il y a le changelog.

Aller plus loin

  • # Relecture ?

    Posté par  . Évalué à 0.

    Je ne voudrais pas avoir l'air de critiquer sans contribuer (mais en fait, si :-)), mais la lecture de cette dépêche est vraiment pénible : orthographe défaillante, anglicismes même lorsque ce n'est pas nécessaire.

    Sinon, la dépêche oublie de précidser que Neko est une machine virtuelle écrite par le même Nicolas Cannasse (http://nekovm.org/). Je ne crois pas qu'elle soit très utilisée…

    • [^] # Re: Relecture ?

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 18 juin 2015 à 13:09.

      orthographe défaillante, anglicismes même lorsque ce n'est pas nécessaire.

      tu peux préciser ?

      PS : j'ai retouché 2 formulations discutables, je suis d'accord pour les anglicismes, mais je cherche l'orthographe défaillante.

      ウィズコロナ

      • [^] # Re: Relecture ?

        Posté par  . Évalué à 2.

        Je ne retrouve pas les fautes, je présume qu'elles ont été corrigées entretemps.

  • # Enfin !

    Posté par  . Évalué à 1.

    Article bien complet sur un des fleurons Oss français, cette nouvelle version était vraiment très attendue !

  • # Erreurs dans l'article sur Scala, Groovy et Java

    Posté par  . Évalué à 2.

    "Utiliser Haxe à la place d'un autre peut apporter beaucoup de choses. Scala et Groovy font la même pour Java."

    Scala et Groovy sont des langages qui n'ont rien à voir avec Java, Groovy est un langage dynamique, Scala est un langage OO et fonctionnel. Le point commun c'est que ces langages produisent un bytecode qui s'exécute sur une JVM, mais il est impossible de transformer du code Groovy ou Scala en code Java.

    • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

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

      C'est précisément ce que je voulais dire.
      On va choisir Scala à la place de Java pour profiter d'un langage fonctionnel et produire du bytecode à destination de la JVM.

    • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

      Posté par  . Évalué à 3.

      mais il est impossible de transformer du code Groovy ou Scala en code Java.

      Même en décompilant le bytecode généré vers du Java ?

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

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

        Je m'étais amusé à décompiler du code Scala avec un décompileur Java : quelques traitements de base sur une liste de chaines.
        Le décompileur a généré du Java pour 80% du source.
        Pour le reste… il a donné sa langue au chat et affiché le bytecode

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

          Posté par  . Évalué à 3.

          Merci pour l'info, je ne connais le bytecode java que je très loin et que pensait qu'il était possible de reconstruire du Java à partir de n'importe quel bytecode, ce n'est visiblement pas le cas.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

            Posté par  . Évalué à 0.

            C'est un peu étonnant. On comprend qu'il ne soit pas possible de reconstruire avec certitude le Java original, mais le bytecode devrait forcément pouvoir être retraduit en un équivalent Java. Après tout, le principe du bytecode est en général de coller d'assez près au langage source pour lequel il a été conçu (contrairement au langage machine).

            • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

              Posté par  . Évalué à 4.

              Dans le cas du bytecode Java, ce n'est pas toujours possible car certaines contraintes n'existent pas dans le bytecode mais existent dans le Java.
              Par exemple, le fait que la première instruction d'un constructeur doivent être l'appel au constructeur de la super classe n'existe pas dans le bytecode. Scala utilisait ça par moment.

              De même dans la gestion des exceptions, Java est connu pour ses checked exceptions qui font partie de l'interface, cependant c'est une contrainte purement au niveau du source, et pas dans le bytecode. Même si les checked exceptions se retrouvent dans l'interface du bytecode, elles ne sont explicitement pas vérifiées. Scala n'a pas ce concept. Pour avoir du bytecode Scala avec exceptions décompilé avec qui recompile en Java, il faut réinférer toutes les exceptions qui ne sont pas des RuntimeException pour les ajouter dans l'interface. Bref, ce n'est pas direct.

              Scala génère aussi des suites d'instructions bytecode qui peuvent ne correspondre à aucune construction en Java. Par exemple les boucles en Java sont compilées d'une certaine manière et Scala les transforme différemment, notamment dû au fait qu'un for scala se traduit en des appels à des méthodes du style map et flatMap. Le compilateur Scala fait aussi de l'optimisation des récursions terminales triviales, je ne suis pas sûr de comment un décompilateur Java peut retraduire ça, si le code généré correspond à comment le compilateur Java compilerait un while.

              Il y a plein de raisons pour lesquelles il est impossible de ressortir du Java à partir de bytecode, la JVM étant moins restrictif que le langage Java. Les obfuscateurs de bytecode jouent là dessus, en réorganisant les instructions pour sans changer la sémantique mais en créant des séquences qui sont inatteignables depuis le Java.

              L'avantage du bytecode est surtout d'être encore assez abstrait pour être portable, il n'a pas besoin de coller au langage source. Surtout pour la JVM maintenant qui fait tourner du bytecode généré depuis plein de langages très différents (java, scala, closure, groovy, python, ruby, ocaml, …). Par exemple le bytecode OCaml est assez loin du langage source, voir les instructions

            • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

              Posté par  . Évalué à 4.

              Java 7 a introduit des opérations au niveau du bytecode (opcodes) uniquement destinées aux langages de scripts tels JRuby, Groovy, Jython, etc. javac ne produisait aucun de ces opcodes a partir de code Java.
              Donc aucun decompilateur ne peut reconstruire du Java a partir d'un tel bytecode.
              Avant cela, les langages de scripts supportant les fonctions en tant qu'objets de première classes ne pouvaient certainement pas être reconstruit en Java ou de tels objets n’existaient tout simplement pas.
              Depuis Java 8, tout ceci a peut être changé.

              En plus, souvent quand on parle de Java on confond souvent le langage de la plateforme (le bytecode, la JVM, etc.).

              L'analogie qui compare Coffeescript + JavaScript avec Groovy + Java et foireuse, car Coffeescript compilé en Javascript (le langage) pour être exécuté sur une VM Javascript, alors que Groovy est compilé en bytecode (plateforme) pour être exécuté sur une JVM. La ou Javascript mélange langage et plateforme, Java les distingue clairement.

    • [^] # Re: Erreurs dans l'article sur Scala, Groovy et Java

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

      Scala est tout de même fortement marqué par Java, et je ne pense pas qu'on puisse faire du Scala sans connaître des particularités de Java. Je pense notamment aux différences Int/int.

  • # Connaissance des technologies cibles nécessaire ?

    Posté par  . Évalué à 3.

    Merci pour cette dépêche, je ne connaissais pas Haxe et j'irai sans doute y jeter un oeil prochainement ! :)

    Par contre il ne dispense pas de connaitre la technologie pour laquelle on compile. Il est important de connaitre le PHP, pour faire du Haxe pour PHP.

    Peux-tu préciser un peu plus ce point là ?
    A part pour l'interfaçage avec le code existant, pour quelle raison a-t-on besoin de connaître la technologie cible ?

  • # nouveauté ?

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

    Je n'ai pas compris l'apport de haxe par rapport à d'autre langage voir même C++.

    C'est un langage objet de plus ? Les macro ont l'air de sortir de l'ordinaire.

    "La première sécurité est la liberté"

    • [^] # Re: nouveauté ?

      Posté par  . Évalué à 5.

      Merci a David pour l'article !

      Je dirais que l'une des principales différences de Haxe par rapport à un autre langage OO est dans le fait que Haxe a été conçu dés le départ pour pouvoir être généré sur de nombreuses plateformes. Celà nous permet donc de conserver une vitesse native quelle que soit la plateforme ciblée (navigateur avec JS, mobile, desktop, etc.)

      Ensuite il y a bien entendu les spécificités du langage : inférence de type globale, enums, macros, etc.

      Je vous invite à consulter le manuel ici : http://haxe.org/manual

    • [^] # Re: nouveauté ?

      Posté par  . Évalué à 4.

      Lorsqu'il a été dévoilé, le cas d'usage dominant de HaXe était de créer des applications Flash sans passer par les outils Adobe. Je ne sais pas ce qu'il en est maintenant…

      • [^] # Re: nouveauté ?

        Posté par  . Évalué à 1.

        hello,

        en effet, j'ai déja utilisé haxe pour tester, et la cible "de base" etait du flash. Ca marchait bien, mais vu que le flash est en plein déclin, je me demande aussi si se mettre à haxe est pertinent aujourd'hui. Par contre la news dit que les mobiles font partie des plateformes ciblées, j'imagine alors qu'on peut faire autre chose que du flash.

        • [^] # Re: nouveauté ?

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

          Oulalaaaa, je pensais etre clair :-/
          Haxe maintenant compile en JavaScript, Java, c#, c++, php, et python

          Rien que ça c'est super.

          Et si on utilise OpenFL, il cross-compile en natif pour Android, IOS, mac, pc, linux,ps, xbox, html5, etc…

          • [^] # Re: nouveauté ?

            Posté par  . Évalué à 1.

            ok, je vais retester, j'ai envie de cibler javascript + html5 (la balise canvas). Merci pour l'info!

          • [^] # Re: nouveauté ?

            Posté par  . Évalué à 5.

            Ça c'est un point ou j'ai eu du mal sur cette dépêche et ailleurs sur le web qui passent trop rapidement sur cette question.

            C'est quoi la différence entre Haxe et OpenFL? pourquoi on parle souvent d'OpenFL si Haxe est deja multiplateforme?

            J'ai trouve ce fil de discussion qui m'a éclairé:
            http://stackoverflow.com/questions/20687000/haxe-openfl-flixel#20714465

            En gros, Haxe est multi plateforme si l'on s'en tient a la librairie standard. Or cette dernière semble limitée lorsque l'on veut faire des choses un peu avancées. On peut ensuite faire des imports spécifiques a la plateforme avec "js", "php", etc. mais l'on perd alors le cote multiplateforme.

            Pour palier a ça, OpenFL (Open Flash Library) a été créé (indépendamment d'Haxe) pour pallier a ce manque. Il s'agit d'une implémentation multiplateforme de la librairie de Flash pour Haxe. Du coup quelle que soit la plateforme ciblée, on peut coder avec l'API de Flash, qu'OpenFL va implémenter sur les plateformes cibles, et on a vraiment un jeu multiplateforme.

            Flixel semble aller plus loin qu'OpenFL et fournit des widgets supplémentaires lorsque les performances sont insuffisantes.

             

            Malgre l'insuffisance de certaines explications, je remercie l'auteur de cette dépêche, car j'ai enfin pu comprendre ce qu'est Haxe et pourquoi il a du succes.

  • # oui, mais si on debugge?

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

    Est-ce qu'il y le service minimum niveau outillage (IDE avec complétion intelligente et debugger)?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # on nous a déjà fait le coup

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

    "parfaitement adaptée au développement d’applications web"

    J'ai l'impression d'avoir déjà entendu cela pas mal de fois depuis des années. Malheureusement tous les langages récents viennent avec une idée différente et des dizaines de mauvaises idées car sans prendre l'expérience des autres. Du coup… et bien tout cela laisse de la place au langage suivant qui comblera une faille et en introduira des dizaines et tout cela laisse de la place au… la roue tourne!

    Franchement, ce qui est important dans un langage c'est ce qu'il interdit pas ce qu'il permet! Certains langage a typage dynamique (Python) introduisent maintenant des "glutes" pour contraindre ces derniers! Ne fallait il pas y penser avant en prenant l'expérience de Modula, Ada… Que d'énergie perdu :(

    Dans Haxe ben un langage de plus!

    • [^] # Re: on nous a déjà fait le coup

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

      Certains langage a typage dynamique (Python) introduisent maintenant des "glutes" pour contraindre ces derniers!

      A part cette proposition de GvR sur les annotations de fonctions, qui ne cible pas un contrôle de type strict à l'exécution mais permettrais la mise en place de vérificateur off-line, tu as des infos sur ces “glutes” ?

      Sinon, je ne vois pas la perte d'énergie, les langages dynamiques comme Python, Perl & co ne ciblent pas du tout les mêmes développements que Ada, Modula et consort.

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

  • # Ludum Dare

    Posté par  . Évalué à 2.

    C'est quoi Ludum Dare? C'est la troisième fois que je vois une référence dessus mais je ne sais toujours pas ce que c'est ni ce que cela représente.

    • [^] # Re: Ludum Dare

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

      Tu peux regarder Ludum Dare ;-)

      • [^] # Re: Ludum Dare

        Posté par  . Évalué à 3.

        Merci!

        J'avais regarde le site web et je n'avais rien compris.
        Je n'ai pas pense a regarder sur wikipedia car je n'ai pas pense que la notoriété serait suffisante.

Suivre le flux des commentaires

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