Philip Marlowe a écrit 1184 commentaires

NB : nota bene

Tu pourrais me traduire l'instruction suivante (syntaxe Eiffel) en syntaxe Ojective C ou SmallTalk ?
echantillon_courant := centri.nacelles.item (parcours.item (iteration).numero_nacelle).emplacements.item (parcours.item (iteration).numero_emplacement).element

Ensuite, je persiste, la maintenabilité, la clarté ne viennent pas du langage mais du programmeur.

Ah bon ? Je dirais que ça vient des deux, et qu'un langage favorisant la maintenabilité et la clarté du code aide tous les programmeurs dans ces domaines, même ceux qui ne sont habituellement pas très inquiets de ce genre de choses. Bien sûr je peux me tromper.

Je pense que c'est à moi que tu réponds. Tu me donnes l'occasion de récapituler.

Merci de cette précision. J'ai cité ton nom parce que toi et Yeupou, dont je ne me souvenais pas sur l'instant du pseudo du moment, étiez les premiers participants à l'enfilade escamotée dont je me suis souvenu. Il m'a semblé que prétendre que cette enfilade était uniquement composée d'échanges entre l'auteur de la dépêche et des modérateurs de DLFP consistait à la présenter selon une certaine perspective, comme en quelque sorte une affaire interne au site, ce qui dans tous les cas est faux. Je me suis tout de même enquis à ce sujet. Ton intervention était d'expliquer calmement à l'auteur, littéralement hors de lui et extrêmement virulent envers ses interlocuteurs, que les normes et les standards étaient choses nécessaires et importantes pour les logiciels libres. C'est peut-être à ce moment qu'il a compris l'énormité des diatribes qu"il venait d'écrire, ce qui l'a poussé non pas à se calmer, mais vers le comportement encore plus extrême d'en effacer les traces.

Il me semblait intéressant que quelqu'un qui propose une nouvelle sur un appel de Richard Stallman, avec une bonne traduction de celui-ci sur son site personnel, par ailleurs agréable à lire et aimablement présenté, ne comprenne pas par ailleurs l'importance des normes et se laisse aller à un comportement agressif et insultant envers ceux qui lui font remarquer le problème, était une chose intéressante. Au moment où l'enfilade a été supprimée, il n'y avait plus à ma connaissance de contribution active ; les choses avaient été dites. Que l'auteur ait voulu supprimer les traces de ces échanges est compréhensible. Que les responsables de DLFP aient accédé à cette requête ne l'est pas.

Il est absurde d'invoquer la loi Informatique et Libertés ou la responsabilité des hébergeurs pour justifier cette censure. L'auteur n'a été en aucun cas calomnié ou diffamé, et ses propres propos sont de sa propre responsabilité. Ce site est en grande partie constitué des commentaires des différents participants, qui se transmutent ce faisant, et même si ce n'est pas toujours dans le sens voulu au départ par ses auteurs, en information. Supprimer des commentaires pour une autre raison qu'une des raisons légales, par exemple des propos racistes ou de la diffamation, c'est supprimer de l'information, c'est faire acte de censure. Prétendre qu'un événement qui s'est effectivement déroulé n'a pas eu lieu en l'occultant me rappelle les méthodes staliniennes à ce point de vue, même si les conséquences en matière de santé publiques sont moins graves... Je n'aurais pas dû lâcher cet adjectif, qui a fourni un échappatoire commode et décentré le débat. Tu évoques de nouveau l'affaire Martin Winckler dans une autre nouvelle et je ne vois pas, quant au geste, de différence de nature entre le travail de nettoyage qu'il y a au lieu sur le site de France Inter après l'affaire Winckler et le travail de nettoyage qui a eu lieu sur ce site.

