Rappelons qu'Eiffel est un langage conçu pour être le plus purement objet possible, et est utilisé surtout dans des contextes où la sécurité/fiabilité du logiciel est primordiale. SmartEiffel, développé par une équipe d'universitaires français, permet de compiler du code Eiffel vers du code C ou du bytecode Java et inclut une large bibliothèque ainsi que des outils complémentaires (debugger, pretty-printer, générateur de documentation...)
Aller plus loin
- Le site officiel de SmartEiffel (18 clics)
# Mémoire
Posté par Alban Peignier (site web personnel) . Évalué à -1.
Sacré Dominique :))
# Eiffel
Posté par Moby-Dik . Évalué à 6.
... plus que Smalltalk ?
et est utilisé surtout dans des contextes où la sécurité/fiabilité du logiciel est primordiale
Heu, plutôt Ada non ? ;-)
Sans vouloir jouer les rabat-joie, il faut être honnête : la principale raison pour laquelle Eiffel est populaire dans les milieux académiques français, c'est justement que c'est un langage conçu par un Français. Pour le reste, il faut avouer que même si c'est un bon langage, il n'a pas de qualités suffisamment extraordinaires pour réussir à s'imposer face aux langages déjà établis. Son utilisation en milieu industriel (contrairement à Ada justement) ou scientifique est anecdotique.
[^] # Re: Eiffel
Posté par Lafrite . Évalué à 4.
http://www.battlefront.com/products/stratcom/stratcom.html(...)
Bien sympa comme petit wargame
-1 car pub
[^] # Re: Eiffel
Posté par Djax . Évalué à 10.
AMHA ce n'est pas la bonne comparaison. SmallTalk est un des meilleurs langage OO (quand je vois Squeak http://www.squeak.org/(...) , je dirais même qu'il est le meilleur OS objet.), mais malheureusement il n'a que le héritage simple.
Je dirais que c'est le plus pure langage objet multihéritage( surtout face à C++.). Il n'a pas à supporter le passé du C.
Sans vouloir jouer les rabat-joie, il faut être honnête : la principale raison pour laquelle Eiffel est populaire dans les milieux académiques français, c'est justement que c'est un langage conçu par un Français.
Il manque les balises <troll></troll>.
Pour le reste, il faut avouer que même si c'est un bon langage, il n'a pas de qualités suffisamment extraordinaires pour réussir à s'imposer face aux langages déjà établis.
Si par qualité, tu entends "argent", "marketing", "moyen de diffusion", "bonne politique d'évangilisation", je suis d'accord: si ESI (ex-ISE http://www.eiffel.com(...) ) avait la même politique pour son EiffelStudio que Borland et son JBuilder,s'il avait donné leur compilateur à grande échelle gratuitement comme Sun. Bien sûr (et heureusement) Sma(rt|ll)Eifel existe, mais il n'est pas mis en avant par Bertrand MEYER.
Sinon Eiffel a:
Ce qui manque encore à SmartEiffel est une IDE et plein de gens sachant <troll>vraiment</troll> programmer en objet multi-héritage pour enrichir les clusters(bibliothèques).
Son utilisation en milieu industriel (contrairement à Ada justement) ou scientifique est anecdotique.
Héritage du passé et manque de personnes qualifiées font que certains dinosaures (Cobol,C,...) restent présents
--
Eiffel rulez
[^] # Re: Eiffel
Posté par Moby-Dik . Évalué à -4.
Comme avec... les assert() en C. Les lois de Murphy démontrent l'insuffisance notoire de telles constructions : tu ne les utilises jamais là où elles auraient été réellement utiles ;)
le ramasse-miettes
Super. Et pour les performances, c'est comment ?
BON
Plaît-il ??
Héritage du passé et manque de personnes qualifiées font que certains dinosaures (Cobol,C,...) restent présents
Oui, mais c'était Ada que je citais. Besoin de sommeil ?
[^] # Re: Eiffel
Posté par Djax . Évalué à 10.
Le paradigme de "Design By Contract" a été mis en avant (voir inventé) par Bertrand MEYER et a été implanté en natif dans Eiffel. Tu as 3 contrats majeurs: la précondition, la postcondition et l'invariant.
(pour plus d'info: http://www.eiffel.com/doc/manuals/technology/contract/page.html(...) )
Bien sûr, tu peux faire du DbC avec des autres langages, mais Eiffel l'implante correctement et facilement.
http://home.rochester.rr.com/skapp/DBCCollateral/DBCForC.PDF(...)
Les lois de Murphy démontrent l'insuffisance notoire de telles constructions : tu ne les utilises jamais là où elles auraient été réellement utiles ;)
La programmation par contrat aurait évité l'explosion d'Ariane 5:
http://www.eiffel.com/doc/manuals/technology/contract/ariane/page.h(...)
Comme toute technique, il faut savoir l'utiliser.
> BON
Plait-il ??
Business Objet Notification est un notation simple, adapté au multi-héritage et le DbC. Il est très facile à comprendre et à utiliser (un concurrent simple d'UML):
http://www.cs.yorku.ca/~paige/Bon/bon.html(...)
Super. Et pour les performances, c'est comment ?
C'est très bien, parce que les perfs des processeurs doublent chaque année, que les techniques de ramasse-miettes vont très bien, que la programmeur fait de la conception de haut niveau et pas de la comptabilité de mémoire. Maintenant bien sûr que si tu préfère faire de l'assembleur pour les perfs à tout prix, c'est ton choix :-). Moi,quand je peux, je préfère ne pas m'en préocupper et me concentrer sur la conception.
Plus la complexité augmente, moins nous devons avoir à nous préoccuper du bas niveau.
Oui, mais c'était Ada que je citais. Besoin de sommeil ?
Je ne connais pas assez ADA dont Eiffel est un héritier, mais certains langages feraient mieux de passer la main plutôt que faire de mauvaise évolution: http://www.elj.com/eiffel/why-eiffel/#Ada(...)
[^] # Re: Eiffel
Posté par Moby-Dik . Évalué à 1.
www.eiffel.com/doc/manuals/technology/co
T'as oublié les balises <troll>.
Tu ne réponds pas à la question. Les techniques de vérification, si elles ne sont pas obligatoires, on oublie toujours de les utiliser à un endroit ou un autre. Que ce soit du haut niveau (dbc) ou du bas niveau (assert) ne change rien au problème.
[^] # Re: Eiffel
Posté par Djax . Évalué à 8.
Des contrats sont inclus dans les classes de base, donc si tu compiles en contrôlant toutes toutes assertions (compilation par défaut), tu es obligé d'utiliser ces classes correctement. Si tu as besoin de mettre des contrats dans tes classes,tu peux facilement. Obliger à mettre des contrats n'aurait pas de sens, ce serait comme obliger d'avoir des paramêtres pour toutes les features. Lorsque tu programmes une feature en Eiffel, tu penses à ce que tu exiges (précondition) et à ce que tu assures (post-condition) et tu t'assure un état cohérent (invariant).En faisant ça systématiquement, ça aide beaucoup à avoir un code sans bug.
Une fois que ton code a bien tourné sans violer aucun contrat, tu le recompiles sans les contrats
("compile -boost") et ton application tourne plus vite.
Maintenant si tu ne veux pas mettre de contrat, tu peux, mais c'est ta responsabilité.<troll>Si tu veux (vraiment) te mettre une balle dans le pied, tu peux</troll>
[^] # vérification des contrats
Posté par Dugland Bob . Évalué à 2.
Est-ce qu'il en fait au moins une partie à la compilation ?
[^] # Re: Eiffel
Posté par Dugland Bob . Évalué à 10.
Super. Et pour les performances, c'est comment ?
Beaucoup moins couteux que le dynamic-binding sur de l'heritage multiple.
Beaucoup plus efficace et secure (et pratique pour les utilisateurs avances) qu'une gestion manuelle si on sait c'en servir.
Beaucoup plus mauvaise connotation chez les mecs qui ne se renseignent pas dessus.
merde, pas les accents ma Ultra 5 :-(
[^] # Re: Eiffel
Posté par Moby-Dik . Évalué à 1.
Ou peut-être que tu ne t'es pas "renseigné" sur le problème ;-))
[^] # Re: Eiffel
Posté par Dugland Bob . Évalué à 5.
Malheureusement, je ne suis pas chez moi, donc je n'ai pas acces a mes bookmarks.
Il existe des techniques de GC deterministes.
D'autre part, toujours l'heritage multiple, rend la complexite assez chiante a apprehender bien qu'elle soit deterministe (si on vire le cache de methodes evidemment).
Je ne suis vraiment pas convaincu que Eiffel soit un bon choix pour ce type d'applications.
Par-contre, l'explicitation des contrats est vraiment une voie a suivre.
qd a la spec du GC, sur un probleme qui vaut la dette du Senegal, y'a moyen d'en developper un a la demande.
[^] # GC temps-réel
Posté par Dugland Bob . Évalué à 3.
http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.htm(...)
C'est un algo ou tous les temps sont bornés.
Il utilise Baker semble-t'il (merde, je sais jamais écrire cet idiome), c'est un système où la mémoire est coupée en 2 espaces, et on copie les objet vivant d'un espace à l'autre en laissant les cadavres derrière. C'est plus compliqué que ça donc me parle pas de consomation mémoire, on utilise pas ça tout seul.
Comme j'ai la flemme de lire, j'en parlerais pas plus.
-1, on est loin d'Eiffel là
[^] # Re: GC temps-réel
Posté par Moby-Dik . Évalué à -1.
[^] # Re: GC temps-réel
Posté par Dugland Bob . Évalué à 1.
Pour les contraintes sur la mémoire, un mark-and-sweep de base consome peu.
Le comptage de référence est une fausse-bonne idée (un antipattern ? :-) ) car il faut lui ajouter un détecteur de cylces qui est souvent (tout le temps, flemme de réfléchir) un marqueur, donc autant tout faire avec le marqueur. On peut prévoir le marquage dans les objets, ainsi, on alloue pas de table de marquage.
PocketSmalltalk, pour pas se faire chier, utilise une table d'objets et un mark-and-compact brutal, en changant le pointeur dans la table d'objets après le déplacement de l'objet. Un ami m'a dit que'un simple Baker (mémoire coupée en 2) avec pointeurs directs prenait moins de place (car la table des objets bouffe une tonne de mémoire) mais j'ai pas testé.
[^] # Re: Eiffel
Posté par Christian Couder (site web personnel) . Évalué à 3.
> Super. Et pour les performances, c'est comment ?
D'abord tu peux compiler tes programmes sans GC et gérer la mémoire toi meme.
Ou alors tu compiles avec le GC et tu utilises les instructions qui le désactivent dans les zones ou les périodes critiques.
Tu peux aussi spécififier certains paramètres pour que par exemple le GC ne se déclanche qu'à partir d'un certain niveau de mémoire utilisé.
[^] # oups
Posté par Moby-Dik . Évalué à -10.
Ah, ok, j'avais pas vu la signature... Au temps pour moi.
[^] # Re: oups
Posté par DiZ . Évalué à 0.
[^] # Re: Eiffel
Posté par Sylvestre Ledru (site web personnel) . Évalué à -3.
Si le Cobol reste le langue employé dans la plupart des banques et administrations au niveau des mainframes, je suis pas certain que ca soit uniquement parce qu'ils n'ont pas les connaissances pour passer à autre chose.
C'est sans doute parce que le Cobol a des avantages propres non ? :)
[^] # Re: Eiffel
Posté par nodens . Évalué à 7.
[^] # Re: Eiffel
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -4.
[^] # Re: Eiffel
Posté par mickabouille . Évalué à 1.
Pour le C, je m'en fout. Mais point de vue dinosaure sous perfusion, le pire, c'est la quantité de code fortran qu'il peut rester.
[^] # Re: Eiffel
Posté par Dugland Bob . Évalué à 5.
Sauf que la sécurité, tu te la mets profond, sans typage fort statique.
Je pense qu'il peut être pas mal à faire apprendre aux étudiants car il permet d'illustrer la notion de contrat.
J'étudie actuellement XDR (le machin utilisé pour communiquer sur les réseaux hétérogènes) et je peux te dire que c'est la merde, t'as des pointeurs dans tous les sens et t'as aucune doc sur les effets de bord.
Je pense que ça fait partie des apprentissages qui feront de toi un développeur meilleur dans les autres langages.
Bon la réalité c'est qu'à part lire des trucs dessus, j'ai jamais compilé une ligne avec. Mais je lis Meyer :-)
[^] # Re: Eiffel
Posté par AnneDeMontMorency . Évalué à 8.
Le langage Ada aussi a été conçu par un français (Jean Ichbiah). Je vous conseille d'aller jeter un coup d'oeil à cette petite histoire d'Ada :
http://www.cs.fit.edu/~ryan/ada/ada-hist.html(...)
# En entreprise !
Posté par Philip Marlowe . Évalué à 6.
Contexte : contrôle d'automates et de robots, vision industrielle (discrimination de séquences ADN). Des programmes développés auparavant en C puis "modernisés avec MS Visual C++. D
es cartes d'axes manipulées par le biais d'appel à des DLL, ce qui nous coince sous Windows pour l'instant.
Nous avons choisi ISE Eiffel pour deux raisons principales : l'existence d'un environnement de développement intégré, adapté au paradigme objet (navigation dans les classes, facilités de débogage, de configuration), et la possibilité de faire du multithreading (ce que SmallEiffel ne proposait pas à l'époque, mais je ne crois pas que cela ait changé).
Nous avons eu à construire une machine pour un client, ainsi que son logiciel de contrôle par un PC. Matériel industriel : carte d'axes pour un petit robot manipulateur 2 axe, carte d'entrées sorties, contrôle en parallèle de plusieurs process simultanés. Un "expert" consultant devait nous produire ce logiciel. Il a envisagé plusieurs solutions, dont l'utilisation de C# et de .NET, ce qui m'a semblé complètement aberrant. Au bout de deux mois sur les quatre dont nous disposions, il n'avait toujours rien produit. Un de mes collègues, avec une relativement faible expérience d'Eiffel, a produit le programme dans les deux mois qui restaient. Après une période de mise au point d'une semaine in situ , tout fonctionne à la satifaction du client. La suite dans le post suivant, car il semble que je sois en présence d'un bogue, de Galeon ou de DaCode, je ne peux plus passer à la ligne.
[^] # Re: En entreprise ! (suite)
Posté par Philip Marlowe . Évalué à 4.
1- en ce qui concerne le compilateur en lui-même, la gestion du multitâche, par les threads ou par un autre moyen. Il est à noter que l'adjonction du parallélisme et de la concurrence dans la deuxième définition du langage par Bertrand Meyer (Object Oriented Software Conception 2 : traduction française "Conception et programmation orientées objet", éditions Eyrolles, ISBN 2-212-09111-7), par la simple adjonction d'un seul mot réservé supplémentaire : separate ainsi que d'une description des moyens utilisés pour produire le parallélisme, un peu à la manière du Langage d'Assemblage de Classes Eiffel, ne soit pour le moment implémentée dans aucun compilateur Eiffel.2- un environnement de développement intégré qui autorise un bon confort de travail (complétion automatique, navigation dans les classes, vues spécialisées directes du code (short, flat) sans nécessité de produire des fichiers supplémentaires avec des outils annexes). Bon, ça va paraître décousu, mais de nouveau je ne peux pas passer à la ligne, donc à suivre ...
[^] # Re: En entreprise ! (suite) (suite)
Posté par Philip Marlowe . Évalué à 6.
Eiffel est utilisé en entreprise, avec succès. Pas seulement là où je travaille, mais aussi dans d'autres PME (imprimantes chez Hewlett Packard, joint venture entre la banque Lazard et le Crédit Agricole ...).
Pour reprendre une remarque qui m'avait été précédemment adressée, dans une autre news concernant Eiffel, s'il existe dans le monde trois programmeurs Eiffel, j'aimerais connaître le troisième, là où je bosse on est déjà deux.
La question de la pureté objet d'un langage, que j'ai pu lire dans certains commentaires me semble une question théologique . Il vaudrait mieux parler de la cohérence de la chose.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.