Quoting ayoul@???:
:Jusqu'à présent, je n'ai encore jamais entendu parler d'application
:industrielle de Eiffel (pas assez proche de la machine -> difficile de
:faire des logiciels performants). Mais comme tu semble bien connaitre
:ce langage, un éclairage de lanterne serait le bienvenu.
On sort totalement du domaine de cette mailing list. Ce sera mon dernier
message public sur le sujet.
Neanmoins, tu poses deux importantes questions.
1. Eiffel est-il utilise industriellement, et si oui, par qui?
2. Eiffel n'est pas assez proche de la machine, donc pas efficace.
Je reponds brievement:
1. Oui! Le moteur de rendering des figures geometriques sur les imprimantes
laser HP est ecrit partiellement en Eiffel. C'est sur, personne ne le sait,
mais il n'y a aucun interet marketing a ce que cela se sache.
De grandes banques utilisent aussi Eiffel pour leur logiciels financiers.
La encore, ce ne sont pas des produits grand public, donc cela ne se sait
pas forcement.
2. C'est exactement l'argument que les opposants a "C" ont sorti. A l'epoque,
l'assembleur etait sacro-saint, et imaginer de laisser au compilateur C
le soin de generer le code, qui serait bien entendu moins efficace que le
code fait "a la main", etait insupportable.
En general, un programme passe 80% de son temps dans 20% du code. Ce sont
ces 20% qu'il faut optimiser. En C par exemple... Il est trivial
d'encapsuler une routine C en Eiffel, et on lui donne une interface Eiffel
complete, avec pre-condition, post-condition, etc... Seul le corps de
la routine est en C.
:J'imagine que tu veux dire par là que Eiffel est une excellente école
:de programmation objet. Soit. Seulement la programmation
:"industrielle" ne se satisfait pas _que_ de la propreté du design. En
:pagaille: la performance, le temps de developpement, la
:maintenabilité, ... sont des critères qui ne sont pas toujours remplis
:avec un splendide modèle objet.
Tu as tout a fait raison sur les premisses, mais la conclusion est fausse.
Une architecture objet avec dynamic binding et polymorphisme est
diantrement plus efficace qu'une suite de tests en cascade. Par exemple,
le design du filesystem Unix avec VFS et les drivers UFS/NFS/CDFS, etc...
est assez oriente objet. Le filesystem est pourtant un composant crucial
dans un systeme Unix...
Penser objet veut dire assurer des criteres de robustesse, des interfaces
minimales avec un couplage faible, une maintenabilite accrue du fait de
la modularite, de l'encapsulation naturelle, et de l'heritage qui permet
de changer le comportement par endroits sans baver sur l'existant.
Bref, le logiciel devient un produit d'ingenierie et cesse d'etre une
production de "coin de table".
:L'approche de mon conseil consiste justement à donner une expérience
:sur un langage _utilisé_ dans l'industrie, afin d'avoir quelque chose
:de vendable dans son CV.
Mon precedent message etait volontairement dur. Mais neanmoins, je maintiens
qu'il faut avant tout etudier les disciplines fondamentales lorsqu'on est
etudiant, et que l'on est pret a apprendre. Ensuite, dans la vie active,
il est tres dur d'apprendre de nouveau concepts, car cela necessite une
remise en cause de certains acquis et convictions.
N'importe quel cretinoide de base peut programmer quelque chose en BASIC.
Mais ce quelque chose risque fort de ne pas etre de qualite industrielle
justement.
Alors qu'un ingenieur qui maitrise l'ensemble des techniques de programmation
saura "structurer" son code et son BASIC risque d'etre de fort bonne qualite.