Il n'était en outre pas besoin d'en appeler au petit père des peuples pour situer ce genre d'actes et la désinformation qui va avec. Nos démocraties libérales avancées en sont tout aussi capables. Pour rester sur France Inter, lors de l'interdiction du livre du Docteur Gubler, qui expliquait comment on avait menti délibérément sur l'état de santé d'un président de la République, des "experts" et des "spécialistes" avaient suavement expliqué au brave public, lors d'une émission du genre "le téléphone sonne", que cette interdiction était de nature tout-à-fait exceptionnelle, et la première depuis longtemps. Au même moment, quelqu'un comme moi doté d'une mémoire très moyenne se souvenait d'au moins deux interdictions notoires : Affaires Africaines de Pierre Péan et Suicide mode d'emploi. On pourrait discuter à l'envi des motifs moraux invoqués quant au second.

Benoît Sibaud s'est laissé aller à littéralement traîner dans la boue Yeupou dont le seul tort avait été de remarquer une anomalie et d'en avertir autrui. Je trouve par ailleurs pertinent de signaler un forfait à l"endroit même où il s'est perpétré.

Quand on s'intéresse aux logiciels libres en France, on tombe forcément un jour sur ton nom. Ton activité est notoire et positive. Pour ma part ma principale contribution est de faire du prosélytisme pour les LL et d'aider les gens qui me le demandent. J'ai quatre enfants, tous en âge scolaire, et j'ai été impliqué jusque récemment dans le milieu associatif, en l'occurence la gestion d'une cantine scolaire (qui présente d'ailleurs des similitudes avec la défense des logiciels libres mais c'est une autre histoire) ; je n'exclus toutefois pas totalement de m'impliquer plus dans le domaine.

J'ai moi-même à certains moments raconté des bêtises, en particulier là où je parle de censure à cause de moinssages. Je ne demande pas pour autant que ces commentaires soient supprimés... Le fait que cette enfilade pollue une nouvelle sur un appel de RMS contre les brevets logiciels est bien sûr regrettable.

J'oubliais l'identité classe/type/module/fichier.

Je suis pour faciliter la vie des développeurs (donc au détriment du ou des concepteurs de langages). Malheureusement, c'est souvent l'inverse que l'on observe : le concepteur qui facilite sa vie au détriment du développeur qui doit utiliser son langage.

Ca fait du bien de lire ça. Je n'envie pas les programmeurs en Java ou en C#. Design By Contract, héritage y-compris multiple et même répété (comprenant l'héritage dit en diamant, mais pas seulement), généricité, le tout accessible avec une syntaxe claire, une fois qu'on y a goûté c'est difficile de revenir en arrière. Si je dois un jour passer au C# ou à Java, je sens que je vais souffrir...

Il y a un mécanisme appelé par le mot-clef external qui permet de réutiliser du code écrit dans un autre langage. J'ai déjà ainsi recyclé du code C en l'encapsulant dans du code Eiffel. Ca fonctionne bien et c'est facile à utiliser. Ca marche aussi pour le C++ et, je crois, le Fortran.

Et comme il s'agit de matrices à coefficients entiers, on ne se posera pas la question de les inverser.

Je ne suis pas sûr que la structure de données de genre tableau double de valeurs de taille 1000 par 1000 ait besoin de toutes les propriétés d'une matrice de taille équivalente, et que le choix de l'implémenter sous forme d'un objet de type matrice soit particulièrement judicieux. Jusqu'ici on parlait de matrices au sens mathématique.

Changer une seule valeur à une matrice peut la rendre ou non inversible.

A quoi peuvent bien servir des matrices ? A changer leurs coefficients ? Ou faire des calculs avec ?

Ok ça marche. Le problème c'est que tu fais tout ça pour vérifier si ton flag est cohérent avec le fait que la matrice est inversible. Le client va scruter si l'inversion est réussie en allant voir l'implémentation du flag. C'est beaucoup plus simple de voir si l'inversion de matrice retourne ou non Void, et ça répond directement à la question. Moins il y a de code mieux on se porte.

Oulà ! j'avais mal regardé. Ton invariant est complètement extravagant. Déjà le fait de ne pas être inversible pour une matrice déclenche une exception. Tu n'aimes pas la singularité ! Tu codes ensuite if m.inversion_reussie then que je traduis par : s'il ne s'est pas produit d'exception... De toutes façon ce code ne sera jamais exécuté car la simple crétion d'une matrice, même inversible, va engendrer une exception.

