[+] Mémoire

Eiffel

• [^]Re: Eiffel

  Posté par Lafrite () le 18/09/2002 à 20:45. (lien). Évalué à 4.

  On programme même des jeux en Eiffel :-)
  
  http://www.battlefront.com/products/stratcom/stratcom.html(...)
  
  Bien sympa comme petit wargame
  
  -1 car pub

• [^]Re: Eiffel

  Posté par Djax () le 18/09/2002 à 22:59. (lien). Évalué à 19.

  ... plus que Smalltalk ?
  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:
  

  • le multihéritage
  
  
  • le polymorphisme
  
  
  • le ramasse-miettes
  
  
  • la programmation par contrat ( avec ça,oui, on peut blinder son code contre les bugs)
  
  
  • la généricité
  
  
  • BON
  
  
  • lisibilité et propreté du langage
  
  
  • pas le lourd héritage d'un langage qui a été rendu objet
  
  
  • ...

  
  
  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 () le 18/09/2002 à 23:22. (lien). Évalué à -4.

    la programmation par contrat ( avec ça,oui, on peut blinder son code contre les bugs)
    
    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 () le 19/09/2002 à 01:32. (lien). Évalué à 11.

      Comme avec... les assert() en C.
      
      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 () le 19/09/2002 à 09:19. (lien). Évalué à 1.

        La programmation par contrat aurait évité l'explosion d'Ariane 5:
        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 () le 19/09/2002 à 10:27. (lien). Évalué à 8.

          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.
          
          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 (page perso, ) le 19/09/2002 à 10:46. (lien). Évalué à 2.

            J'attend toujours une vérification statique de ces contrats, ça fait partie des trucs dont il a été prouvé que c'est impossible ?
            
            Est-ce qu'il en fait au moins une partie à la compilation ?

    • [^]Re: Eiffel

      Posté par Dugland Bob (page perso, ) le 19/09/2002 à 08:37. (lien). Évalué à 12.

      le ramasse-miettes
      
      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 () le 19/09/2002 à 09:16. (lien). Évalué à 1.

        Et si je programme un service pour lequel j'ai des contraintes mémoire fortes, qu'est-ce que je fais ? J'utilise le GC au risque de voir la mémoire exploser parce que le dit GC (Garbage Collector) a une gestion trop "paresseuse" de la désallocation ? Tu as une solution ? Les spécifications du GC sont précises et garanties ?
        Ou peut-être que tu ne t'es pas "renseigné" sur le problème ;-))

        • [^]Re: Eiffel

          Posté par Dugland Bob (page perso, ) le 19/09/2002 à 09:55. (lien). Évalué à 5.

          je me suis renseigne sur le probleme (en fait je suis tombe dessus par hazar car je m'en fout).
          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 (page perso, ) le 19/09/2002 à 10:54. (lien). Évalué à 3.

          Tiens, j'ai cherché un peu :
          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 () le 19/09/2002 à 11:10. (lien). Évalué à -1.

            Ok, merci beaucoup :-)

          • [^]Re: GC temps-réel

            Posté par Dugland Bob (page perso, ) le 19/09/2002 à 11:27. (lien). Évalué à 1.

            Je crois que j'ai dit une connerie là, tu parlais de contraintes sur la mémoire, pas sur le temps.
            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 () le 19/09/2002 à 19:20. (lien). Évalué à 3.

      > > le ramasse-miettes
      
      > 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 () le 18/09/2002 à 23:24. (lien). Évalué à -11.

    Eiffel rulez
    
    Ah, ok, j'avais pas vu la signature... Au temps pour moi.

    • [^]Re: oups

      Posté par DiZ () le 18/09/2002 à 23:31. (lien). Évalué à 0.

      Master-DiK tu as oublié de dire que au moins le C++ ca s'apprend en 1/2 journée

  • [+] [^]Re: Eiffel

    Posté par Sylvestre Ledru (Jabber id, page perso, ) le 18/09/2002 à 23:49. (lien). Évalué à -3.

    Héritage du passé et manque de personnes qualifiées font que certains dinosaures (Cobol,C,...) restent présents
    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 (page perso, ) le 19/09/2002 à 00:10. (lien). Évalué à 7.

      c'est surtout parce que ça reviendrait trop cher de tout migrer vers un autre langage, en regard des avantages...

      --
      Clément Hermann (nodens)
      - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
      Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
      GPG : pgp.mit.edu - 0xEBD1399D

      • [+] [^]Re: Eiffel

        Posté par LupusMic (page perso, ) le 19/09/2002 à 02:49. (lien). Évalué à -4.

        Et que ça à l'air de fonctionner. Pourquoi changer alors que ça fonctionne ? Windows est beaucoup utilisé comme station de travail alors qu'il marchote ... alors il vont pas jeter à la trappe un truc qui fonctionne correctement !

  • [^]Re: Eiffel

    Posté par Mickaël L () le 24/09/2002 à 15:34. (lien). Évalué à 1.

    > certains dinosaures (Cobol,C,...) restent présents
    
    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 (page perso, ) le 19/09/2002 à 11:04. (lien). Évalué à 5.

  Eiffel est statiquement typé, donc incomparable, si tu veux de la pureté, prends Self, il a pas ces infamnies au niveau Metaclass class etc. puisqu'il n'a pas de classes :-)
  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 () le 19/09/2002 à 11:50. (lien). Évalué à 8.

  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
  
  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 !

• [^]Re: En entreprise ! (suite)

  Posté par Philip Marlowe (Jabber id, ) le 21/09/2002 à 09:19. (lien). Évalué à 4.

  Ce qui manque à SmartEiffel, à mon avis :
  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 (Jabber id, ) le 21/09/2002 à 09:31. (lien). Évalué à 6.

  Abrégeons.
  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.