L'environnement est maintenant sous double licence GPLv2 / commerciale. La bibliothèque est sous licence Eiffel Forum License v2 qui est compatible avec la GPL ainsi qu'avec les licences propriétaires. L'environnement est multiplateforme et contient :
- un compilateur générant du C et supportant la compilation incrémentale ou la compilation avec optimisation poussée
- un IDE de bonne qualité
- un débogueur graphique
- le support intégré et graphique de la méthode de conception BON et du standard UML avec réversibilité complète entre le code et les diagrammes
- la génération automatique de documentation de code
- le support de la plateforme .NET
- des bibliothèques
Les autres environnements disponibles pour Eiffel sont SmartEiffel et VisualEiffel qui sont aussi des logiciels libres.
Il est amusant de noter c'est un logiciel valant 4799$ qui est devenu disponible librement.
Aller plus loin
- Annonce (7 clics)
- Un site d'actualité sur eiffel (8 clics)
- SmartEiffel (8 clics)
- VisualEiffel (5 clics)
# Proprio vs libre
Posté par Guillaume Vauvert (site web personnel) . Évalué à 8.
[^] # Re: Proprio vs libre
Posté par gautiers . Évalué à -5.
La licence BSD permet autant de faire du libre que du proprio
http://fr.wikipedia.org/wiki/Licence_BSD
[^] # Re: Proprio vs libre
Posté par FredCL . Évalué à 6.
Sur le site je lis ceci :
"The Open Source version of EiffelStudio under the GNU General Public License (GPL)"
puis ceci :
"Users who donate their source code to the Open Source community can use the Open Source version and must distribute their software under the same license."
Il n'est nulement question de BSD mais uniquement de GPL, il il est clairement dit que les programmes issus de cette version libre doivent être fait sous la même licence donc GPL.
[^] # Re: Proprio vs libre
Posté par Yusei (Mastodon) . Évalué à 0.
[^] # Re: Proprio vs libre
Posté par Yusei (Mastodon) . Évalué à 7.
[^] # Re: Proprio vs libre
Posté par Philip Marlowe . Évalué à 6.
[^] # Re: Proprio vs libre
Posté par outs . Évalué à 4.
Cela dit j'ai quand même eu un doute en rédigant la new car le site web est effectivement pas clair. Si quelqu'un pouvait me confirmer ? je suis pas expert en licence.
[^] # Re: Proprio vs libre
Posté par outs . Évalué à 1.
Je confirme qu'avec la version libre d'EiffelStudio on peut a la fois faire du propriétaire et du libre.
cf : http://blog.daniel-baumann.ch/2006/04/05#20060406_eiffelstud(...)
Donc la mention sur le site officiel est incorrecte. vu que les bibliothèques standard sont dans une license style BSD.
[^] # Re: Proprio vs libre
Posté par Guillaume Vauvert (site web personnel) . Évalué à 0.
Eiffel Software interdit de faire du propriétaire commercial avec la licence libre, mais Daniel Baumann pense que ce n'est pas légal.
[^] # Re: Proprio vs libre
Posté par outs . Évalué à 2.
[^] # Re: Proprio vs libre
Posté par Guillaume Vauvert (site web personnel) . Évalué à 2.
[^] # Re: Proprio vs libre
Posté par outs . Évalué à 2.
D'un autre coté VisualEiffel est clairement a la traine sur EiffelStudio pour l'environnement et sur SmartEiffel pour la qualité de code. donc on s'en fout
[^] # Re: Proprio vs libre
Posté par left . Évalué à 2.
pas du tout. ne fais pas de ton cas une généralité.
[^] # Re: Proprio vs libre
Posté par outs . Évalué à 2.
[^] # Re: Proprio vs libre
Posté par left . Évalué à 4.
C'est pas parce que il y a 1 projet qui est bien que je me fous mes autres, surtout s'ils sont libres et de bonne facture.
[^] # Re: Proprio vs libre
Posté par outs . Évalué à 3.
*VisualEiffel va mourrir
*SmartEiffel va diverger completement (ils ont déclaré qu'ils ne suivront pas le standard ECMA). Donc cela ne sera plus de l'eiffel mais du smarteiffel.
*EiffelStudio va intégrer le compilateur Gobo pour faire des compilations optimisé non incrémentale (eiffelstudio n'est pas très fort sur ce point mais est incrémentale). Les deux projets visent a implémenter ECMA.
Mes deux cents et rien de plus.
[^] # Re: Proprio vs libre
Posté par gautiers . Évalué à -3.
Mais la GPL est loin d'être la seule licence libre
Et vu le titre du commentaire : "Proprio vs libre", cette remarque avait plutot l'air d'etre une grossière généralisation des licences libres et non une remarque sur la licence de Eiffel Studio
# Liens intéressants
Posté par Guillaume Vauvert (site web personnel) . Évalué à 7.
Wiki de eiffel studio : http://eiffelsoftware.origo.ethz.ch/index.php/Main_Page
Versions compilées 32&64 bits pour Linux et Windows : http://eiffelsoftware.origo.ethz.ch/builds/
Code source (subverion) : https://eiffelsoftware.origo.ethz.ch/svn/es/
Code source (websvn) : http://eiffelsoftware.origo.ethz.ch/apps/websvn/listing.php?(...)
Comment compiler : http://eiffelsoftware.origo.ethz.ch/index.php/Compiling_Eiff(...)
Listes de diffusion : http://origo.ethz.ch/cgi-bin/mailman/listinfo
[^] # Et les screenshots, nom de...
Posté par durandal . Évalué à 7.
# Différences par rapport à l'ancienne version "Free"
Posté par Guillaume Vauvert (site web personnel) . Évalué à 6.
= Seamless coverage of the entire software lifecycle
= Cross-platform availability (Windows, .NET, Linux, Unix, MacOS, VMS and others)
= Full support for Design by Contract
+ Automatic documentation generation
+ Diagramming support (BON and UML) with full reversibility between diagram and code views
= Extensive browsing, debugging and refactoring capabilities
= Thousands of reusable library classes from Eiffel Software and other providers
[^] # Re: Différences par rapport à l'ancienne version "Free"
Posté par mickabouille . Évalué à 1.
[^] # Re: Différences par rapport à l'ancienne version "Free"
Posté par Philip Marlowe . Évalué à 8.
[^] # Re: Différences par rapport à l'ancienne version "Free"
Posté par Dr BG . Évalué à 0.
[^] # Re: Différences par rapport à l'ancienne version "Free"
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
# Encore un autre !
Posté par Philip Marlowe . Évalué à 6.
http://gobo-eiffel.sourceforge.net/gec/index.html
https://sourceforge.net/projects/gobo-eiffel/
Ce compilateur est réalisé par Eric Bezault, le créateur de la bien connue bibliothèque Gobo pour Eiffel, qui a pour ambition d'être compatible avec tous les compilateurs Eiffel en activité. Il est réalisé sous la Eiffel Forum License, version 2, compatible GPL, et qui est tellement concise que je peux la citer intégralement ci-dessous :
# pourquoi libérer le studio de developpement maintenant?
Posté par bertje . Évalué à 10.
J'ai l'impression que l'on passe un logiciel propriétaire en libre uniquement pour relancer celui-ci et avoir l'appuie des développeurs du libre...
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Pour réussir, il faut que l'ouverture soit faite très tôt, sous une licence libre et que le logiciel ait sa place parmi la concurrence. Alors il peut rassembler une communauté de développeurs.
Analysons quelques cas :
- Solaris : ouvert trop tard, licence pas libre, Linux et BSD existent => échec
- Blender : ouvert tard, mais était le seul, licence libre => succès
- MySQL : ouvert en 2000, licence libre => succès
- Ingres : ouvert trop tard, concurrence en place, licence libre => échec
- StarOffice/OpenOffice : ouvert tard, mais était le seul, licence libre => succès
- Mozilla : ouvert tard, mais était le seul, licence libre => succès
J'ai eu il y a peu de temps une discussion assez animée avec un commercial de l'INRIA à propos de la licence de Lissac. Il n'a toujours pas compris ce qui fait maintenant l'échec ou le succès d'un logiciel. Il est resté sur des modèles économiques désuets qu'il a appris à l'école. Dans mon esprit, il est un fossile, bien qu'il soit beaucoup plus jeune que moi. Il y a des gens qui font avancer les entreprises, ceux qui ne font rien (ils ne sont pas trop gênants) et ceux qui empêchent les autres d'avancer. Je mets ce commercial dans la dernière catégorie.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Yusei (Mastodon) . Évalué à 8.
Peut-être aussi qu'il s'intéresse moins au succès d'un logiciel qu'à sa rentabilité. Il est relativement facile de démontrer que libérer les sources aide au succès, mais il est quand même un peu plus difficile de convaincre que ça puisse rendre une technologie rentable.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Ontologia (site web personnel) . Évalué à 4.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par JoeltheLion (site web personnel) . Évalué à 5.
Ce genre d'attitude de plus en plus fréquente de la part d'organismes de recherche publics est vraiment inquiétant...
Le but de ces organismes, c'est de permettre l'avancement de la science et de la société en faisant ce qui est insuffisament rentable pour une entreprise, mais qui est rentable pour la société. Pas de faire des profits.
Pareil pour les articles de recherche. Si on paye nos impôts pour se retrouver à payer 30$ pour le moindre papier, je vois pas trop l'intérêt...
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par reno . Évalué à 1.
A long terme, le succès peut aussi amener la rentabilité évidemment c'est loin d'être garanti.
Bon dans le cas particulier de Lissac, il y a tellement de language en concurrence que c'est pas gagné même s'il devenait libre:
D a une communauté assez importante par exemple, Scala est pas mal comme langage, etc..
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Psychofox (Mastodon) . Évalué à 7.
En quoi est-ce un échec ? ça fait tellement peu de temps qu'il a été libéré qu'on est loin de pouvoir faire un constat maintenant.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Cook Captain . Évalué à 1.
Pour plus d'infomations vous pouvez consulter, sur le site de la FSF, la page trés instructive sur les licences : http://www.fsf.org/licensing/licenses/index_html
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Thomas Douillard . Évalué à 8.
En même temps, il y a peut être eu des projets ouvert très tôt (dès le début peut être) qui ont périclités ... Un bon paquet sans doute, dont on a jamais entendu parler. il y a des tas de projets morts sur sourceforge. Et d'un autre côté, il y a pas forcément besoin d'un code ouvert pour faire un succès. Tu enterres le modèle proprio un peu vite, à mon avis, du point de vue du succès auprès des utilisateurs, au moins.
Qu'il se forme une communauté de developpeurs est sans doute une condition nécessaire au succès d'un LL. (Bien que j'ai cru comprendre que les contributeurs à OpenOffice ou à FF sont principalement ceux qui développaient StarOffice ou Netscape en leur temps, pas facile de s'insérer en cours dans des projets aussi énormes). Mais point de vue succès auprès des utilisateurs, on est encore loin des chiffres de MS, même si FF par exemple donne un pourcentage d'utilisateur très loin d'être ridicule, et que globalement le libre progresse.
Je n'irai pas jusqu'a dire, comme toi que le LL vaincra, que le proprio va mourrir, etc. Ce qui me fait le plus tiquer à propos du libre, c'est les questions financières. Les boîtes qui vivent du libres existent, mais les revenus générés sont-ils à la hauteur de ceux des boîtes proprios ? Peut-on faire vivre autant de développeurs avec du libre qu'avec du proprio ? Le mythe du libriste bénévole à ses limites. D'ailleurs je suis pas sûr que la MoFo ou le projet openoffice aient des devs bénévole. Quelqu'un sait d'ou ils tirent leurs revenus ?
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Vador Dark (site web personnel) . Évalué à 5.
Il est vrai que dans le libre, la vente de boite marche assez mal en général. La question est donc, pour une société, de savoir si elle va pouvoir trouver un autre modèle économique viable dans le libre.
Après, sans doute que certains domaines pourront plus difficilement que d'autres percer dans le libre, et seront plus à l'aise dans le propriétaire. On peut aussi trouver des exemples de sociétés qui ont pu percer dans le libre, et qui n'auraient jamais perçées dans le propriétaire, parce que si le libre ne répond pas à toutes les problématiques le proprio non plus.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Thomas Douillard . Évalué à 2.
Je sais parfaitement que la vente de licence ça marche pas très bien dans le libre, et pour cause, et donc qu'il faut que le libre se trouve d'autres modèles économiques. Mais cela appuie au contraire mon raisonnement, et ne répond pas à mes questions, sur le quantitatif en argent notament, et donc en développeurs qui peuvent de consacrer à temps plein au libre, quelque part. Au final, ces autres modèles peuvent-ils générer des revenus suffisants, d'une manière ou d'une autre ? Je l'espère, mais je n'ai pas la réponse.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Ontologia (site web personnel) . Évalué à 3.
1/Modèle propriétaire
Coûts de développement : chers
Qualité finale du projet : Fonction de la qualité de l'organisation, a priori inférieur à un projet libre très actif.
Finition : Excellente, car le projet est pensé en amont.
Coûts de marketing : Très élevé. Un marketeux pour 5 développeurs. Nécessite de dépêcher des évangélistes, d'être une société solide et reconnue.
Profitabilité : élevé.
2/ Modèle Libre
Coûts de développement : Minimes mais résultats aléatoires.
Qualité finale du projet : Bonne mais dépend de l'organisation de départ (Conception, lisibilité du code, normes de dev, etc...)
Finition : Cela dépend des conditions énoncées plus haut.
Coûts de marketing : Assez bas, la communauté fonctionnant sur un modèle de bouche à oreille, de publication, plébiscites, etc...
Profitabilité : Minable.
Après, c'est à discuter, mais l'un et l'autres ont des avantages. Billou n'est pas le plus riche pour rien.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Vador Dark (site web personnel) . Évalué à 3.
Je pense aussi qu'une fortune à la bill gates, dans le libre, serai impossible. Ce qui ne veut pas dire que la viabilité économique d'un projet libre est forcément minable. Jusqu'au jour d'aujourd'hui, elle est beaucoup moindre, et sans doute minable.
Je crois qu'il faut voir deux choses:
->Sa propriété d'être libre.
->L'influence(les conséquences) pour un projet d'être libre, ou d'être propriétaire(conséquence sur le "produit" final).
Si le marché attachait plus d'importance à la propriété qu'à un logiciel d'être libre, sans doute qu'alors les entreprises répondraient à cette demande. Le marché y est globalement indifférent, globalement les entreprises préfèrent le propriétaire qui leur offre directement certains avantages. Ce qui, je trouve, donne une certaine légitimité au logiciel propriétaire(accepté par la majorité).
C'est pourquoi, on tente de jouer sur le second point: le libre et l'efficacité qui s'y associe. Ainsi, même si l'utilisateur ne cherche pas un logiciel libre mais un logiciel peu chère et efficace, il choisira un logiciel libre.
C'est ainsi que j'analyse la situation.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si 50% des PC vendu dans le monde rapportait 10¤ à mandriva, je pense que la société serait multimilliardaire.
"La première sécurité est la liberté"
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Plus sérieusement, une situation comme ça serait justement quasi-impossible avec le libre. Si Mandriva avait 50% du marché, il y aurait quasi immédiatement des forks (typiquement, les distributeurs genre HP, Dell & cie se feraient leur propre version sans payer Mandriva pour chaque copie) qui boufferaient une partie du marché.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Yusei (Mastodon) . Évalué à 6.
Mouais, ça dépend hein. J'ai souvenir d'avoir utilisé un certain nombre de logiciels propriétaires qui affichaient fièrement un numéro de version élevé, et qui n'étaient clairement pas finis. L'exemple le plus énorme était Windows Me, mais il y en a eu pas mal d'autres.
Parmis les inconvénients, du point de vue de la finition, des logiciels propriétaires, je dirais qu'il y a:
- la nécessité de sortir un produit relativement rapidement, pour ne pas investir 10 ans sans rentrée d'argent
- la peur de briser la compatibilité avec les versions antérieures, qui fait qu'on se traîne longtemps les mauvaises décisions de design
- le fait qu'il est plus rentable d'ajouter une fonction qui plaise à 95% des gens que corriger un bug qui touche 0,1% des gens
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par stephwww . Évalué à 1.
Ta phrase me surprend.
Ama, c'est une bonne peur. La compatibilité est importante et c'est un élément déterminant dans le choix.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par outs . Évalué à 2.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par reno . Évalué à 4.
Quand le logiciel perd sa configuration, ne peut plus lire les données de la version précédente, ne tourne plus sur l'OS mis à jour, etc., l'utilisateur est "un peu" frustré.
Il est vrai aussi que l'accumulation de bidouilles pour garder la compatibilité peut en arriver a rendre le code difficilement maintenable..
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Yusei (Mastodon) . Évalué à 2.
C'est une bonne peur à court et moyen terme, parce qu'on n'a pas envie de tout changer tout le temps, mais à long terme, ça oblige à continuer avec les mauvais choix de design qui ont été faits au début. Et il ne faut pas se leurrer, on fait toujours des mauvais choix au début :)
Personnellement, j'aime bien la politique de GTK, qui est de conserver la compatibilité (au niveau des sources et en principe des binaires) pour tous les Y d'une série de versions X.Y, et de casser la compatibilité quand on change de X. Ça marche plutôt bien, dans la mesure où la bibliothèque 1.2 est encore disponible pour les applications qui ne sont jamais passées à la version 2.
Il me semble que dans le libre on peut se permettre d'avoir moins de scrupules à casser la compatibilité avec les versions antérieures, quand c'est nécessaire, dans la mesure où les utilisateurs ont le code source des versions antérieures, et peuvent continuer à les maintenir s'ils le désirent. Mais évidemment, il ne faut pas en abuser :)
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
> faits au début. Et il ne faut pas se leurrer, on fait toujours des
> mauvais choix au début :)
Je ne suis pas d'accord. On fait effectivement des mauvais choix mais on fait aussi des bons choix à l'instant t qui s'avère être des mauvais choix à l'instant t+1. C'est normal, inévitable et même une bonne chose, cela signifie tout simplement que l'objet technique évolue et est vivant (cf Bruno Latour).
C'est donc dans la conception du langage, des bibliothèques... qu'il faut s'accorder des espaces de liberté et ne pas trop contraindre le langage, les bibliothèques... Sinon ceux-ci auront du mal à évoluer et seront donc condannés à une mort quasi-certaine.
C'est d'ailleurs ce que je critique un peu dans Eiffel, il est très beau mais trop contraint.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par outs . Évalué à 6.
Sinon ils ont jamais été présent sur les marchées plus petit, je ne sais pas si c'est un échec. Mais j'ai l'impression qu'ils n'ont en fait jamais essayé.
Enfin c'est quand même un avantage pour eux car du coup les clients sont plutot fidéle, forcement car ISE est la seul société a proposer un service sur Eiffel... Mais je pense pas qu'ils quitteraient ISE même si ils sont plus indépendant maintenant grace a la libération du code, d'ailleurs je pense qu'ils doivent être content de leur collaboration avec ISE et de l'utilisation d'Eiffel.
Par contre avec la montée des langages plus souple que C++ comme Java (même si eiffel peut être considéré comme supérieur techniquement la différence est moins grande aujourd'hui) ISE devait avoir du mal a trouver de nouveau client. Peut-être que le libre leur ouvrira d'autre marché. Ca me semble difficile quand même y'a pas de miracle, il fallait faire ca y'a 10 ans.
Bon personnelement je m'en fout, Eiffel software n'a jamais été capable de promouvoir Eiffel ailleur quand dans les marché de niches. Pourtant il y avait de quoi faire. Toujours est-il que maintenant on peu utiliser EiffelStudio comme on veut.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Thomas Douillard . Évalué à 6.
C'était un modèle économique, qui n'a a priori pas marché pour Eiffel. Est-ce que ça aurait mieux marché si ils avaient tout libérés de base ? Qui peut le dire ... les langages de programmations sont quand même pas mal encombrés, et on reste énormément encore au C et au C++, alors que du point de vue langage, on a fait quand même beaucoup mieux depuis.
# Support Gtk bof
Posté par Miguel Moquillon (site web personnel) . Évalué à 10.
Maintenant, avec l'incohérence qui existe entre le Eiffel de l'ECMA et celui de NICE et les guerres de chapelles entre les partisants de l'un et de l'autre, je me détourne de plus en plus d'Eiffel. Décidemment, Eiffel sera toujours le grand perdant des langages objets à cause d'erreurs politiques ou commerciales à chaque tournant historique du marché des langages objets.
[^] # Re: Support Gtk bof
Posté par outs . Évalué à 2.
Par contre y'a le concept IHM de l'IDE qui est étrange, ca c'est vrai. Au lieu de cliquer sur l'icone d'un outil et d'amener le curseur sur la cible de l'outil on fait l'inverse : on clique droit sur la cible et on l'amene sur l'icone ... Enfin ca a été inventé y'a 10 ans ce truc. On va dire que ca fait partit du folkore Eiffel
Pour le reste : c'est le moins que l'on puisse dire ! :)
Il faut bien replacer la déciser de libérer dans le contexte délicat ou se trouve le monde d'eiffel depuis la scission provoqué par le standardisation EMCA qui n'en était pas une. (en gros ECMA est une nouvelle version du langage non validé plutot qu'une standardisation de ce qui ce fait). Pour le moment aucun compilateur n'implémenta la norme ECMA et a mon avis c'est pas près d'arriver. A mon avis il fallait juste rajouter les concepts intéressant comme les agent (une facon de faire du fonctionnel en objet) et l'héritage d'implémentation et garde la conpatibilité ascendante.
Le problème amha est que dans la tête des utilisateurs Eiffel c'est le langage parfait (enfin ils en ont tous une vision différentes)... du coup personne n'est pret a faire de concession pour assurer la conhérence future du langage et prefere fonctionner en autarcie. Ce qui résume quand même pas mal la situation d'eiffel.
Reste quand même qu'utiliser EiffelStudio pour remplacer un langage comme Delphi et faire une appli sympa rapidement c'est cool maintenant que c'est libre. (En attendant Lisaac que je trouve encore meilleur mais chut ... :)
[^] # Re: Support Gtk bof
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
[^] # Re: Support Gtk bof
Posté par outs . Évalué à 3.
Je suis pas très attentif a ce genre de chose vu que de toute facon en ce moment je dois utiliser une interface un peu étrange rajoutée pardessus xemacs, alors tout me parait merveilleusement ergonomique =)
# Petite blague
Posté par outs . Évalué à 4.
http://origo.inf.ethz.ch/~schoelle/
Y'a un gros bouton rouge au milieu :) (mais sans fonctionnalitée autour)
# Goûtez-y !
Posté par Philip Marlowe . Évalué à 10.
D'abord, en vitesse, les principales caractéristiques, maintes fois exposées, d'Eiffel.
La programmation par contrat permet de spécifier les applications ainsi que de les documenter. En passant, la gestion des exceptions est d'une remarquable simplicité : la génération d'une exception est la violation d'une assertion. Quand j'entrevois le pastis de la gestion des exceptions en, par exemple, Java, ça ne me donne pas envie. L'héritage, multiple bien sûr, ne simplifie pas la vie de ceux qui implémentent des compilateurs Eiffel ; mais celle du reste du monde. La généricité (qui peut certes être simulée par l'héritage, surtout quand il est multiple...) évite la duplication inutile de code et concourt à sa lisibilité.
Si l'on cherche un langage ayant ces trois caractéristiques, il n'y a pas pléthore. On peut ajouter une syntaxe d'une lumineuse clarté, héritée de Simula, de Pascal et d'Ada, l'identité entre la classe et le type, associée à l'unicité de leur représentation par un fichier ainsi que les nombreuses facilités, anciennes ou plus récentes, telles que l'héritage d'implémentation.
Le principal manque de la spécification d'Eiffel concerne les concepts de concurrence et d'application répartie. En ce qui concerne la concurrence, EiffelStudio implémente les threads et permet donc le multitâche. Bertrand Meyer a proposé une conception unifiée de ces concepts sous le nom de SCOOP (Simple Concurrent Object Oriented Programming). Son implémentation offrirait une remarquable facilité d'utlisation aux programmeurs, au prix d'une terrible difficulté pour ceux qui auraient à l'implémenter dans un compilateur.
Bertrand Meyer, le géniteur d'Eiffel, occupe désormais une position académique en tant que titulaire de la chaire de Génie Logiciel à l'Ecole Polytechnique Fédérale de Zurich. Parmi les projets de ses collègues ou élèves, on trouve :
une ébauche d'implémentation de SCOOP, SCOOPLI par Volkan Arslan
http://se.inf.ethz.ch/research/scoop.html
http://eiffelzone.com/esd/scoopli/index.html
AutoTest, un outil de test automatique de code Eiffel, écrit par Andreas Leitner et Ilinca Ciupa comme project de recherche
http://se.ethz.ch/people/leitner/auto_test/
Erl-G, une bibliothèque permettant la réflexivité et l'introspection du langage écrite par Andreas Leitner.
http://se.inf.ethz.ch/people/leitner/erl_g/
Il y a plein d'autres projets concernant Eiffel sur le site de l'ETH. On peut aussi y découvrir des jeux développés par les étudiants comme sujet d'étude.
Ces derniers temps, Eiffel Software promouvait les qualités du langage en tant qu'elles facilitent les pratiques d'outsourcing et d'offshoring, propres à faire grincer les dents de beaucoup de monde, à commencer par les miennes... Cette facilité de sous-traiter le travail logiciel liée à la capacité de bien spécifier, en particulier grâce à la conception par contrats, est une chose à prendre en compte dans l'élaboration collective de logiciels libres. De plus, l'extrême lisibilité du langage, y compris par les non-spécialistes, peut permettre une communication fructueuse entre les praticiens des aspects métier et ceux de la programmation. Je pense qu'un projet métier libre, genre dont on peut espérer la prolification, tirerait grandement parti des qualités d'Eiffel dans le cadre d'un travail distribué et décentralisé, qui sont les caractéristiques fréquentes des projets libres.
Je ne vous parle pas de l'environnement de développement, faites-vous en une idée par votre propre pratique. Je risque d'oublier des délices, entre la navigation dans le code et les multiples outils et facilités qu'il offre et qui font du développement sous EiffelStudio un vrai plaisir. Jusqu'ici, je me retenais de le dire, la chose étant purement propriétaire, maintenant je peux y aller !
En gros, j'ai l'impression, purement subjective probablement, que certains d'entre vous trouvent que la mariée est trop belle.
[^] # Re: Goûtez-y !
Posté par pearlfr (site web personnel) . Évalué à 2.
Je ne connais pas bien Eiffel, j'en avais juste un peu gouté à l'époque de l'Amiga.
J'ai parcouru le site en cherchant les caractéristiques du support des base de données (MySQL, PostgreSQL, SQLite, etc) , sans rien trouver de concluant...
Si le support pass par ADO, ODBC ou .Net, ce n'est pas trés interressant.
Y a t'il des librairies pour un tel support ailleurs ?
Bye
[^] # Re: Goûtez-y !
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Goûtez-y !
Posté par left . Évalué à 3.
C'est un des reproches que je fais au langage Eiffel (que j'aime beaucoup par ailleurs): le concept objet n'a pas été poussé assez loin je trouve. L'introspection du langage devrait faire partie intégrante de ce dernier. Personnellement, je n'aime pas devoir faire 3 passes de pre-processing sur mon code avant de le compiler. Comment tu veux débugger après ? (c'est d'ailleurs le même repproche que je fais à SCOOPCLI).
heureusement que le langage a d'autres atouts !
[^] # Re: Goûtez-y !
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
- support de la covariance multiple,
- support de la généricité contrainte,
- support des agents (<=> sélecteurs de méthodes)
Grâce aux deux premières caractéristiques, Eiffel est considéré, comme Smalltalk, comme un langage à classes et non à types. Or le typage de Cook est plus riche et plus propre que le typage de Liskov qui se trouve rapidement limité avec les types récursifs.
Ce qui manque par contre dans Eiffel actuellement :
- l'ajout de méthodes dans une classe d'objet déjà existante et dont on ne veut/peut pas modifier le source,
- l'introspection naturel (donc dans les spécifications du langage),
- les closures.
Quoi qu'il en soit, depuis 1984, apparition du langage sur le marché, il n'a pas réussi sa perçée et ce n'est pas maintenant, avec la libération d'EiffelStudio, que cela va marcher. Et ceci est principalement dû à de mauvais choix stratégiques.
Depuis quelques temps, avec Self, apparaissent les langages objets à prototype plus prometteurs, comme Lisaac par exemple, et à mon avis, pour m'être amusé avec, et au risque de me faire passer pour un oracle, l'avenir des langages objets leur appartient.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 2.
Je ne vois pas pourquoi il faudrait attendre l'arrivée des langages objet à prototypes pour coder avec des outils confortables et puissants.
[^] # Re: Goûtez-y !
Posté par left . Évalué à 4.
tu peux développer parce que moi je trouve que justement c'est un gros point faible de ce langage, notamment parce que:
- il faut hériter d'une classe pour pouvoir traiter les exceptions
- une exception n'est pas une instance de classe et il est donc impossible de l'identifier par son type
qu'est-ce que tu trouves si bien dans cette conception ? peut être que je passe à côté de qqchose de formidable sans m'en rendre compte!
[^] # Re: Goûtez-y !
Posté par outs . Évalué à 3.
Comme pour n'importe quelle classe utilitaire en Eiffel. oui les classe sont aussi des bibliothèques en eiffel, mais dans la nouvelle version il faut utiliser l'héritage d'implémentation plutot que l'héritage normal (ce qui est plus logique je suis d'accord).
Sinon tout dépend de ce que tu entend par exception :
-si tu veux t'en servir pour programmer comme en Java (genre récuperer une execption sur une conversion String->int pour afficher une message utilisateur) alors les exeptions en eiffe sont nullesl. L'idée de base est que les exceptions (c'est à dire des goto déguisée) détruisent la structure du programme et eiffel est protégé contre cela.
-sinon si tu veux ten servir pour gérer les erreurs. alors eiffel a le concept de conception par contrat qui généralise l'usage des exceptions.
[^] # Re: Goûtez-y !
Posté par Miguel Moquillon (site web personnel) . Évalué à 6.
Une exception est un évènement anormal et pas autre chose. Et c'est ce que propose justement Eiffel ; les évènements anormaux sont le résultat d'une rupture du contrat entre l'appelant et l'appelé (post-conditions, pré-conditions, ou invariants).
Dans les autres langages, les exceptions ont tendance à être utilisées pour traiter même des flots d'exécution normaux ! Ce qui rend les choses difficiles à lire et surtoût à maintenir. Par exemple, les cas d'erreurs dans un programme, lorsqu'ils ont été spécifiés, sont des cas normaux et non des exceptions. Une exception ne devrait traiter que les ... exceptions, c'est à dire des cas qui ne devraient pas arriver, qui n'ont pas été prévus dans la spécification du programme ... que ces cas soient identifiés ou non lors de la conception.
Bien sûr, tout n'est pas rose dans la gestion des exceptions dans Eiffel. Il pourrait être amélioré en ajoutant au langage le support des symboles et donc, il pourrait, par exemple, attacher l'identification d'une exception donnée par un symbole unique.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il manque aussi les itérators de Sather qui simplifie grandement l'arbre des classes.
Enfin, en plus de pouvoir rajouter des méthodes a des classes, il faudrait aussi pouvoir supertypé l'arbre des classes, c'est à dire introduire une nouvelle classe en plein milieu de l'arbre.
Un des problèmes d'Eiffel est que l'arbre des classes est trop rigide et trop imbriqué, du coup, c'est très difficile de le faire évoluer. Or, par définition, un langage se doit d'évoluer, il y a toujours quelques erreurs de conception.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 3.
http://www.di.ens.fr/~castagna/pub.frame.html
Si j'ai bien compris, l'avantage de la contravariance est qu'elle ne pose jamais de problème. Son inconvénient est qu'elle prive de toutes les possibilités où la covariance serait valide. Mantenant ce sont les compilateurs Eiffel qui analysent le code pour détecter les possibles catcalls. Choisir la contravariance comme l'ont fait les créateurs de Sather semble résulter d'une analyse, sinon simpliste, du moins manquant de finesse. On se prive de possibilités, de la même manière que d'autres langages n'implémentent pas l'héritage multiple, pour ne pas compliquer l'implémentation du compilateur.
Ceci dit, il est assez fréquent que j'entende parler de Sather là où se trouvent des discussions sur Eiffel. Existe-t-il des compilateurs Sather qui permettent de produire des applications de la vie réelle ? Y en a-t-il qui de plus proposent un environnement de développement avec quelques facilités ? Et y a-t-il des applications ou des services informatiques qui utilisent Sather ? Ces questions sont sans malice, j'avoue seulement mon ignorance dans ce domaine.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Les personnes qui ont développés Sather ont montré que les exemples de Meyer était "bidon" et qu'on pouvait très bien les refaire en contravariant en utilisant la généricité. Je ne suis pas spécialiste des langages mais je n'aime pas le sacrifice qu'a fait Eiffel, ce trous dans le langage, surtout s'il y a une autre possibilité, qui elle n'a aucun trous !
Par ailleurs, il ne faut pas en faire un plat non plus. Le C++ n'a pas de variance du tout et des milliers d'applications réelles sont développés avec. Eiffel est un nain négligeable à coté, Sather étant lui même un nain à coté d'Eiffel.
Sather est malheureusement virtuellement mort aujourd'hui, l'équipe de recherche qui le développait aux états unis ayant vu ses crédits arrétés. Au moment de son arrêt, vers 1999 d'après mes souvenirs, l'environnement de développement était pas si mal (il y avait même une option de compilation pour activer la reflexivité).
Je me suis amusé un peu sur Eiffel vers 1998 puis j'avais essayé Sather. Il a lui aussi des défauts mais comparativement, quel bonheur. Le langage semble bien moins lourds ;-) Il est clair que pour celui qui débite du code Eiffel à longueur de journée, ce type d'argument n'est pas valable.
Si je parle de Sather ici, ce n'est pas pour changer Eiffel, la suppression de la covariance dans Eiffel reviendrait à refaire un autre langage. Mais justement l'INRIA avec Lisaac fait un nouveau langage et ils trainent sur ce forum. Mes quelques post de néophite ne sont que des messages subliminaux ;-)
Pour en revenir au compilateur Sather, il existe toujours et doit toujours marcher. Le paquet debian a été malheurement enlevé de l'archive. Je ne conseille à personne de développer un gros projet en Sather aujourd'hui. Cela n'empêche pas de voir en lui un petit frère d'Eiffel qui a trouvé un voie intéressante mais non finit.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 2.
Si tu lis le papier de Castagna que je t'ai indiqué, tu verras que la question de la covariance et de la contravariance ne sont pas des notions opposées mais qu'elles recouvrent des objectifs de nature sémantiquement différentes.
Par ailleurs je ne promeus pas ici Eiffel comme un langage expérimental, mais comme un outil disponible aujourd'hui pour produire des logiciels, avec ses défauts. Comme tu le dis, on peut bien aussi utiliser C++... Le vrai défaut d'Eiffel, comme cela a été pertinemment évoqué ici, c'est sa relative pauvreté en bibliothèques et en frameworks.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En voici un sorti de la documentation de Sather. Il est vrai qu'il vaut mieux comprendre un peu le système de type de Sather pour tout piger.
http://www.icsi.berkeley.edu/~sather/Documentation/EclecticT(...)
Par exemple, il faut savoir que l'héritage de code et d'interface sont dissociés en Sather. Lorsqu'on dis qu'une classe hérite d'une autre, elle n'hérite que de l'interface. L'héritage de code doit être explcité avec le mot clef "include".
Ca fait bizarre la première fois mais dans les fait, c'est pas du tout génant, c'est même mieux car très clair. Et maintenant, pas mal de langage rajoute la notion d'interface à la notion de classe (Eiffel compris) quand elle n'ajoute pas aussi l'inclusion de code ! Bref, la aussi, Sather en séparant les rôles a finalement simplifié et se montre au final plus souple.
Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel. Ca ne l'aide pas non plus. A cela s'ajoute qu'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN". Le C s'en sors très bien sans mais pour des raisons historiques.
IIl parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac. S'il est vrai que cela n'a aucun intérêt technique pour le compilateur, ca a un intérêt social énorme pour les développeurs.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 2.
C'est vrai ; il ya trois compilateurs Eiffel, bientôt quatre avec Gobo, tous au moins partiellement sous des licences libres. VisualEiffel est resté à la version 2 de la spécification du langage, et n'implémente donc pas les agents. EiffelStudio et SmartEiffel implémentent, eux, les agents, mais chacun de manière différente. VisualStudio veut implémenter petit à petit les spécifications de l'ECMA, alors que l'équipe de SmartEiffel affirme que c'est la spécification d'un langage différent ; par contre SmartEiffel rend sensible à la casse l'écriture des programmes, alors que les textes Eiffel sont insensibles à la casse depuis la création du langage...
Gobo veut faire des outils et des bibliothèques compatibles avec tous les compilateurs en activité. Comme VisualEiffel en fait partie et n'a pas les agents, les bibliothèques Gobo n'utilisent pas les agents. Si VE s'y met, il faut espérer que ce ne sera pas d'une troisième manière différente... Si l'on suit les mailing lists de Gobo, on peut voir que c'est SmartEiffel qui leur pose le plus de problèmes.
SmartEiffel a produit un compilateur incompatible depuis le 2.0 avec sa version précédente, la 1.1. Du coup, quelques un, dont Daniel Moisset ont créé une version 1.2 de SmartEiffel dont le but est d'être compatible avec le versions 1.1 et la dernière 2.x afin de faciliter la migration des programmes écrits dans la première vers la deuxième.
Mon avis est que SmartEiffel est devenu un compilateur expérimental, un laboratoire où les chercheurs de l'INRIA peuvent essayer leurs excellentes idées, mais qu'on ne peut pas considérer comme un outil de travail permettant de produire des logiciels aspirant à une certaine pérennité. VisualStudio est un outil qui permet de travailler d'une manière efficace. Désormais une version libre existe. Pourquoi ne pas s'en servir ?
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 4.
Bravo pour le lapsus !
[^] # Re: Goûtez-y !
Posté par outs . Évalué à 2.
Ouais mais en fait les namespaces ne font que repousser le problème des conflits de nom dans les namespace. Si par exemple en C++ je veux utiliser le namespace std, je peux pas. C'est juste qu'il y a moins de problème car il y a moins de namespace différent dans le monde que de nom de classe.
Eiffel possède aussi un mécanisme pour gérer les conflits de nom mais ce n'est pas dans le fichier source mais dans le fichier "make" d''eiffel. A cet endroit on peut résoudre les conflit de nom de classe et même renommer des classes c'est plus sympa je trouve. J'ai réfléchit un peu a ca et finalement je trouve que les problème de conflits de nom c'est plus un problème des gestion de projet que de programmation donc c'est normal de régler ça dans les fichiers "a la make". A priori Lisaac utilisera le même système
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Maintenant, essayes de mettre tout le CPAN dans un seul projet ! Ca explose. Le but d'un "namespace" est de permette à des projets différents de mutualiser du code source. c'est pour cela que l'approche java qui préconise de prendre les noms de domaine DNS a l'envers n'est pas bonne et que l'approche du CPAN de Perl est excelente. Elle permet de mutualiser un maximum le code des bibliothèques entre projet.
C'est pas ton Makefile, si bien fait soit-il, qui va te faire cela. Comme je le dis depuis le début, ce n'est pas un problème technique, c'est un problème sociologique. Il fait donc intervenir de multiples personnes. Si vous souhaitez que Lisaac marche, il faut tenir compte un minimum des problèmes sociologiques.
[^] # Re: Goûtez-y !
Posté par reno . Évalué à 2.
J'aimes bien ce concept.
[^] # Re: Goûtez-y !
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
- la contravariance des arguments d'entrée associée à la covariance simple respectent le typage classique (typage de Liskov),
- la contravariance multiple et la covariance multiple ne respectent pas le typage de Liskov (typage de premier ordre avec polymorphisme)
- la covariance multiple respecte le typage de Cook (typage de second ordre : un typage qui, à mes yeux, est le typage le plus adapté à l'esprit objet puisque la grande partie de ses propriétés, comme le polymorphisme, en découlent naturellement). En fait, la covariance multiple en découle même.
Dire que la contravariance est mieux que la covariance est une erreur, de la même façon que l'inverse, ceci du point de vue du typage de Liskov. Eiffel, permet, par ses constructions, de /simuler/ le typage de Cook. Une proposition avait été faite à Meyer de le supporter complètement mais celui-ci l'a refusé ; les arguments des uns et des autres étaient valables et le choix ne relevait plus que d'un décision subjective.
[^] # Re: Goûtez-y !
Posté par reno . Évalué à 3.
Uniquement dans les universités ou à long terme alors:
Self est quasiment inconnu malgrè son âge (pas tellement étonnant car c'était juste une exploration) et Lissac le seul endroit ou j'en ai entendu parler c'est ici!
En plus comme pas mal de langages universitaire, sa syntaxe me prend à rebrousse poil.
Ce qui bien sûr ne prélude pas au succès ou pas du concept de langage à prototype.
Eiffel est un bon exemple de langage qui n'a pas réussi à percer malgrès bien des qualités, et les langages fonctionnels soi-disant supérieurs restent à la traine depuis combien de temps?
Ruby et Java par contre sont des bons exemples de ce qui permet à un langage de percer (enfin Ruby n'est pas encore vraiment sorti de l'auberge et Java bien qu'utilisé n'est pas vraiment apprécié).
[^] # Re: Goûtez-y !
Posté par outs . Évalué à 2.
Oui c'est *exactement* ça ...
Ah mon avis Eiffel a deux principaux défaut pour l'industrie informatique. Cela tient au fait que la méthode eiffel permet d'obtenir plus rapidement un résultat de meilleur qualité. Ce qui veux dire :
1. on gagne moins d'argent en utilisant eiffel car on programme plus vite : donc il y a moins d'heure de travail a facturer.
2. on gagne moins d'argent en utilisant eiffel car on produit moins de bug : donc on ne peut pas vendre des nouvelles versions/mise à jour pour corriger les bug.
Je suis peut être (très) désabusé mais le principal but de l'industrie logicielle n'est *pas* de faire des produits de qualité mais de gagner de l'argent en *vendant* du logiciel. Et pour cela ce n'est pas nécessaire de faire de la qualité.
Prouvez moi le contraire ca me remontera le moral ...
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 4.
Je me permets de remarquer que la production de logiciels libres ne souffre pas des mêmes soucis. La qualité tout de suite, c'est bon à prendre.
[^] # Re: Goûtez-y !
Posté par outs . Évalué à 3.
C'est vrai c'est d'ailleur une des raison pour laquelle on est tous là.
Mais par contre les développeur libre adorent utiliser des techniques/langages plus difficile d'utilisation.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . Évalué à 2.
Pour l'enquête psycho-sociologique, je me déclare incompétent :-)
[^] # Re: Goûtez-y !
Posté par outs . Évalué à 5.
Mais je suis sur que c'est plus facile d'expliquer le succes ou l'échec des langages en utilisant seulement des argument sociaux ou commerciaux
[^] # Re: Goûtez-y !
Posté par パパフラクス . Évalué à 5.
De plus il y a qd même un client à satisfaire, et selon la situation ce n'est pas toujour à lui de payer.
[^] # Re: Goûtez-y !
Posté par vrm (site web personnel) . Évalué à 8.
[^] # Re: Goûtez-y !
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Goûtez-y !
Posté par photon . Évalué à 2.
Comme tu le dis, ça "existe" mais pas comme partie du langage. En java pur, il est juste possible de documenter les pre et post-conditions. Pour le code, il y a bien les asserts comme en C/C++ mais il est alors nécessaire de re-copier ce code dans les sous-classes. Dans ce contexte, on pourrait dire que la programmation par contrat existe en C/C++...
Par contre, on peut dire que ça existe indirectement, en utilisant iContract qui est un pré-processeur java: http://www.javaworld.com/javaworld/jw-02-2001/jw-0216-coolto(...)
En Eiffel, les pre/post-conditions sont specifiées dans l'interface de la méthode et sont répercutées dans les sous-classes par héritage.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.