Journal SmartEiffel RIP

Posté par  (site web personnel) .
Étiquettes : aucune
10
19
juil.
2009
Cher Journal,

Bon ça sentait le sapin pour SmartEiffel (le compilateur Eiffel GNU) depuis un moment mais là ça a l'air carrément mort :

http://n2.nabble.com/Status-of-SmartEiffel-(alive-or-dead)-t(...)

C'est ce qui arrive quand un compilateur décide de ne plus compiler le code existant (passage de SmartEiffel 1->2) pour devenir une sorte de dialecte incompatible avec les autres compilo. Se coupant ainsi de ses utilisateurs.

Car il y avait une petite communauté autour de SmartEiffel 1 (et avant SmallEiffel), qui n'a pas suivi et les gens sont restés en version 1 et ont migré sous d'autres cieux.

Et puis, pourquoi porter le code s'il risque d'être cassé à nouveau lors d'une prochaine version ? Je suis resté scotché à la version 1 comme les autres. Quant à forker un compilo Eiffel ben...

Dommage, ce compilateur était bien sympathique et j'ai passé de nombreuses heures avec.

On me demande une épitaphe
Pour SmartEiffel mort. En vain
Je creuse, et je rue et je piaffe ;
Je ne trouve qu’un mot : « Enfin ! »