Ensuite il y a un autre critère de qualité qui s'appelle le masquage d'information. Les clients ne doivent pas avoir accès à l'implémentation de la classe.

Tu es passé d'une fonction à une procédure... Sinon ton point de vue est pertinent. Pour utiliser mon code, c'est un tout petit peu plus simple.

x:= m.inverse
if x /= Void then traitement normal
else traitement de l'erreur
end

il faudrait alors mettre à jour ce drapeau dès que l'on modifie une valeur de la matrice
Là je ne suis pas d'accord. C'est un des principes de la conception à objets que de ne pas modifier ceux-ci de manière intempestive. Si tu as besoin de modifier des coefficients de la matrice, il faut en créer une autre !

On ne m'a pas rattrappé par les bretelles... Il vaut mieux éviter de tenter d'inverser plusieurs fois une matrice qui ne peut pas l'être, d'accord, mais calculer plusieurs fois le résultat de l'inversion quand cela a déjà été fait une fois ne vaut guère mieux.

On peut donc ajouter un attribut non visible, par exemple resultat_inversion: MATRICE.

on peut modifier le corps de la routine par
require [...]
do
if already_tried then
Result := resultat_inversion -- si ça a foiré précédemment resultat_inversion = Void
else
Result := un_calcul_compliqué
resultat_inversion := Result
already_tried := True
ensure [...]
rescue[...]
end

La clause d'exception permet d'effectuer un_calcul_compliqué sans filet (un des risques est de tenter de faire une division par zéro). Il va de soi qu'il est possible de faire autrement.

On peut même améliorer les choses en déclarant already_tried comme attribut plutôt que comme variable interne à la routine et éviter ainsi de tenter d'inverser plusieurs fois une matrice qui ne peut pas l'être.

A remplacer : dans le sens de la routine par au sens de la routine.

Je suis d'accord avec tes objections, cependant même en Eiffel on est parfois astreints à des impératifs d'efficacité. Ton code présente bien l'utilisation des assertions mais avec un mauvais exemple.

D'abord la vérification de la non singularité de la matrice par le calcul de son déterminant, ou par la méthode de Gauss implique un volume de calcul du même ordre que l'inversion proprement dite.

La postcondition souffre de quelques lacunes aussi. Déjà avec un x: DOUBLE différent de zéro, x * 1/x = 1 n'est pas toujours vrai. Il va donc plutôt falloir trouver un autre critère comme, par exemple, calculer la norme de la différence entre le produit de la matrice par son inverse et l'identité, et vérifier qu'elle est inférieure à une certaine tolérance.

je propose donc le code suivant comme exemple amélioré (à ne pas considérer comme étant taillé dans le bronze) :

inverse: MATRICE is

require

is_square -- on ne traite pas les pseudo inverses

local

already_tried: BOOLEAN

do

if already_tried then

-- Result := Void ceci est un commentaire

else


--code de tentative d'inversion de la matrice

end

ensure

Current = Void or else (Current * Result).distance (identity) < epsilon -- epsilon attribut de la classe

rescue

already_tried := True

retry


end

En procédant de cette manière on va obtenir une approximation de l'inverse de la matrice si la matrice n'est pas singulière et que le code le permet et un objet vide dans les autres cas. L'avantage c'est que si la matrice n'est pas inversible dans le sens de la routine (ce qui ne veut pas dire qu'elle ne l'est pas mathématiquement), l'objet retourné sera vide, ce qui décharge le client de lourdes vérifications.

Un exemple est donné, tourné autrement, dans Conception et programmation orientées objet de Bertrand Meyer, pages 771 et 772.

Pendant que j'y suis. Ce n'est pas une perte de temps d'essayer la version gratuite de EiffelStudio, actuellement en version 5.5. Il y a un formulaire à remplir pour y accéder, mais l'accès direct est ici : ftp://ftp.eiffel.com/pub/downloads/(...) et on y trouve les exécutables pour Linux, Solaris et Windows. Je sais, c'est propriétaire, mais voir à quoi ça ressemble et comment ça marche ne rendra personne idiot. Ca peut même donner des idées.

