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)
Journal SmartEiffel RIP
19
juil.
2009
# .
Posté par Romain . Évalué à 3.
[^] # Re: .
Posté par ecyrbe . Évalué à 3.
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 drakmaniso . Évalué à 5.
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 Patrick Lamaizière (site web personnel) . Évalué à 2.
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 Philip Marlowe . Évalué à 3.
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 drakmaniso . Évalué à 2.
http://sourceforge.net/projects/tecomp/
[^] # Re: Le langage aussi?
Posté par Mildred (site web personnel) . Évalué à 3.
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 Nicolas Boulay (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 Mildred (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 caouis . Évalué à 1.
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 Ontologia (site web personnel) . Évalué à 1.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Le langage aussi?
Posté par geb . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# compatibilité
Posté par Zenitram (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!
[^] # Re: compatibilité
Posté par fridim . Évalué à 8.
[^] # Re: compatibilité
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1.
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 Romeo . Évalué à 2.
Non.
[^] # Re: compatibilité
Posté par mscestdelamerde . Évalué à 3.
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 geb . Évalué à 2.
[^] # Re: compatibilité
Posté par auve . Évalué à 2.
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 Framasky (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 2.
-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.