Sortie de Hercule la version 2 du compilateur SmartEiffel

Posté par jcs (site web personnel) le 29 septembre 2004 à 19:04. Modéré par rootix.

Étiquettes :

sept.

2004

Après deux release candidate cet été et deux versions beta depuis début Septembre, la version 2.0 de SmartEiffel (ex SmallEiffel), le compilateur GNU multi-plateformes pour le langage Eiffel, est sortie. Le compilateur apporte de nombreuses améliorations et de nouvelles fonctionnalités telles que la bibliothèque graphique Vision ou l'héritage non-conforme.
SmartEiffel est développé au LORIA à Nancy. Le langage Eiffel :

Le langage Eiffel est un langage objet conçu par Bertrand Meyer. Il est entièrement objet (sans notion de type primitif) et inspiré de Smalltalk. Il possède de nombreuses fonctionnalités telles que l'héritage multiple, la programmation par contrat ou la généricité. Il possède aussi un garbage collector intégré. Si sa syntaxe peut paraître déroutante au premier abord c'est un langage intéressant à connaître et particulièrement adapté à l'apprentissage.

Le compilateur :

Depuis la sortie de la version 1.1 il y a un an, les améliorations sont nombreuses. Parmi les plus importantes on trouve :
- révision de l'architecture du compilateur pour implémenter l'héritage non-conforme (héritage de l'implémentation mais pas du type)
- vision : une bibliothèque graphique. Le code écrit avec Vision est portable sous X et Windows. On est encore loin de GTK ou Qt mais c'est un début. Vision utilise intensivement les mécanismes des agents apparus dans la version -0.74 de SmallEiffel
- implémentation du design pattern Visitor
- amélioration du débugger

Toutes les améliorations, nouvelles fonctionnalités, et corrections de bugs se trouvent dans le changelog.

Aller plus loin

SmartEiffel (2 clics)
Téléchargement (1 clic)
Le changelog (0 clic)
Le langage Eiffel (1 clic)

# -1

Posté par Roger Rabbit le 29 septembre 2004 à 20:34. Évalué à -3.

"Non hercule n'y pas"

--

[ Cf. la blague du poète errant ]
# Quelques "coquilles"

Posté par thecat le 29 septembre 2004 à 20:44. Évalué à 9.

Meier -> Meyer

(sans notion de type primitif)
Cette affirmation est trés disuctable car les types expansés on pour principale raison d'étres l'implémentation de ces types primitif. Disons plutot que les type primitifs sont trés biens intégré en Eiffel, pas comme dans d'autres langages.

et inspiré de Smalltalk
Alors la j'aimerais bien avoir un lien car Eiffel est :
-un langage dont toutes les implémentation propose sont des compilateurs
-un langage à typage statique
-un lanage à héritage multiple
-un langage ne proposant pas de meta-niveau ni d'introspection
-un langage ayant une syntaxe vraiment propre
Donc il est inspiré de trés loin non?

Au sujet de l'héritage non-conforme, il a était introduit en partie pour résoudre les problèmes lié à l'héritage multiple. L'ancien mécanisme pour gérer c'est problèmes, le mot clef "select" était loins d'etres parfait. Malheureusement cela n'est génial:
D'une part il ne résoud pas tous le problèmes (voir la mailling list de SmartEifel) mais en plus ca casse un ensemble de bibliothèque qui éxistait déja et surtout ce n'est pas une feature standardisé!
L'équipe de SmartEiffel implémente des concepts qui anticipent la future version de Eiffel (la version 3). Même si je comprend que les devs se font plaisirs et veulent avancer, le problème est que le langage Eiffel n'arrivera jamais à surmonter les péchers de jeunesse qu'il avait : pas de norme officielle, des implémentation toutes incompatibles les unes avec les autres, un ensemble de bibliothèques réduites (et pour cause! a chaque version il faut les revoir!) et du coup un nombre d'applications utilisables plutot léger.
Eiffel est un super langage et SmartEiffel un compilo plutot efficace mais je pense qu'ils aurrait plutot dut implémenter les réels manque du langage (suport de la concurence et du chargement dynamique de classe) plutot que d'anticiper une future norme qui n'arrivera pas avant des années!
- [^] # Re: Quelques "coquilles"
  
  Posté par reno le 29 septembre 2004 à 21:12. Évalué à 5.
  
  >Au sujet de l'héritage non-conforme, il a était introduit en partie pour résoudre les problèmes lié à l'héritage multiple.
  > L'ancien mécanisme pour gérer c'est problèmes, le mot clef "select" était loin d'etre parfait.
  
  Tu peux préciser ce qu'est le select? Je ne le trouve pas dans mon (vieux) livre..
  
  Après avoir appris la notion de "programmation objet" en lisant les livres de B. Meyer, j'avais tendance à considérer que la façon de faire l'héritage multiple en Eiffel comme une solution qui avait l'air élégante: en cas d'héritage multiple "en diamant", il faut renommer au moins une méthode dupliquée pour éviter les conflits et on peut choisir de reimplementer la méthode.
  
  Pour ce qui est de la concurrence, en 93 Meyer étudiait une proposition, apparemment cela ne progresse pas vite!
  - [^] # Re: Quelques "coquilles"
    
    Posté par reno le 30 septembre 2004 à 09:34. Évalué à 4.
    
    OK j'ai trouv'e le select (en cas de conflit on peut choisir de quel pere on herite un element) mais tu peux preciser quels sont les problemes dont tu parles li'es a l'heritage multiple?
    
    J'ai deja utilis'e l'heritage multiple en C++ sans probleme particulier et comme Eiffel impose la resolution des conflits, cela me semblait encore plus propre..
    
    Je suis curieux de savoir quels sont les problemes qui apparaissent en pratique ..
    - [^] # Re: Quelques "coquilles"
      
      Posté par thecat le 30 septembre 2004 à 11:27. Évalué à 2.
      
      J'ai deja utilis'e l'heritage multiple en C++ sans probleme particulier
      Car on utilise l'héritage multiple en C++ de manière beaucoup moins intensive qu'en Eiffel: Et pour cause! il n'y a aucun moyen de résoudre les conflits. Mais le problème classique du "diamand" en C++ est insoluble.
      
      Je suis curieux de savoir quels sont les problemes qui apparaissent en pratique
      lit ce mesage et les suivants (mailling liste de SmartEiffel).
      http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2004-09/msg00167.ht(...)
      - [^] # Re: Quelques "coquilles"
        
        Posté par reno le 30 septembre 2004 à 21:43. Évalué à 2.
        
        Euh merci pour le lien (le machin anti-spam est buggé et m'a perdu 5 minutes, mais j'ai fini par retrouver le bon message), mais j'avoue n'avoir pas tout compris, si ce n'est que la sémantique derriere a l'air puissante mais horriblement compliquée!!
        
        Ca fait quand même très "usine à gaz" toutes ces règles complexes de sémantique..
- [^] # Re: Quelques "coquilles"
  
  Posté par Sébastien Douche le 29 septembre 2004 à 22:37. Évalué à 9.
  
  > Donc il est inspiré de trés loin non?
  
  Disons que Smalltalk est un des langages que Meyer s'est inspiré. Plusieurs points qui me semblent intéressant sur Eiffel :
  
  - Le créateur, B. Meyer est un ancien élève de l'école polytechnique et de l'ENST, ancien prof et fondateur de revue technique, ... Un homme que je trouve personnellement intéressant.
  
  - B. Meyer à étudié la programmation objet pendant des années. Je vous invite fortement à lire ses livres si vous êtes intéressé par le sujet (dont le volumineux (1300 pages) "Conception et programmation orientée objets" qui est pour moi une bible sur le sujet).
  
  - Le langage est donc le fruit d'un intense travail, avec un but : un langage dédié à l'analyse, la conception et la réalisation. C'est à dire capable de gérer de bout en bout le processus de développement logiciel; et des objectifs clairs : concision, esthétique, réutilisabilité, extensibilité, fiabilité, effficacité, ouverture, portabilité.
  
  - Inspiré de plusieurs langages : smalltalk pour le coté objet, le langage Z pour son formaliste (spécification), de Simula 67, d'Algol, de CLU, d'Ada , ...
  
  - La programmation par contrat. Pour moi une idée génialissime, que les méthodes agiles avec la programmation conduit par les tests approchent de loin pour l'efficacité.
  
  - Et pour valider ses idées, il a monté une boite, créé un compilateur. Ses clients sont principalement dans des domaines ou l'efficacité est primordiale (banque, assurance, transport, ...).
  
  Bref, plus qu'un langage, Eiffel est une méthode de pensé. La lecture des livres de Meyer ne vous apportent pas que des techniques de programmation mais une vision complète de la conception et du développement. C'est à ce titre que je trouve ses livres des plus intéressants. Et pour ne rien gaché, il écrit trés bien. Ses livres sont clairs, abondamment commentés dans ses choix, avec une double lecture, et fort bien documentés. Bref, pour moi un vrai régal. J'invite tout ceux qui aiment ce domaine de lire le livre cité plus haut ...
  
  Bref un tableau presque idilique si ce langage était beaucoup utilisé, mais ce n'est pas le cas :/ Une vision plus Open Source dans son développement aurait amha été bénéfique ...
  - [^] # Re: Quelques "coquilles"
    
    Posté par Guillaume Vauvert (site web personnel) le 30 septembre 2004 à 12:36. Évalué à 8.
    Je trouve également que ce langage très agréable : tout est propre, bien pensé. La programmation par contrat, pour ceux qui ne connaissent pas consiste à considérer que l'utilisation de chaque méthode est soumise à un contrat : si l'utilisateur de la méthode respecte certaines contraintes (le préconditions, ou require), alors, moi, concepteur de la méthode, je lui garantis un certain résultat (les post-conditions, ou ensure). Exemple de code dans la classe matrice :
```
inverse : MATRICE is                                       -- nom_de_fonction : type_renvoyé

    -- Renvoie l'inverse la matrice                     -- commentaire

  require                                                          -- zone preconditions

    is_inversible                                                -- fonction booléenne qui teste si la matrice est inversible

  do                                                                  -- begin ou {

    ...                                                                 -- code : peu timporte, ce qui compte, c'est le contrat

  ensure                                                           -- zone postconditions

    Current x Result = Identite                          -- Current = object courant; x = opérateur infixe de multiplication de matrices;

                                                                         -- Result = objet résultat dans le cas d'une fonction

                                                                         -- Identite = Object défini une seule fois comme étant la matrice identité

  end                                                                 -- end ou }
```
    Comme vous le voyez, ces contraintes sont écrites dans le langages lui-même, et, plus fort, ces contraintes peuvent être vérifiées à l'exécution ! Dès qu'une pré ou postcondition est violée, le programme s'arrête et signale la violation. Les bogues sont donc détectés le plus tôt possible.
    Il existe aussi les invariants qui permettent de spécifier des contraintes toujours vraies. Ex : dans la classe COMPLEXE :
```
  invariant

    Re = module * cos(argument) and Im = modules * sin(argument).
```
    Au département d'informatique de l'université Paris 13 (pour l'enseignement donc), nous avons choisi de nous inspirer de la méthode Eiffel pour les cours de programmation objet. Malheuresement, la "mode" et les contraintes horaires nous obligent à voir la pratique en Java. Nous utilisons cependant des extensions à Java qui permettent d'inclure des pré- et post-condition et invariants dans les commentaires sous forme de tags, et de les vérifier à l'exécution. Il existe plusieurs solutions, avec chacune ses avantages, au niveau de la précompilation et de la gestion de la documentation :
    jContract
    iContract
    Jass
    Jcontract
    JMSAssert
    jassert
    Handshake
    Java Modeling Language (JML) - un peu différent, mais même esprit
    - [^] # Re: Quelques "coquilles"
      
      Posté par Snark_Boojum le 30 septembre 2004 à 13:59. Évalué à 5.
      
      Le point super important qui n'est pas précisé dans le long message précédent, c'est que les contraintes sont _héritées_!
      
      Cela signifie que si la classe MERE définit une méthode toto avec une précontrainte et une postcontrainte (elle peut faire ça: ne donner que le typage et les contraintes sans implémentation!), alors la classe FILLE aura une méthode toto avec a priori les mêmes contraintes automatiquement! Je dis "a priori", parce qu'évidemment, la fille peut affaiblir les précontraintes et renforcer les postcontraintes.
      
      Bref, effectivement on peut faire des contraintes avec un paquet d'autres langages, mais le fait qu'elles soient héritées est ce qui rend les choses carrément plus intéressantes.
      
      Snark
    - [^] # Re: Quelques "coquilles"
      
      Posté par Philip Marlowe le 30 septembre 2004 à 14:38. Évalué à 4.
      
      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".
      - [^] # Re: Quelques "coquilles"
        
        Posté par Guillaume Vauvert (site web personnel) le 30 septembre 2004 à 21:46. Évalué à 3.
        
        Je ne suis pas d'accord :
        1) méthodologiquement, les exceptions sont destinées aux erreurs que l'on ne maitrise pas, une condition anormale : réseau indisponible, saturation disque/mémoire, faute matérielle ... générer une exception pour une impossibilité mathématique me semble déplacé.
        2) algorithmiquement, on peut s'en sortir comme avec la méthode "search" qui renvoie vrai ou faux si un élément existe dans un ensemble. si l'élément existe, la éthode "last_found" renvoit cet élément, sans avoir à relancer de recherche. Il existe une méthode d'inversion de matrice qui utilise le calcul de déterminant. Il suffirait de stocker le déterminant calculé lors de l'appel de est_inversible pour s'en servir lors de l'inversion de matrice.
        J'avoue ne pas avoir une grande expérience dans le développement concret d'applications, mais ma méthode me semble plus propre et plus proche de l'esprit des contrats.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 30 septembre 2004 à 23:58. Évalué à 0.
        
        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.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 00:30. Évalué à 0.
        
        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.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 08:36. Évalué à 0.
        
        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.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Guillaume Vauvert (site web personnel) le 01 octobre 2004 à 09:08. Évalué à 1.
        
        La première version que j'ai proposée utilise en effet un schéma a priori (on teste l'inversibilité avant), simple et clair. Je pense que cette version est correcte si le calcul d'inversion utilise le calcul du déterminant (par exemple avec A-1 = 1/det A * "transposée de la matrice des cofacteurs")
        Maintenant, si l'inversion n'utilise pas le déterminant (méthode de Gauss), l'inversibilité est découverte en cours de calcul. Un schéma a priori est alors effectivement dans ce cas plus indiqué (mais en général, le schéma a priori est plus propre). Le principe est le suivant : on tente l'inversion, et on positionne un drapeau selon la réussite ou l'échec de l'inversion. Le test se fait alors après la tentative.
        tente_d_inverser is require is_square -- on ne traite pas les pseudo inverses do -- code qui permet d'inverser la matrice -- si l'inversion est possible, inversion_reussie vaut True et inverse contient la matrice inverse -- si l'inversion n'est pas possible, inversion_reussie vaut False et inverse vaut Void ensure not inversion_reussie or else (Current * inverse).distance (identity) < epsilon -- epsilon attribut de la classe end inversion_reussie : BOOLEAN inverse : MATRICE invariant inversion_reussie = (inverse /= Void)
        Pour utiliser ce code, on ferait :
        ... m.tente_d_inverser if m.inversion_reussie then x := m.inverse ... else ... traitement de l'erreur ... end ...
        Remarques :
        
        je préfère ne pas utiliser de rescue, car il n'y a pas d'erreur imprévisible;
        
        on pourrait effectivement ajouter already_tried pour éviter de tenter d'inverser deux fois, mais il faudrait alors mettre à jour ce drapeau dès que l'on modifie une valeur de la matrice (mais le problème est différent);
        
        d'accord pour la post-condition qui spécifie que l'on a une matrice inversée, mais, ceci dit, mon égalité entre deux matrices (avec le signe =) pourrait être calculée comme toi en utilisant une distance et un epsilon.
        
        PT : j'espère que la discussion n'est pas trop technique et que tout le monde peut suivre.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 10:09. Évalué à 0.
        
        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 !
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Guillaume Vauvert (site web personnel) le 01 octobre 2004 à 11:43. Évalué à 1.
        
        Je ne connais pas ce principe de "non-modification intempestive".
        Vas-tu créer un matrice à chaque modificiation ? Dans certaines applications, cela peut se produire souvent et donc être très coûteux ! Ferais-tu de même avec un complexe ? L'état d'un objet est-il sensé rester stable ? Toute modification mineure de la matrice (une seule valeur) nécessite-t-elle la création d'une nouvelle matrice ?
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 14:42. Évalué à 0.
        
        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 ?
        
        [^] # Re: Quelques "coquilles"
        
        Posté par ZeGrunt le 01 octobre 2004 à 15:22. Évalué à 1.
        
        > Changer une seule valeur à une matrice peut la rendre ou non inversible.
        
        D'où l'idée de remettre le flag à false lors d'une modif.
        
        > A quoi peuvent bien servir des matrices ? A changer leurs coefficients ? Ou faire des calculs avec ?
        
        Les deux, mon capitaine.
        
        Imagine un programme qui fait du calcul de temps de trajet en train : la matrice représente le temps de trajet entre deux gares reliées directement sans passer dans une autre gare. Si jamais il y a une panne sur un tronçon et que j'ai 1000 gares, je fais quoi ? Je change une valeur de ma matrice ou je reconstruis une matrice 1000 par 1000 juste pour UNE valeur ? La réponse change-t-elle si on produit un soft pour de l'embarqué ?
        
        C'est comme d'habitude, chaque implémentation est adaptée à un cas, voir à une façon de coder.
        
        ZeGrunt.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 16:36. Évalué à -1.
        
        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.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par ZeGrunt le 01 octobre 2004 à 17:28. Évalué à 1.
        
        > 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.
        
        Ah bon ? Je n'ai rien vu de spécifiquement mathématique dans ce qui a été dit mais je n'ai peut-être rien compris...
        
        Quant à l'utilité d'une matrice dans le cas que je citais, oublions le temps et passons à l'accessibilité d'une gare. Si on considère que 0 correspond à "pas de lien direct" et 1 à "lien direct" au départ. Si mes souvenirs sont bons, le produit de cette matrice par elle-même donne les gares reliées entre elles via au plus une seule autre (celles pour lesquelles, l'intersection ne vaut pas 0). Elève la matrice au cube et ce sera les gares reliées entre elles via au plus 2 autres. Et ainsi de suite.
        
        ZeGrunt.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 18:17. Évalué à 0.
        
        Et comme il s'agit de matrices à coefficients entiers, on ne se posera pas la question de les inverser.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par ZeGrunt le 02 octobre 2004 à 09:39. Évalué à 1.
        
        Euh, je ne répondais pas forcément sur le problème d'inversion de matrice mais sur celui du changement de coef dans une matrice.
        
        Tu prétendais qu'à chaque changement de valeur, il fallait recréer une matrice. Je t'ai montré un cas où je pense que c'est inutile voir dommageable. C'est tout.
        
        Merci de ne pas perdre le fil (je sais, c'est difficile quand y'en a tant ;)).
        
        ZeGrunt.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 11:16. Évalué à 0.
        
        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.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Guillaume Vauvert (site web personnel) le 01 octobre 2004 à 11:58. Évalué à 1.
        
        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.
        Ah bon ? Je ne vois pas pourquoi ?
        L'invariant est : inversion_reussie = (inverse /= Void)
        À la création de la matrice : inversion_reussie = False et inverse = Void (ce sont les valeurs par défaut, que l'on peut de toutes façons modifiées dans la méthode de création). (inverse = Void)=True, donc (inverse /= Void) = False, donc (inverse /= Void) = inversion_reussie.
        Ensuite, après tentative d'inversion :
        - inversion réussie : inversion_reussie = True, inverse /= Void, et donc (inverse /= Void) = True
        - inversion échouée : inversion_reussie = False, inverse = Void et donc (inverse /= Void) = False
        
        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.
        Je ne vois pas en quoi les clients ont accès à l'implémentation de la classe. La post-condition [not inversion_reussie or else (Current * inverse).distance (identity) < epsilon] suffit à l'utilisateur de la classe pour comprendre comment utiliser les méthodes pour trouver l'inverse de la matrice. La partie implémentation, ce serait le code dans la méthode. Ce n'est pas parce que l'utilisation de la classe n'est pas conforme à la version mathématique, ou aux habitudes qu'il s'agit d'implémentation montrée.
        
        [^] # Re: Quelques "coquilles"
        
        Posté par Philip Marlowe le 01 octobre 2004 à 14:32. Évalué à 0.
        
        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.
- [^] # Re: Quelques "coquilles"
  
  Posté par Philip Marlowe le 30 septembre 2004 à 08:55. Évalué à 4.
  
  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.
  - [^] # Re: Quelques "coquilles"
    
    Posté par deftones_chris le 30 septembre 2004 à 10:35. Évalué à 4.
    
    Les autres acteurs du monde Eiffel se plaignent du manque de respect des standards du genre par l'équipe de SmartEiffel.
    En clair, si on désire apprendre ce langage de manière correcte, il vaut mieux se tourner vers EiffelStudio. Ai je bien compris ?
    - [^] # Re: Quelques "coquilles"
      
      Posté par Philip Marlowe le 30 septembre 2004 à 11:38. Évalué à 1.
      
      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.
    - [^] # Re: Quelques "coquilles"
      
      Posté par Philip Marlowe le 30 septembre 2004 à 19:00. Évalué à 1.
      
      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.
  - [^] # Re: Quelques "coquilles"
    
    Posté par Ontologia (site web personnel) le 02 octobre 2004 à 01:40. Évalué à 2.
    
    >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.
    
    windev ?
    
    ok, je ---> []
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# SmartEiffel#

Posté par Djax le 30 septembre 2004 à 03:07. Évalué à 1.

Est-ce qu'un SmartEiffel# est prévu pour être sur Mono au côté de C#?
- [^] # Re: SmartEiffel#
  
  Posté par Philip Marlowe le 30 septembre 2004 à 15:02. Évalué à 1.
  
  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.
  - [^] # Re: SmartEiffel#
    
    Posté par Philip Marlowe le 30 septembre 2004 à 15:04. Évalué à 0.
    
    Oups ! C'est à Philippe Piette ci-dessous que je voulais répondre.
# B. Meyer et .NET

Posté par Philippe Piette le 30 septembre 2004 à 14:03. Évalué à 3.

Je me suis laissé dire aussi que B. Meyer avait été un des principaux architectes de .NET... Malheureusement, je n'ai plus aucune idée de l'endroit où i'ai vu cela.

Je me rappelle qu'à l'époque, ayant été fortement impressionné par son bouquin sur la programmation orientée objet, m'être fait la réflexion que s'il avait vraiment participé à la conception de .NET, cet environnement de développement devait être quelque chose de solide et bien conçu et pas seulement un effet de mode.

Voilà et tant pis pour mes xp et le lynchage public.
- [^] # Re: B. Meyer et .NET
  
  Posté par Vivi (site web personnel) le 30 septembre 2004 à 15:05. Évalué à 3.
  
  Je me suis laissé dire aussi que B. Meyer avait été un des principaux architectes de .NET
  
  Tu confondrais pas avec Erik Meijer ? http://research.microsoft.com/~emeijer/(...)
  - [^] # Re: B. Meyer et .NET
    
    Posté par Philippe Piette le 30 septembre 2004 à 15:34. Évalué à 3.
    
    Tu confondrais pas avec Erik Meijer
    
    Que neni, jette un oeil sur le cache de google mentionné (par erreur) dans le thread du dessus!
    - [^] # Re: B. Meyer et .NET
      
      Posté par Vivi (site web personnel) le 30 septembre 2004 à 16:05. Évalué à 3.
      
      Ah ben justement, en lisant l'article j'ai plutôt l'impression qu'il n'a pas participé à la conception de .NET. Par ex:
      
      I mentioned above that I have my reservations about some of the aspects of the .NET model. Mostly, they follow from the observation that some decisions perpetuate misguided choices of the C-C++-Java line. This is the dominant line today, so it's not surprising that the designers of the framework should have retained a high degree of compatibility with it,
      - [^] # Re: B. Meyer et .NET
        
        Posté par Philip Marlowe le 30 septembre 2004 à 17:24. Évalué à 1.
        
        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.
# Le successeur de Eiffel

Posté par Ontologia (site web personnel) le 30 septembre 2004 à 17:41. Évalué à 2.

Lisaac : designé par B. Sonntag (grand amateur d'Eiffel) qui travaille dans le même labo que Dominique Colnet, le concepteur et mainteneur de SmartEiffel.
D. Colnet a d'ailleurs participé à la génèse de lisaac.

Lisaac. Langage objet à prototype, supression de la liaison dynamique (les appels de méthodes sur différents objets sont statiques : les solutions possibles sont analysés et le code contextuel généré).
Garbage Collector évidemment. Facilités pour la programmation système, programmation par contrat.

Multi héritage et surtout héritage dynamique à l'exécution.

L'avenir, quoi...

---> http://www.isaacos.com(...) section langage

Le compilateur est librement téléchargeable.

(oui je sais le site est pourri et incompréhensible, on me l'a déjà dit des centaines de fois)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.