Articles précédents : Articles
- [15] Deux polices libres cursives
- [15] NovaForge.org : un nouveau guide des logiciels libres
- [147] GNU Affero General Public License : la GPL des applications web
- [0] PloneGov récompensé à Paris par le Grand Prix du Jury des Lutèces D'Or
- [34] L'assemblée nationale, personnalité de l'année 2007
- [49] Créer une discipline informatique à l'école ?
- [2] Initiation à la ligne de commande, jeudi 14 (gentoo-class)
- [5] Naissance du projet PloneGov européen
- [24] Un UMPC sous Linux
- [15] Acceleo 2.0.0 : génération de code PHP, JEE, Java, CSharp et Python
Liens connexes
- SmartEiffel (120 hits)
- SE sur Gforge (44 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Sortie de la bêta 2 de SmartEiffel 2.3
Posté par THEpini (page perso, ). Modéré le 26 juin 2007.
L'année a été riche en nouveautés. Beaucoup de progrès ont été fait côté compilateur, mais aussi côté bibliothèques et confort des utilisateurs. Certains projets externes ont vu le jour (Eiffel Wrapper Libraries Collection - EWLC, Entreprise SmartEiffel - ESE, Useful SmartEiffel - USE) dont les acteurs ont fortement contribué aux améliorations de cette nouvelle fournée.
Cette bêta annonce la sortie prochaine (espérons-le) de la version stable 2.3, ce que certains développeurs de SmartEiffel attendent pour pouvoir intégrer leurs tous derniers changements ("bord coupant" :-) dans la future version 2.4.
![[en]](../../../images/en.png)
SmartEiffel (120 hits)-
SE sur Gforge (44 hits)
> Lire la suite (9 commentaires, moyenne: 2,8). [dépêche : 2140 caractères]
- Clarification des règles de conformité (lien insert/inherit) : détails sur la page Typing_policy du wiki ;
- Nouvel algorithme pour le chargement des classes. Cet algorithme tient compte de la "distance" entre les classes pour décider laquelle utiliser. Lorsqu'il existe deux classes avec le même nom, le compilateur parcourt l'arbre formé par les fichiers loadpath.se pour trouver la classe la plus "proche" (au sens "répertoire à parcourir"), d'abord en profondeur puis en arrière ;
- Installation améliorée : un effort a été consenti sur la fin pour permettre un meilleur packaging dans les distributions (certains ont peut-être remarqué la présence d'un paquet 2.2.99 dans Debian unstable) ;
- Configuration améliorée : l'ancien fichier ~/.serc (ou /etc/serc) a été remplacé par un répertoire du même nom. A l'intérieur de celui-ci peuvent maintenant se trouver plusieurs fichiers de configuration (leurs noms importent peu). Ceci permet une meilleure intégration de paquets externes nécessitant des fichiers de configuration (EWLC/USE/ESE ?) ;
- Le paramètre -debug_check est périmé. Un nouveau paramètre -debug permet d'activer les blocs debug ;
- L'ancienne classe READY_DESCRIPTION du séquenceur a été remplacée par la classe EVENTS_SET pour unifier tout type d'évènements ;
- La bibliothèque a été un peu améliorée, notamment avec RECYCLING_POOL pour permettre la réutilisation d'objets ;
- Les clusters net, exec et xml ont été améliorés, avec notamment une validation par DTD automatique et un parseur "namespace-aware" ;
- Un nouveau cluster "language" est apparu. Son but est d'héberger des interfaces vers d'autres langages, notamment les langages de script. Pour le moment, seul Perl est représenté ;
- Le fameux bug des inspects sur STRING a été éradiqué, ainsi que de nombreux autres bugs un peu partout.
Eiffel, trop tard ...
Le langage Eiffel est un très bon langage mais qui n'a pas réussi à percé pour différents motifs et je pense essentiellement dû au décalage entre l'attente des développeurs/décideurs et ce qui était fourni.
Maintenant, il aura d'autant plus de mal avec d'une part le Eiffel de NICE et le Eiffel de l'ECMA. Sur lequel pouvons nous vraiment miser ? Décidément, Meyer n'a jamais su vraiment profiter ou créer les opportunités qu'il fallait.
A côté de ceci, il y a l'arrivée de nouveaux langages objets comme par exemple Lisaac ou Io, et ceci sans parler du renouveau de Smalltalk, toutjours imité, mais jamais vraiment égalé (si ce n'est peut-être par Self), avec par exemple Squeak, seaside, ... et probablement dans un future plus ou moins proche, StrongTalk.
De plus actuellement, l'environnement des langages objets utilisés dans l'industrie s'est grosso-modo bipolarisé avec d'un côté la plateforme Java et de l'autre C# et sa plateforme .NET.
-
[^]Re: Eiffel, trop tard ...
Posté par THEpini (page perso, ) le 26/06/2007 à 15:24. (lien). Évalué à 3.Effectivement, on reproche souvent à Eiffel son manque de connexion avec les utilisateurs et la "faible" communauté qui l'entoure, mais malheursement tout ceci est un cercle bien vicieux : les utilisateurs ne suivent pas, donc le langage se développe sans eux, du coup ils ont l'impression d'avoir été mis de côté, donc ils ne suivent pas...
A noter à propos de lisaac, un rapprochement est en cours entre l'équipe de SmartEiffel et celle de Benoit Sonntag, qui donnera sans doute naissance à un outil eiffel_to_lisaac.-
[^]Re: Eiffel, trop tard ...
Posté par Ontologia (page perso, ) le 27/06/2007 à 07:53. (lien). Évalué à 2.... Et après deux jours de coding intense et joyeuse, l'outil est presque prêt, reste à le finaliser.
Connaissant la rigueur extrême, voire la maniaquerie des deux protagonistes, ça devrait prendre quelques temps, mais le plus gros est fait.
Il y a eu beaucoup d'échanges d'idées et Eiffel devrait s'inspirer de certains de Lisaac(le futur modèle de concurence COP par exemple).
D. Colnet et B. Sonntag se sont aussi bien vite rendu compte que'un traducteur Lisaac_to_eiffel était malheureusement impensable. Dommage, une passerelle entre les deux aurait été sympa...
-
-
[^]Re: Eiffel, trop tard ...
Posté par GTS () le 26/06/2007 à 16:09. (lien). Évalué à 2.J'ai un peu essayé SmartEiffel car un des concepteurs était prof dans mon IUT. Ca m'a valu quelques bonnes notes car ce langage est vraiment sympa.
Tous les concepts qui font recette en programmation orienté objet s'y retrouvent.
Cependant le programmeur-bidouilleur est souvent frustré car le manque de communauté en fait un langage très peu fourni en librairies "annexes".
La compilation SmartEiffel passe, de mémoire, par une "traduction" en C.
Et c'est là qu'on est le plus souvent frustré, puisque le C est bien plus complet que l'eiffel.
On ne va pas par exemple re-coder l'OpenGL pour pouvoir l'utiliser en Eiffel !
Je n'ai hélas pas eu le courage de pousser plus loin mon expérimentation d'Eiffel à cause de ces "défauts".
C'est dommage car j'avais bien accroché aux concepts du langage.-
[^]Re: Eiffel, trop tard ...
Posté par viridis (page perso, ) le 26/06/2007 à 17:37. (lien). Évalué à 2.
Cependant le programmeur-bidouilleur est souvent frustré car le manque de communauté en fait un langage très peu fourni en librairies "annexes".
Cependant le programmeur-bidouilleur est souvent frustré car le manque de communauté en fait un langage très peu fourni en librairies "annexes".
La facilité d'interfacer du C avec SmartEiffel permet d'avoir facilement et rapidement accès à toutes les bibliothèques C...et ce, spécialement pour les "bidouilleurs"..
De plus, un vrai "bidouilleur" n'est jamais avare en écriture de wrapper ou autres :)
On ne va pas par exemple re-coder l'OpenGL pour pouvoir l'utiliser en Eiffel !
Un widget vision (le système de GUI de SmartEiffel) est dispo depuis longtemps...
Ceci dit, je comprend les arguments, mais comme le dit pini, c'est un cercle vicieux à transformer en cercle vertueux !
-
[^]Re: Eiffel, trop tard ...
Posté par Rémi Pannequin (Jabber id, ) le 26/06/2007 à 19:13. (lien). Évalué à 3.« J'ai un peu essayé SmartEiffel car un des concepteurs était prof dans mon IUT. Ca m'a valu quelques bonnes notes car ce langage est vraiment sympa. »
C'est aussi mon cas, mais il était maître de conf dans mon école d'ing. (Je pense qu'on parle de la même personne...) :-)
Eiffel est vraiment un langage agréable, car il permet d'utiliser très simplement toutes les fonctionnalités des langages à objets. Le langage mets en oeuvre en plus le paradigme de programmation par contrat, qui constitue une alternative très intéressante aux outils de tests unitaires (a la JUnit).
Ha nostalgie ! Quand je pense que je n'écris plus qu'en java (et en VB /o\ )...--
Qui invente, qui réinvente, quelle importance ? (Yakari, tome 16)
-
GOBO : une autre alternative
Il existe un autre compilateur Eiffel, gec de la librairie GOBO : http://www.gobosoft.com. C'est aussi un projet libre, qui fournit une librairie assez riche et des outils pour Eiffel.
Pour développer en Eiffel, je conseille vivement EiffelStudio, un excellent IDE.
J'ai travaillé sur une extension d'Eiffel (implémentation de l'héritage inverse) et j'ai trouvé le langage trés intéressant.
Ces nombreux mécanismes exploitent plein de bonnes idées qu'on peut trouver dans le paradigme objet.
-
[^]Re: GOBO : une autre alternative
Posté par Jazz () le 26/06/2007 à 22:27. (lien). Évalué à 4.Et au passage, EiffelStudio 6.0 (qui existe en version GPL) est sorti le 19 juin dernier.
http://eiffelsoftware.origo.ethz.ch/
Eiffeldoc et ravalement de façade...
Un grand absent de ce changelog mais qui est pourtant bien présent, c'est la nouvelle mouture d'eiffeldoc, l'outils de documentation de SmartEiffel !
Le plus simple c'est d'aller voir ce que ça donne par ici :
http://smarteiffel.loria.fr/libraries/index.html
Nouveau style donc, mais aussi nouvelles fonctionnalités avec entre autre une navigation plus facile (présence de "blocs dépliables" et plus de lien dans l'API) et davantage d'informations affichées.
On notera que le site du projet a fait peau neuve également bien qu'il reste certaines vieilles pages :
http://smarteiffel.loria.fr/
Cette page a été générée par Templeet en 0.0759s (dont 0.0138 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.