ISE was privileged to be one of the outside language providers selected, more than a year before the first official announcement of .NET [...]
Tu as raison. On leur a demandé de collaborer pour fournir un langage externe ayant .NET comme cible.

Oups ! C'est à Philippe Piette ci-dessous que je voulais répondre.

http://www.google.fr/search?q=cache:PFejj65lq4MJ:archive.eiffel.com(...)
C'est en cache de Google, l'original n'est plus disponible, peut-être à cause de son caractère polémique, en particulier à l'encontre d'un certain Bob Metcalfe.

Ce qui est amusant c'est que la routine d'inversion de matrice montrée en exemple n'est justement pas le meilleur exemple pour l'utilisation des assertions, surtout de la précondition. Vérifier qu'une matrice est inversible prend autant de temps que de l'inverser, ce qui fait qu'en l'occurence on choisira plutôt de traiter le problème en utilisant la gestion des exceptions avec une clause rescue.

Les pré et postconditions sont abandonnées sur les exécutables finaux, ce qui fait qu'un programme mis au point avec la précondition indiquée va mettre des contraintes énormes sur les clients de la routine d'inversion de matrice en les obligeant à prendre à leur charge la vérification préalable de l'inversibilité de la matrice passée en argument, sauf dans le cas qui me semble douteux où une preuve de l'inversibilité des matrices passées en argument serait préalablement apportée.

C'est un peu du pinaillage que je fais là mais j'aime autant prendre les devants plutôt que de voir quelqu'un affirmer "Eiffel ça vaut rien d'ailleurs ça se voit bien sur l'exemple".

Ce n'est pas si simple. Au niveau du langage, l'histoire de l'insert est la seule qui me vient en tête. Par contre c'est au niveau des bibliothèques de base que se posent les problèmes.

Pour apprendre les bases du langage toutes les implémentations se valent. Pour la partie apprentissage des bibliothèques le problème se pose. Pour adapter un projet écrit avec un compilateur sur un autre, ça se complique sérieusement.

Les autres acteurs du monde Eiffel se plaignent du manque de respect des standards du genre par l'équipe de SmartEiffel. Par exemple l'héritage non conforme est déclaré avec le nouveau mot-clef insert. Les récentes versions d'EiffelStudio utilisent le mot-clef déjà existant expanded. SmartEiffel pose beaucoup de problèmes à GoboSoft, fondé par Eric Bezault http://www.gobosoft.com/(...) qui propose des bibliothèques compatibles avec le plus de compilateurs Eiffel possible (il n'y en a pas tant : de mémoire, SmartEiffel, EiffelStudio de Eiffel Software http://www.eiffel.com/(...) et Visual Eiffel d'Object Tools http://www.object-tools.com/(...) Halstenbach semble ne plus exister).

Pour ce qui est justement de la définition des standards, qui au départ devait être assurée par NICE (Nonprofit International Consortium For Eiffel http://www.eiffel-nice.org/(...) , elle semble maintenant dévolue à l'ECMA. I ya eu quelques discussions un peu chaudes à ce sujet sur les mailing lists Eiffel.

J'utilise Eiffel au travail (environnement propriétaire EiffelStudio sous Windows, il en existe aussi une version GTK2 sous Linux), et cela a beaucoup influencé ma manière de concevoir (cela n'est cependant pas ma spécialité). J'aurais du mal à me passer de la Programmation par Contrats et de l'héritage multiple, ainsi que du confort de l'environnement de programmation proposé par EiffelStudio. A ce propos, y a-t-il des gens qui le connaissent et qui, pratiquant d'autres EDI avec d'autres langages, seraient à même de comparer ? Cela m'intéresserait.

Ce qui est complètement invraisemblable, c'est que Microsoft produise quoi que ce soit d'important sous licence GPL. Ils n'ont jamais perdu une occasion de la dénigrer, et pour cause, elle contrevient totalement à leurs intérêts.

Pardonne-moi d'avoir blasphémé.