(Baudelaire, épitaphe pour la Belgique)

  • # .

    Posté par  . Évalué à 3.

    J'adore la réponse de Dominique Colnet, elle est parfaitement significative de l'ambiance qui règne dans l'équipe.

    • [^] # Re: .

      Posté par  . Évalué à 3.

      Je ne lui jetterais pas la pierre, il a vraiment investis beaucoup de temps dans ce projet..
      C'était mon professeur quand j'étais en école d'ingénieur, et c'est un type que j'ai toujours apprécié, super balèze, il nous a initié à smarteiffel (smalleiffel à l'époque), m'as appris beaucoup de choses et était vraiment à l'écoute de ses élèves.
      Pour l'ambiance qui règne dans l'équipe, je dirais qu'elle doit être bonne, en tout cas à l'époque l'ambiance était au beau fixe car son projet était vraiment innovant.
      Franchement, le connaissant, je pense qu'il a essayé d'améliorer Eiffel, de toute bonne foi.
      Je pense qu'effectivement la rétro-compatibilité n'était pas son but premier, mais améliorer le language, expérimenter de nouvelles méthode d'optimisations etc...
      Ne l'oublions pas, Dominique Colnet est un chercheur, il aime les défis, et répondre aux critiques ne doit pas être son passe temps favoris...

  • # Le langage aussi?

    Posté par  . Évalué à 5.

    Et qu'en est-il du langage proprement dit? Il y a des gens qui utilisent encore Eiffel?

    J'avais l'impression que les problèmes n'étaient pas limités à SmartEiffel, mais plutôt que le processus de standardisation chaotique avait entrainé (ou du moins accéléré) sa chute...

    En tout cas c'est dommage, il y avait plein de bonnes choses dans ce langage. Et quand à SmartEiffel, ils avaient une approche originale de la compilation orientée objet (à base d'IDs et de branchement dichotomiques en lieu et place du tableau de méthodes). Sans oublier que c'était une excellente source de trolls...

    • [^] # Re: Le langage aussi?

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

      Et qu'en est-il du langage proprement dit? Il y a des gens qui utilisent encore Eiffel?

      Peut-être quelques sociétés mais ça a l'air moribond. À priori il ne reste plus que le compilateur Eiffel produit par la boite de Bertrand Meyer (EiffelStudio)

      les pixels au peuple !

      • [^] # Re: Le langage aussi?

        Posté par  . Évalué à 3.

        Ce n'est pas moribond, c'est marginal. Je m'en sers pour mon boulot mais ne comptez pas sur moi pour en faire un plat, une fois que tout le monde aura admis l'aveuglante évidence que c'est le meilleur langage du monde.

        Sinon, question compilateur c'est vrai qu'il n'y a pas foule, mais il n'y a tout de même pas que EiffelStudio de Eiffel Software, il y a aussi GEC (Gobo Eiffel Compiler), pas assez avancé pour être utilisé en production et tecomp, The Eiffel Compiler qui est à la fois un compilateur et un interpréteur et qui n'en est pas encore à la version 1.0.

    • [^] # Re: Le langage aussi?

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

      Cette approche de la compilation par analyse de flot se retrouve aussi dans Lisaac ... un langage assez proche de Eiffel en fait (le premier compilateur Lisaac a été écrit en Eiffel d'ailleurs).

      Bon, la aussi, le projet n'a pas l'air très vivace. Il bouge, on fait des choses, mais il reste encore à faire des releases propres et publier les dernières versions du compilateur Lisaac.

      Si tout se passe bien, j'aimerais d'ailleurs bien porter Lisaac sur l'architecture LLVM. Ça serait vraiment bien.

      • [^] # Re: Le langage aussi?

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


        Si tout se passe bien, j'aimerais d'ailleurs bien porter Lisaac sur l'architecture LLVM.

        LLVM est très loin d'être utilisable donc bon...

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

        • [^] # Re: Le langage aussi?

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

          ???

          LLVM est fonctionnel.

          Ce qui n'est peut être pas fonctionnel complètement, c'est LLVM-clang, surtout lorsqu'on considère le langage C++. Ce projet vise a créer un front-end pour les langages dérivés du C.

          Mais LLVM en lui même est un framework complet de compilation, qui inclus des front-end (clang, gcc, ...) et des back-end (fichiers objets natifs, bytecode pour une machine virtuelle, code C, ...). Il y a un langage assembleur spécifique à LLVM et standardisé qui permet aux deux parties de communiquer.

          • [^] # Re: Le langage aussi?

            Posté par  . Évalué à 1.

            ce qu'il veut dire à mon avis c'est que dans ce framework il y a des bugs ou des fonctionnalités pas/mal implémentées .
            personnellement je n'en sait rien mais sur des listes de discussion j'ai vu des gent qui disaient ça aussi.

          • [^] # Re: Le langage aussi?

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

            Bon les enfants, vous vous étriperez là dessus lors de notre réunion fin aout :-)

            Trève de plaisanterie, un port de plus, pour un projet qui a des chances d'être au point un jour, car tout de même supporté par Apple, n'est pas une mauvaise idée.
            Et le compilo est assez bien découpé pour porter assez facilement.

            N'insultons l'avenir.

            Pour les realease, elles ont lieu environ tous les deux ans, on est encore dans les temps (il me reste à faire la doc...)

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

            • [^] # Re: Le langage aussi?

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

              Quelqu'un avait passé un commentaire ou il avait essayer de compiler des programmes disponibles sous une distributions Linux en utilisant LVM, les résultats n'étaient pas fameux. L'idée est sympa si LVM marche.

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

              • [^] # Re: Le langage aussi?

                Posté par  . Évalué à 3.

                Tu le fais exprès ?

                C'est llvm-clang ou llvm-gcc qui est a blâmer dans ce cas. Pas le framework (llvm) qu'ils utilisent...

                • [^] # Re: Le langage aussi?

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

                  Si ton entrée, c'est du C...

                  Si la version C n'est pas correct, quel sont les cas d'utilisation ayant une bonne stabilité dans ce cas ?

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

          • [^] # Re: Le langage aussi?

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

            Et d'ailleurs Dominique Colnet sera là à la réunion...

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

  • # compatibilité

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

    C'est ce qui arrive quand un compilateur décide de ne plus compiler le code existant (passage de SmartEiffel 1->2)

    Bah... Python l'a bien fait entre la v2 et la v3... Mais ils avaient pour eux une base d'utilisateurs plus grande et des outils de migration pas trop mal!

    • [^] # Re: compatibilité

      Posté par  . Évalué à 8.

      Faut pas parler au passé pour ce cas la, peu de gens utilisent python 3.

    • [^] # Re: compatibilité

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

      Bah... Python l'a bien fait entre la v2 et la v3... Mais ils avaient pour eux une base d'utilisateurs plus grande et des outils de migration pas trop mal!

      Mais il n'y a qu'un interpréteur python (?).

      Là c'est un peu comme si un compilo C décidait de ne plus compiler le C.
      Ça fait désordre...

      les pixels au peuple !

      • [^] # Re: compatibilité

        Posté par  . Évalué à 2.

        Mais il n'y a qu'un interpréteur python (?).
        Non.

        • [^] # Re: compatibilité

          Posté par  . Évalué à 3.

          tu aurais pu developper un peu plus mais ta reponse est en effet la bonne. Juste pour info:

          Jython http://www.jython.org/
          Pypy http://codespeak.net/pypy/dist/pypy/doc/
          Ironpython

          sont des interpreteur de python differents, pas tous au meme niveau mais bon le projet jython a repris vis recemment, pypy avance pas mal et le dernier j'en ai rien a carre donc je sais pas. Il y a donc 4 differents interpreteurs de python.

        • [^] # Re: compatibilité

          Posté par  . Évalué à 2.

          et parrot ? :)

    • [^] # Re: compatibilité

      Posté par  . Évalué à 2.

      Bah... Python l'a bien fait entre la v2 et la v3... Mais ils avaient pour eux une base d'utilisateurs plus grande et des outils de migration pas trop mal!

      La grosse différence est que Python 3 est la « nouvelle version » officielle de Python : si j'ai bien compris ce qu'il s'est passé pour Eiffel et SmartEiffel, l'équipe de ce dernier a décidé de développer une version du langage spécifique, plutôt que le standard qui ne les satisfaisait pas. Je ne pense pas que la co-existence de deux versions plutôt concurrentes du langage soit très saine pour ce dernier...

      • [^] # Re: compatibilité

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

        l'équipe de ce dernier a décidé de développer une version du langage spécifique, plutôt que le standard qui ne les satisfaisait pas. Je ne pense pas que la co-existence de deux versions plutôt concurrentes du langage soit très saine pour ce dernier.

        Juste au passage, je voudrais juste dire que c'est le cas pour COBOL.
        L'éditeur Microfocus a sa propre norme ( dérivée quand même des standards) et ma prof de COBOL m'a dit que tous les éditeurs de compilo COBOL (ou presque) ont fait la même chose. C'est chiant, ça ne permet pas de bosser sur différents compilos (je voulais utiliser opencobol sur mon linux mais ça ne marchait pas après sur les machines de l'IUT) mais a priori COBOL n'en est pas mort, vu le nombre de banques qui' l'utilisent encore.

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

        • [^] # Re: compatibilité

          Posté par  . Évalué à 2.

          C'est aussi le cas des divers compilos C/C++ ... Et GCC a pas mal d'extensions "GNU". Et ils font la même chose avec :
          -sed
          - awk
          - make
          - plein d'autres trucs ....

          Ces incompatibilités ont nécessité d'ajouter une couche permettant de gérer tout ça (et qui au passage ajoute encore de la complexité) : les autotools ...

Suivre le flux des commentaires

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