lundi 06 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de Montaigne :

[05/10@00:33] Alliance Sun - Google
[02/10@18:07] GCC et le mmx/sse{1,2,3)/3dnow
[22/09@14:29] Comment résoudre la "crise du logiciel" ?
[16/09@14:19] Les ratés historiques de l'informatique française
[04/09@19:18] TF1 roule pour Sarko
[04/09@16:54] Une vidéo de la Nasa sent le trafiqué
[30/08@10:18] C'est beau comme de l'antique...
[06/07@21:53] Conception d'une API interface utilisateur
[20/06@11:09] Spécifier une nouvelle librairie graphique
[01/06@13:13] Microsoft transmet ses propositions définitives à la Commission
[13/04@21:39] Meeting militant pour le oui
[05/04@17:25] Les (vieux) automates de la SNCF tournent sous...
[18/03@19:15] Microsoft vaincra
[09/09@15:19] La constitution européene
[06/09@16:38] Licence logiciel et viabilité du modèle économique
[15/07@22:18] Automatisation de patching de sécurité
[13/07@21:13] "Ce que nous vendons a Coca-Cola, c'est du temps de cerveau humain disponible"
[24/06@12:49] Documentation sur le wrapper du driver nvidia
[17/06@11:22] Logiciel générant automatiquement le graphe d'un code source
[10/06@11:09] Bijection entre noeud et graphe

Journal : Repenser les langages et le développement logiciel

Posté par Ontologia (page perso, ) le 06 octobre 2005

Chers tous, j'aimerai vous présenter deux réflexions très profondes qui tentent de remettre en perspective notre façon d'écrire des logiciels, d'architecturer ceux-ci et bien sûr de repenser totalement les langages de programmation.
Cette remise en cause émerge face à l'importance des bugs dans l'industrie logicielle.

Jaron Lanier[1], pionnier de la réalité virtuelle et Victoria Livschitz[2], "senior IT architect", tentent d'analyser les causes du facteur bug dans le développement logiciel.

[1]http://java.sun.com/features/2003/01/lanier_qa1.html(...)

[2]http://java.sun.com/developer/technicalArticles/Interviews/livschit(...)

Je vous les traduis ici en le résumant pour vous simplifier la vie, mais vous pouvez toujours lire la source bien sûr. Je discuterai certains points ensuite (pour les non habitués à cet acronyme NDR signifie "note du rédacteur", c'est à dire moi :-).

Dans son interview, Jaron Lanier pose le constat qu'il est est quasiment impossible de développer de gros logiciels réellement fiables et constate que des projets de plus de 30 millions de lignes de code deviennent insurmontable.
Celui-ci s'interroge d'autant plus sur ces difficultés qu'il constate la capacité humaine à gérer des projets très complexes, dans des contraintes de fiabilité drastiques (Automobile, aviation commerciale et militaire, spatial).
Il prend le parti d'affirmer que cela ne doit pas être considéré comme une fatalité ou comme une limitation de l'esprit humain.

Ceci étant posé, il tente d'analyser ce qu'est un bug, et le traduit comme étant une imperfection. Si l'on compare le fonctionnement d'un programme avec les programmes qui animent l'évolution, on constate que dans le premier cas, un simple changement peut tout faire tomber, tandis que dans le second cas, il y a une évolution incrémentale.

(ndr : un programme ne se construit pas du tout de la même façon : c'est un système multi-agent à un niveau, il n'y a donc pas validation algorithmique de niveau inférieurs sur lesquel s'appuyer. Il n'y a pas un banc de test qu'est un biotope pour tester les "algorithmes" (ou les mécanismes biologiques) qui marchent )

Après cette définition, un historique des concepts de modes de programmation est retracé depuis les origines, c'est à dire depuis la conception de l'ordinateur moderne par Turing, Claude Shannon et Von Neumann.
Jaron Lanier fait judicieusement remarquer que les premiers programmeurs, familier de la télégraphie, formulaient toujours leur programme en terme de transmission d'un signal d'un point A vers un point B.
Le code source de nos programme étant une simulation d'information passant à travers de fil, le passage de paramètres à une fonction étant un exemple.
(ndr : d'où le terme de bugs, insecte...)
Ces notions peuvent être fortement étendue : pour décrire la connection entre un rocher et le sol, vous pouvez le le décrire en terme d'information envoyé sur un fil (ndr : lors qu'on pourrait proposer une reconnaissance de pattern "physique")

On pourrait penser en terme de pattern reconnaissant les différents objets entre eux, ce qui diffère du concept classique consistant à créer et utiliser un protocole.

On reste à l'heure actuel avec un paradigme proche de l'information envoyé par télégraphe. Un paramètre passé à une méthode d'un objet n'est que la simulation d'un signal envoyé dans un câble. Ce qui est innefficace lorsque vous gérez un protocole basé sur le temps (ndr : vous êtes obligé de vous représenter le fonctionnement de la machine qui va réussir à respecter les contraintes de temps).
Ce genre de chose est très susceptible à bugs : tout tombe, comme des dominos.
Avec un système de reconnaissance de forme, les bugs seraient proportionnels aux sources de dysfonctionnement

Suit une explication sur les techniques de reconnaissances de forme, dans un contexte précis : reconnaissance d'expression faciale humaine, et des méthodes qui permettraient de les associer : Wavelet et FFT

***

Victoria Livschitz, Senior IT Architect, Européenne (Ukrainienne) mathématicienne et joueuse d'échecs. Je trouve sa contribution plus intéressante et plus concrète, s'étant frotté au développement de très gros logiciel, elle en a bien analysé les manques et rebondit sur la problématique très judicieusement introduite par Jaron Lanier. Je trouve in fine son analyse plus intéressante et plus concrète, tout en laissant le mérite à J.L d'avoir si bien conceptualisé la problématique.

Discussion autour du pasé de la donzelle, qui fut une jeune joueuse d'échec et poursuivi des mathématiques comme tout le monde dans sa famille, pour s'orienter vers l'informatique.

Vient la problématique "Que voyez-vous comme gros problèmes lors de l'écriture de logiciels ?"

Victoria Livschitz raconte son expérience en tant qu'ingénieur de développement sur un énorme projet commandité par la firme Ford.
Elle affirme avoir été choquée par la déficiance de l'ingénierie en informatique en règle général, ajoutant que les gros projets sont rarement couronné d'un succès total.
Les "gros" logiciel, dit-elle sont généralement de qualité pauvre, de service rendu médiocre, difficile à faire migrer, et mal adaptés aux besoins des autres entreprises (trop contextuel à chaque fois), technologiquement obsolète au bout d'un certain temps, et fonctionnellement identique à plein d'autres logiciels adaptés à chaque contextes.
"Tout ça pour des millions de dollars en développement, maintenance - et pour quoi ? D'un point de vue ingénieural, zéro innovation et zéro valeur incrémentale ont été produite"

L'intervieweuse l'interroge alors sur l'analyse développée par Jaron Lanier

Victoria Livschitz se déclare tout à fait en accord avec Jaron Lanier et problématise de la même façon.
Elle déclare être intéressé par l'idée de remplacer la reconnaissance de forme à l'opérateur classique math/no match dominant dans la programmation (les if/then. case/switch, while, repeat/until), la logique floue l'ayant toujours intêressée. Sa quête de de trouver une réponse est selon elle "orthogonal" à celle de Jaron.

Victoria relève deux approches pour créer des logiciels moins complexes tout en répondant aux même besoins. Comme en médecine, il y a l'approche préventive et l'approche "currative".

L'approche préventive a énormément fait de progrès ces trentes dernières années :les langages fortement typés, objets, haut niveaux, garbage collector, la gestion des exceptions (ndr :les contrats), les AGL.

Ceci étant dit, de nombreux bugs ne peuvent être solutionnés par ce genre d'approche en ce qu'un bug, dans le fond, reste un comportement undésirable ( " a sign of recognition") non attendu lors de la spécification. C'est un problème mécanique d'un algorithme qui ne fait pas ce qu'on voulait qu'il fasse (ndr : on retrouve le problème de l'humain avec la perfection, et le manque d'utilisation de l'intuition humaine selon Victoria Livschitz).
Mais il arrive que le l'algorithme soit mécaniquement bon, mais que cette mécanique soit fausse par rapport à l'ensemble.
Le premier est un bug de programmation, l'autre d'architecture, bien plus grave.
Les constants problèmes de sécurité des produits Microsoft est avant tout du à des causes architecturales, Java c'est mieux avec son architecture "sandbox".

Victoria Livschitz ne pense pas que les avancées futures dans le domaine pourra apporter des solutions aux bugs architecturaux : un bout de code se comportant de façon appropriée dans une version précédente ne mettra à dysfonctionner lors du changement de contexte.
Elle affirme que le programme ayant changé de domaine, celui-ci doit s'adapter. Un bug est une simple manifestation d'un nouvel désalignement, et c'est la correction de ce bug et non sa prévention qui compte.

Dans cette optique le polymorphisme et l'héritage sont des concepts vraiment novateurs, bien que de nombreux bugs demandent plusieurs niveaux de refactoring toujours dangereux et imprévisibles.

L'intervieweuse lui demande alors si l'on peut considérer la complexité comme une principale raison d'existence des bugs et si elle dispose d'idées concrètes afin de la réduire.

Victoria Livschitz propose deux principale armes : l'une consiste à laisser s'exprimer l'intuition et l'expérience du développeur et l'autre de décomposer le tout en partie simple puis de les aggréger en un tout.

Les choses apparraissent plus simple lorsque nous faisons appel à notre intuition, à un niveau de conscience totalement concentré sur des choses difficiles. Donc le contraîre de la complexité - et la meilleur arme contre lui - est l'intuition
L'ingénieurie logiciel devrait utiliser l'intuition des développeurs, puis leur expérience, cela permettra au professionnel d'être à l'aise avec cette complexité.

L'ITW lui demande (on dans les équipes de recherches de Sun) si Java est capable de cacher totalement cette complexité au développeur.

Victoria Livschitz est assez franche et explique qu'elle pense qu'on a pas du tout avancé dans la résolution de ce problème (ndr: ce qui rejoint J.L qui expliquait que la programmation avait évolué sur la base des premiers ordinateurs où l'on manipulait des boutons ie. on envoyait des signaux dans des câbles )
Reprenant un peu les idées de J.L, elle les complète en expliquant que la syntaxe reste esotérique. En mathématique on apprend plusieurs années à maîtriser des concepts et une syntaxe permettant de les exprimer en terme de preuve absolu. Le problème, en programmation, est qu'on ne décrit que des métaphore de fonctionnement le plus correcte possible par rapport à notre perception de la vie de tous les jours, où de processus humains de traitement de donnée (au sens où il y a un contenu et une structure ontologique http://fr.wikipedia.org/wiki/Ontologie_(informatique)(...) de ces données )
Les programmeurs ne sont pas aussi sélectionnés que des mathématiciens, qui ne sont pas aussi nombreux , et les études peuvent être plus courtes.

Pendant longtemps, les développeurs manipulaient des sous-programmes, fonctions, structures de données, boucle et contructions abtraites qui néglige, sourde l'intuition humaine.
Apparait la programmation orienté objet.
On peut pour la première fois créer des construction beaucoup plus proches du monde réel. C'est un concept globalement accessible même par un non informaticien (ndr : dans sa globalité oui, j'ai pu le vérifier, parce lorsqu'on rentre dans les détails avec la différence entre paramètre par référence ou par copie, là ça coince vite...).

L'OO a permis à l'industrie de créer des logiciels beaucoup plus complexes qu'en procédural, mais il atteint maintenant une limite : personne ne peut confortablement manipuler un système de plusieurs milliers de classes.

Dans les langages OO, l'objet est la seul abstraction disponible, l'univers que l'on souhaite définir est uniquement modélisable avec cette construction, en maniant la généalogie (ndr : en anglais inheritance signifie généalogie, terme que je préfère au moins approprié français "héritage) et la notion de collections. Ce qui peut rendre les choses assez difficile : le monde est trop riche pour être exprimé avec cette syntaxe trop frustre.

Considérons les concepts courament utilisé afin de décrire le monde : avant/après, causse/conséquence, Etat d'un système. Les concepts "préparer un café", "assembler un véhicule, "diriger un rover sur Mars" ne peuvent être décomposé facilement en objets simples. Traité avec l'approche OO, leur programmation sera inintuitive.
Les séquences de programmes eux-même : Que ce passe t-il en fonction de quel conditions basé sur quel causalité - n'ont pas de modalité d'expression, de représentation en OO, parce les langages OO n'ont pas de concept de séquence, d'état, ou de cause.

La notion de processus est habituel dans le monde réel et dans la programmation. tous les mécanismes élaborés ont été conçu pour gérer des transaction, workflow, orchestration, threads, protocole et tout concept intrinsèquement procédural.
Ces mécanismes complexes compensent la notion de gestion du temps absente (ndr : un objet n'est pas un agent, il n'est pas vivant, il est instancié ou détruit, c'est tout).
La notion d'avant/après n'est pas implémentable à la base, il faut le construire. Il faudrait que l'avant/après, l'état système soit au coeur du langage.

Victoria Livschitz envisage un langage plus riche que les langages OO basé sur un certains nombres de primitives plus intuitives, de métaphores plus accessibles comme des objets, des conditions et processus. On pourrait imaginer cela comme une extension aux syntaxes existantes.

L'intervieweuse récapitule sa thèse : La programmation doit être plus intuitive pour les développeurs et mieux simuler le monde réel, cela aiderait les programmeurs à écrire des logiciels avec moins de bugs ?

Victoria Livschitz répond que c'est exactement sa thèse, ajoutant que c'est un combat contre la complexité et une tentative de mieux permettre l'expression de l'intuitivité du développeur.
Elle cite visual basic comme exemple, qui a permis de vulgariser le développement.

Mais étendre le modèle objet pour étendre le nombre de primitives n'est qu'une partie de la guerre contre la complexité, l'autre est un meilleur modèle d'aggrégation/décomposition de ce qui est encore alambiqué et fragmenté à l'heure actuel.
Et cela, sera toujours d'une extrême importance.

Hiérarchies et collections sont les seuls outils dont on dispose pour définir les relations entre objets et comment elle devraient être organisées en structures manageable (ndr : J'ai toujours un problème avec la traduction de manage en français : gestion est trop passif).
Même si la nature est rempli de structure hiérarchiquement descriptibles et de collections (un arbre est une hiérarchie d'objet, avec des collections de feuilles par exemple, de chloroplaste, etc...), ce duo est trop limité pour nos besoins.

Il existe plein d'autres relations qui satisferaient : Maître/Esclave, relation plusieurs à plusieurs ( ndr : SMA ?), component/container, intervalles, element/métradonnées, et plein d'autres.
Peut-on condidérer l'objet comme la seule unité valable ? Nous ne possédons que le "Possède A", "Est A".
Une fois intégrés, on pourrait imaginer la définition d'élément dialoguant avec une sémantique beaucoup plus riche, un logiciel graphique de "design pattern" permettrait de documenter comment on aggrège les éléments entre eux dans le système collectif (ndr :voir thèse de Pierre-Michel Ricordel [3])

Nous avons besoin d'une architecture composant autonome assez riche pour couvrire tous le besoins, de la distribution à la réutilisation.
Ces composants disposeront de d'autres relations que les relations "Is-A" "Has-A". L'héritage ne sera qu'une relation parmi d'autres.

Il faudra alors créer de nouveaux supports théoriques à la réutilisabilité, peut être dans une voie évolutionniste afin que le refactoring ne soit pas une opération destructive sémantiquement et syntaxiquement garanties par le compilateur

Victoria Livschitz affirme qu'à son avis, il s'agit de la meilleur méthode pour exprimer la puissance du logiciel.

***
Ces deux contributions m'apportent plusieurs questions et réflexions que je jette ici aux lions (Ave Caesar, morituri te salutant)

Sociologiquement, tout d'abord : Y aura t-il une résistance des informaticiens quand à la perte de leur pouvoir quand à la complexité technique ?
Oui et non, je pense, car certes, n'importe quel cadre d'une entreprise pourrait s'écrire son petit logiciel, comme il y arrive honorablement aujourd'hui avec Excel, Access, mais je pense que seul un "oeil" d'informaticien, pardon de spécialiste des systèmes d'informations, pourra solutionner des problèmes complexes.
Cela permettrait de former des professionnels sur les systèmes d'informations et l'organisation de l'entreprise. Et on pourra relocaliser : il faudra être proche de l'entreprise pour cela..

Une autre question de développeur celle là : On peut bien sûr construire des objets permettant d'autres relations que le match/no match en les construisants par rapports aux axiomes existants, mais la syntaxe des langages actuels est-elle alors adaptée ? Je pense AMHA qu'il faudra reprendre un minimum la syntaxe et faire évoluer les concepts de compilation pour intégrer de tels relations. Cela nécessitera aussi de recourir à des langages acteurs ou plutôt orienté agent, qui, pour le moment reste confiné en laboratoires d'où il sortent assez rarement( voire [3].

[3]http://rangiroa.essi.fr/rapports/2001/01-these-ricordel.pdf(...)
Vous trouverez ici ftp://ftp.enseeiht.fr/pub/logiciel/thesis/Matthias.Colin/thesecoli(...) , dans les premières pages de sa thèse, un très bon résumé des concepts étudié et développés pour les langages acteurs.

Il y a quelques temps, je me suis englué (je suis un assez mauvais codeur) en Java en faisant un petit jeu monojoueur consistant à diriger un sous-marin (cap et vitesse) et à courir derrière les bateaux ennemis pour les couler. C'est là que je me suis rendu compte, comme Victoria, que les paradigmes OO sont très limité. On se rend compte que le simple fait de vouloir coder le comportement d'un bateau détectant notre sous-marin dans le radar et demandant de l'aide à un bateau de guerre aux alentour est extrêmement pénible à coder.
J'ai vraiment eu l'impression de devoir rentrer un cube dans une fente en forme de disque.
Un langage agent avec possibilité d'envoyer des messages multipoint (que j'ai commencé à définir d'ailleurs) serait beaucoup plus approprié pour ce genre de chose.
La gestion du temps réel y serait aussi importante.
Le problème est que pour cela, il faudrait pratiquement un nouvel OS, temps réel, avec une gestion des thread poussée (temps réel) et capable d'assurer absolument qu'un programme terminera son exécution à temps, et pour cela il faut donner des informations au compilateur afin qu'il évalue ce temps de calcul, par analyse de flot.

Deux liens en plus pour les courageux ;-)
La discussion sur /. autour de l'interview de Victoria Livschitz :
http://developers.slashdot.org/comments.pl?sid=96750&threshold=(...)

Quelques réflexions sur son blog :
http://blogs.sun.com/roller/comments/alur/Weblog/what_is_a_micro_ar(...)

Mon horizon est à une ou deux décennies, il ne s'agit pas de commenter les dernières évolutions cosmetiques de tel ou tel langage, mais de s'attaquer au mal à sa racine :-)

Je rappelle, à toutes fins utiles le questionnement de mon journal :

A quoi pourrait ressembler un langage accessible mélangeant des concepts OO avec d'autres primitives, en intégrant peut-être d'autres logiques (fonctionnelles ? Logique ? Agent ? Acteur ?) et surtout en permettant à l'intuition de s'exprimer et ainsi de réussir d'énormes projets logiciels.
(Par accessible j'entend facilement compréhensible par un enfant de 10 ans par exemple. Logo était un très bon exemple.)

En d'autres termes, quel sens donner à des primitives comme Maître/Esclave, Composant/Containeur, intervalles, élement/métadonnées, Chef de groupe (dans un contexte agent), objet physique, objet mécanique, etc..

Quel autres primitives créer ? Quel sens leur donner ? Quel besoins pourraient-elles couvrir ?

Comment permettre aux développeurs d'exprimer la puissance de leur intuition ?

Comment rendre l'écriture de logiciel moins complexe ?

> Lire le journal (114 commentaires, moyenne: 3,9).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Ouf

Posté par Uld (page perso, ) le 06/10/2005 à 23:04. (lien). Évalué à 10.

J'ai enfin atteint le bas de la page....

Bon y a plus qu'à lire maintenant. :°|

--
Ubuntu is an ancient african word meaning : "I can't configure Debian".

[^]Re: Ouf

Posté par Ontologia (page perso, ) le 06/10/2005 à 23:06. (lien). Évalué à 10.
Oui je suis désolé, c'est un peu long, mais j'ai voulu traiter ce problème correctement ;-)

J'ai bien du passer 6 à 8 heures sur ce journal ;-)
- [^]Re: Ouf
  
  Posté par Bruce Le Nain (Jabber id, page perso, ) le 07/10/2005 à 11:15. (lien). Évalué à 10.
  Tu devrais absolument mettre tout ça sur un site perso, agrémenté d'images, par exemple, car les journaux on malheureusement tendance à disparaitre vite noyés dans la masse. Enfin, heureusement les journaux publics restent visibles plus longtemps !
  
  Merci pour ce travail.
  
  --
  Hôdo
  Livingstone
  - [^]Re: Ouf
    
    Posté par Victor STINNER (page perso, ) le 07/10/2005 à 12:31. (lien). Évalué à 6.
    En attendant, je te propose, Ontologia, de "squatter" mon site perso. J'utilise MediaWiki. La syntaxe est simple et l'utilisation l'est également. Tu pourras découper ton article et deux/trois articles, mettre des titres, ajouter des URL dans le texte, ajouter des images, etc.
    
    http://www.haypocalc.com/wiki/Langages_de_programmation(...)
    Suffit de se créer un compte, la page donnée ci-dessus devrait être la bonne catégorie je pense.
    
    Haypo qui n'a pas non plus réussi à lire ce pavé de texte sans titre ni rien, et en plus il est à la bourre ...
    (au pire, tu as mon email ;-))
  - [^]Re: Ouf
    
    Posté par blobmaster () le 07/10/2005 à 22:03. (lien). Évalué à 4.
    Tout d'abord bravo pour l'article. Ce fut un régal que de le lire.
    
    Je suis d'accord sur l'intérêt d'avoir une version plus "aguicheuse" sur un autre site (confort de lecture, images, tout-ça..) Mais le fait d'avoir cet article sur Linuxfr permettra, à l'avenir, de pouvoir faire des recherches plus facilement.
    
    Je sais pas vous mais je commence facilement mes recherches un peu techniques ou de réflexion (sur les LL) par un gouglage de linuxFR.
    
    L'ouverture d'un tel débat/L'ouverture d'une telle réflexion, a sa place ici je trouve.

Bof

Posté par Vivi (page perso, ) le 06/10/2005 à 23:55. (lien). Évalué à 3.

Le premier article avait été discuté sur LtU [1] il y a quelque temps (le deuxième aussi mais je ne le retrouve pas). Il n'avait pas fait grande impression [2] et j'étais plutôt d'accord avec les critiques.

Personnellement, l'avenir pour les langages de programmation je le vois plutôt dans les langages fondés sur concepts mathématiques, genre la programmation fonctionnels, les calculs pour la programmation concurrente, le multi stage programming, etc. Pas dans le handwaving frénétique assorti d'analogies vaseuses que nous sert J. Lanier.

(désolé, c'est un peu court comme réponse au vu du temps que tu as passé à écrire tout ça mais il se fait tard).

[1] http://lambda-the-ultimate.org/(...)
[2] http://lambda-the-ultimate.org/node/view/925#comment-9013(...)

[^]Re: Bof

Posté par Ontologia (page perso, ) le 07/10/2005 à 00:17. (lien). Évalué à 7.
Je ne suis pas tout à fait en désaccord avec toi. Mais il y a un problème dans ton approche :

Les mathématiques sont un art difficile qui ne sont pas à la portée de tout le monde.

Je sort d'un BTS et je peux te dire qu'on y forme pas mal de gens qui, au sortir de leur formation, savent faire un logiciel en VB, Windev ou faire un site, mais ne maîtrise absolument pas le concept de fonction...

Si tout le monde en était capable - je veux dire les millions de professionnels de l'informatique, les types qui pisse de la ligne pour des logiciels de gestion bateau - ta solution serait la meilleur.
Et d'ailleurs, si tu avais raison, Caml serait un langage Roi dans l'industrie. On a quoi en ce moment ? C#, Java, VB, PHP, etc...

Mais ce n'est pas le cas de tout le monde.

Ce que je veux dire, c'est que le problème n'est pas *fonctionnel, il est de s'adapter à la population des gens qui développent des logiciels, et il ne sont pas tous capable d'avoir une licence de maths (avec le niveau d'une licence en France, s'entend).
---
(désolé, c'est un peu court comme réponse au vu du temps que tu as passé à écrire tout ça mais il se fait tard).
Mais je t'en prie :-)
- [^]Re: Bof
  
  Posté par Guillaume Knispel () le 07/10/2005 à 00:45. (lien). Évalué à 9.
  A ce moment c'est plutôt le niveau des informaticiens qu'il faut remettre en question. L'outil miracle qui permet à tout le monde de faire 0 bug n'existe pas, tout le monde en est conscient (sauf certains defenseurs aveuglés de leur langage preféré ;)
  
  Il me semble assez normal, je pourrais même dire intuitif, que l'approche objet soit limité en complexité gérable, tout comme le procédural est limité. De même il me semble plutôt logique que quelqu'un qui n'a pas une grande capacité à l'abstraction n'ait ni la même approche ni les mêmes résultats que quelqu'un qui travaille comme ça.
  
  Concernant les articles et notemment les lacunes en ingénieurie logicielle par rapport à d'autres domaines, trois remarques : quand on veut vraiment on peut tendre vers la quasi perfection - 30000000 de lignes c'est déjà pas si mal... je vois mal pourquoi on voudrais faire plus ;) - encore faudrait-il que les méthodes d'ingénieurie soient appliqués, et de plus très intelligement (du genre ne pas ecrire des doc inutiles et 3x plus longues que chaque fonctions juste parce quelqu'un a décidé que c'était obligatoire, éviter de concevoir toute l'architecture en mode ultra détaillée d'un gros projet sans avoir la force de travail (compétente en plus! :) necessaire a un tel boulot et sans faire les tests qui s'imposent en même temps, etc..., etc...)
  - [^]Re: Bof
    
    Posté par Obi MO (page perso, ) le 07/10/2005 à 12:01. (lien). Évalué à 6.
    
    L'outil miracle qui permet à tout le monde de faire 0 bug n'existe pas
    
    Certes, mais un language très expressif, moins de caractères entrainant moins de bgs), ne permettant pas de manipuler des concepts dangereux (pas de pointeurs, de boucles non finissables), ayant une relation au temps discrète (un language fonctionnle synchrone quoi) et travaillant correctement sur les types (inférence de types) réduit drasitquement le nombre de bugs.
    
    Ayant pas mal développé en C/C++/Java, jamais je ne conseillerai ça pour développer du code critique embarqué. Pour ça il y a des languages comme lustre et des outils associés comme SCADE. C'est utilisé par Airbus pour les commandes de vol de l'A380, Eurocopter pour ses pilotes automatiques, dans des centrales nucléaires, etc. Pour l'avoir utililsé en production, je peux dire que ça n'a rien à voir avec un langage classiqe, l'impression est bizare: tu codes et du premier coup ça marche. Si ça marche pas, c'est que ça vient du materiel, des drivers ou de l'intégration.
    A force de bosser avec ça, tu chopes la grosses tête, c'est toujours chez les autres que ç amarche pas, jamais chez toi ;o)
    
    Bon allez, j'ai fait ma pub, un petit lien:
    http://www.esterel-technologies.com/products/scade-suite/overview.h(...)
    
    Et c'est pas parce que je bosse là bas que je dis tout ça ;o)
  - [^]Re: Bof
    
    Posté par Ontologia (page perso, ) le 07/10/2005 à 12:56. (lien). Évalué à 6.
    Je réitère ce que je disais.
    
    Un type qui sort d'un Bac pro compta, qui n'a pas fait beaucoup de maths, qui sort d'un milieu culturel ne le portant pas à beaucoup de curiosité, assez réticent à l'effort intellectuel, n'est pas capable de maîtriser de tel langages. En tout cas, même s'ils ont la capacité d'abstraction nécessaire (et encore), ils n'ont pas l'endurence et la volonté requise pour maitriser de tels langages.
    
    Lorsque tu écoutes des DSI, tu te rend comptes que beaucoup renoncent à Java car leurs équipes de développement ne sont pas capable de s'y mettre...
    S'il y a 50% des développeurs capable de programmer en orienté objet (de programmer en objet, pas d'utiliser des objets comme en VB), c'est déjà pas mal.
    
    Ceci posé, on pourrait décider de ne plus former d'informaticiens à Bac+2.
    Parce que in fine, c'est un peu ton propos ou tout au moins ce qu'il implique :
    
    Maîtriser le caml/lisp/etc.. comme tu sais le faire demande quelques années d'études en cycles académiques.
    Je comprend tout à fait la passion que peu susciter de tels langages, à mon niveau, je la partage, mais il faut choisir : soit on forme des professionnels de niveau moyen (Bac+2, Bac+3) et on essaye de limiter la complexité, soit on forme des ingénieurs à manipuler des langages comme Caml.
    
    Je voudrais bien que vous compreniez quelques chose, tout le monde, sur linuxfr : La plupart d'entre vous font partie d'une élite, il y a beaucoup de Bac+5 et plus ici. Mais vous n'êtes pas majoritaires dans le métier..
    - [^]Re: Bof
      
      Posté par Guillaume Knispel () le 07/10/2005 à 13:16. (lien). Évalué à 4.
      Tout à fait d'accord. Mais si un bac+2 / +3 convient très bien pour créer certains petits outils et programmes (et d'ailleurs certains bac+2/+3 sont capables de bien plus mais c'est une autre histoire ;) ) simples en utilisant quelques objets et constructeurs visuels d'IHM, et si 50% ne maitrisent pas l'approche objet, alors il est illusoire de vouloir étendre l'approche objet (ou tout autre approche) pour qu'elle soit plus en adéquation avec les métaphores du monde réel. Une extension implique la compréhension de la base, et ce n'est pas un ajout de concept qui rendra le tout plus simple.
      
      Reste qu'il est surrement utile de le faire, et il est clair que quand on parle de projets de 30 Mloc on parle de gens capables d'abstraction et d'apprendre n'importe qu'elle nouvelle approche, pas de developpeur VB :)
      - [^]Re: Bof
        
        Posté par d-jo (page perso, ) le 07/10/2005 à 13:41. (lien). Évalué à 1.
        Celà dit en passant, je connais beaucoup d'ingénieurs et plus qui sont d'une telle rigidité et tellement incapable d'apréhendre une dynamique humaine et collective qu'ils en finissent par ne plus se supporter eux même.
        
        Il y en à même qui forment des bac+2
    - [^]Re: Bof
      
      Posté par CrEv (page perso, ) le 07/10/2005 à 13:32. (lien). Évalué à 5.
      
      Un type qui sort d'un Bac pro compta [...] n'est pas capable de maîtriser de tel langages
      
      sans vouloir dénigrer cette filière, mais c'est pas un peu normal que quelqu'un sortant d'un bac pro compta ne sache pas maitriser correctement certains langages ?
      c'est pas vraiment une filière destinée à former des programmeurs / informaticiens donc ca reste quand même logique, non ?
      - [^]Re: Bof
        
        Posté par Ontologia (page perso, ) le 07/10/2005 à 14:15. (lien). Évalué à 6.
        Je ne dénigre absolument pas le bac pro compta. Ils sont très compétent dans leur domaine (auquel je comprend rien d'ailleurs).
        
        Je parle de jeunes gens qui sortent d'un Bac pro pour faire un BTS Info gestion, option développeur.
        
        Sans leur jeter la pierre, à cause de leur manque de formation en maths, ils ont déjà énormément de mal avec le programme de BTS qui est un espèce de programme de Term S amélioré.
        
        J'ai été nul en Term S, je ne comprenais rien aux maths, puis j'ai découvert, à la fac, les bases des maths (dans ce pays, on marche sur la tête, on t'apprend à dériver une fonction sans t'expliquer ce qu'est vraiment une fonction..).
        Donc je comprend vraiment ce que c'est de ne rien comprendre à ce programme de Term S, ce qui était le cas de beaucoup de mes collègues de BTS.
        
        Ce que j'ai compris depuis, sont les concepts de fonction, de structures algébriques de base (Groupes, anneaux, corps, Algèbres, les bases de la topologie).
        Or, maîtriser ces structures, ou tout au moins les bases de la théorie des ensembles est vraiment nécéssaire pour être un bon informaticien. Une bonne culture fait le reste : si le type qui sort avec un BTS a passé quelques heures à lire les pages théoriques de Wikipédia sur l'informatique et qu'il les a globalement compris, c'est déjà pas mal. Le problème est aussi de leur faire comprendre que c'est important. Ca j'ai essayé de leur expliquer (peut être mal) mais ils étaient pour la plupart bouchés.
        
        Mais en général, les gens qui sortent de Bac pro pour un BTS ont du mal avec les concepts de boucles, de test, de logique, c'est normal, on ne leur a jamais appris les bases !!
        
        Tel est le système scolaire français et tel est le marché.
        
        Il faut s'y adapter ou le changer.
        
        [^]Re: Bof
        
        Posté par imalip (page perso, ) le 07/10/2005 à 15:17. (lien). Évalué à 8.
        Et serieusement, des personnes qui ne sont pas capables de comprendre le principe de boucle arrivent a se faire embaucher comme developpeur ? Faudrait pas revoir certaines choses du coté du recrutement aussi ? Parce que si on colle des personnes incompétentes a des postes comme ca, ca ne m'étonne pas qu'on retrouve des bugs a la pelle.
        
        --
        "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
        
        [^]Re: Bof
        
        Posté par Ontologia (page perso, ) le 11/10/2005 à 16:18. (lien). Évalué à 2.
        Je me pose la question. Disons qu'au bout de deux ans, les enseignants ont quand même réussi à faire passer le concept...
        
        Après ça ne concerne que certaines personnes dans un groupe-classe, la plupart des diplômés sont bon voire très bon pour certains !
    - [^]Re: Bof
      
      Posté par Obi MO (page perso, ) le 07/10/2005 à 16:41. (lien). Évalué à 7.
      Je ne sais pas si c'est tellement une question d'années d'études. Je pense que c'est plutôt une démarche intellectuelle: je suiis curieux, je cherche à faire mieux, je suis uvert à ce qui se passe ailleurs. Si tu as la chance de tomber sur des gens qui savent des choses et qui sont disposés à les enseigner, là tu deviens un vrrai professionel.
      
      Mais tout Bac+N que tu sois, c'est rarement à l'école que tu apprends à développer une application. Pour être un tant soit peu à l'aise dans la conception d'applications en C++ par exemple, il faut en faire tous les jours pendant au moins un an ... Et encore, tu es loin d'en maîtriser tous les aspects.
      
      Bon, je viens de relire ton message puis le mien, en fait on est parfaitement d'accord.
      
      Pour faire court, si tu prends un mauvais ébéniste, ton meuble, il aura peut-être une tête de meuble, mais il sera moche, vieillira mal et t'encombrera plus qu'il ne t'aidera. Pour la conception d'applications, c'est pareil.
      
      Comme pour les chasseurs. Le mauvais, il voit un truc qui bouge, il tire ... Le bon .. ben il tire aussi, mais c'est un bon chasseur.
    - [^]Re: Bof
      
      Posté par riri le breton (page perso, ) le 15/10/2005 à 06:36. (lien). Évalué à 0.
      Je n'ai fait qu'un DUT GEII (Génie Electrique et INfo Indus) et je maîtrise parfaitement caml/poo/c++/java.
      
      Non ce n'est pas une question de longueur de formation, mais une histoire de motivation. Arrêtez de dire que seuls les ingénieurs savent régler les problèmes complexes, c'est complètement faux !
      
      Dans ma boîte, ce sont uniquement des BAC+2 qui développent correctement les produits (250 développeurs), les ingé sont trop abstraits pour gagner en efficacité.
      
      --
      La liberté d'une personne s'arrête là où commence celle des autres.
      - [^]Re: Bof
        
        Posté par patapon () le 22/10/2005 à 12:11. (lien). Évalué à 2.
        "je maîtrise parfaitement caml/poo/c++/java."
        
        Permets moi d'en douter.
        
        Maitriser parfaitement une technologie, ça prends des années. Il faut avoir travaillé sur de gros projets, connaitre l'ensemble des outils et solutions disponibles face à un problème, avoir debattu avec pas mal de monde sur certaines caracteristiques d'un langage...
        
        Je ne te connais pas donc je ne peux pas me permettre te mettre en cause tes compétences (qui je n'en doute pas sont sans doutes elevées) mais de là à pretendre que tu maitrise parfaitement lest technologies evoquées ci dessus...
- [^]Re: Bof
  
  Posté par JYF () le 07/10/2005 à 06:17. (lien). Évalué à 3.
  JJe devrai mettre mes lunettes avant de poster ici on parle de Caml :)
  
  Et d'ailleurs, si tu avais raison, Caml serait un langage Roi dans l'industrie. On a quoi en ce moment ? C#, Java, VB, PHP, etc...
  
  Je dirai que un langage/logiciel/OS répendu n'implique pas que ce soit le meilleur langage/logiciel/OS :o)
- [^]Re: Bof
  
  Posté par saorge () le 10/10/2005 à 19:29. (lien). Évalué à 6.
  Les mathématiques sont un art difficile qui ne sont pas à la portée de tout le monde.
  
  Et ?
  En lisant ta phrase, j'ai pensé à "La médecine, c'est compliqué, et ce n'est pas à la portée de tout le monde...". Quelle est la conclusion de cette affirmation ? Dans le reste de ton commentaire, tu as l'air de dire qu'il faut éviter de faire trop compliqué. Euh, en relisant, tu dis bien qu'il faut s'adapter à la population de programmeur ;)
  
  Je sors également d'un BTS (enfin, on dit graduat par chez moi) dans le domaine de l'informatique de gestion. J'y ai appris les bases de l'algorithmique, les bases du C, et même des bases en comptabilité. En sortant de ces études, j'étais capable de m'intégrer dans un équipe pour développer des applications de gestion. Durant ma formation de BTS, j'ai également eu des cours de math. Encore une fois, basiques. Mais bon, l'objectif de ces études était de faire de moi un développeur (un pisseur de code comme tu dis), pas un 'computer scientist'. Il me semble important de faire la distinction.
  
  Dans mon cas précis, ce graduat en programmation en suivait un autre en bibliothéconomie, et précédait une licence et un DESS dans le domaine des 'library and information science'. Mon métier n'est pas de développer des logiciels, mais je suis souvent en relation avec des développeurs. En tant que client, je suis en droit de demander des logiciels sans bugs. Est-ce que la compétence, ou l'incompétence des pisseurs de code doit perturber cela ? Pour reprendre l'exemple de la médecine, quand je vais trouver un médecin, et bien, j'espère en sortir vivant ;)
  
  Dans l'idéal, il faudrait faire le métier pour lequel on a été formé, mais bon, ce n'est pas toujours le cas (nous ne vivons pas dans l'idéal de toute manière). Mais si le métier implique de comprendre de manière avancée les math, et que l'on en est pas capable, il est logique d'en tirer les conclusions. Vouloir appliquer le principe de Peter à tout prix n'est peut-être pas une bonne idée.
  
  Programmer peut-être un hobby, comme le dessin. Mais vouloir en faire son métier implique pas mal de "détails". Il est important de garder cela en tête. Parce qu'au final, cela donne des choses parfois saugrenues (je me souviens d'avoir côtoyer des consultants en informatiques qui m'expliquaient des choses que je connaissait déjà, et manque de bol pour eux, je constatais qu'ils ne maîtrisaient pas du tout leur dossier, voire leur boulot ! ; mais bon, je tiens à rassurer le plus grand nombre, ce n'est qu'une minorité des consultants rencontrés).

[^]Re: Bof

Posté par JYF () le 07/10/2005 à 06:10. (lien). Évalué à 3.
A propos du paradigme fonctionnel, j'ai justement un cours de OCaml dans 1/2h (... ou pas) :o) c'est bien le seul langage ou je peux ecrire une fonction qui marche du premier coup :) et où la plupart des bugs sont detectés à l'analyse de type plutot qu'a l'execution.
Je trouve que ce langage est peu considéré en dehors du milieu de l'éducation mais que vaut-il dans des projets taille réelle genre MLdonkey selon vous ?
- [^]Re: Bof
  
  Posté par serge_kara () le 07/10/2005 à 08:12. (lien). Évalué à 10.
  et où la plupart des bugs sont detectés à l'analyse de type plutot qu'a l'execution.
  bugs "techniques" je veux bien (et encore, un effet de bord malencontreux etc.), mais detecter un bug fonctionnel au typage, l'est fort le compilo... ;-)
- [^]Re: Bof
  
  Posté par briaeros007 () le 07/10/2005 à 13:45. (lien). Évalué à 3.
  je peux faire a peu pres la meme chose en java quand la taille des fonction n'est pas trop grosse (style la methde encode de pkcs euh non pas du premier coup).
  Et le compilo java est aussi sympa pour les erreurs "bateau".
  De meme que la trace pour les bugs levant des exceptions non catché pour le debug.
  Tout ca pas pour dire java bien caml pas bien, ou autre, mais pour dire que plus on a l'habitude et de l'experience dans un langage mieux on s'en sors,et moins il y a de bug directs .
  
  --
  Subete ga wakatta toki…watashi ga anta wo korosu.

J'étais en train d'essayer de lire et de tout capter.... quand ...

Posté par Guillaume Knispel () le 07/10/2005 à 00:31. (lien). Évalué à 3.

Elle cite visual basic comme exemple, qui a permis de vulgariser le développement.

C'est sûr qu'en visual basic on fait des projets de 10000 classes et de 30 000 000 de lignes :)))

[^]Re: J'étais en train d'essayer de lire et de tout capter.... quand ...

Posté par Ontologia (page perso, ) le 07/10/2005 à 00:40. (lien). Évalué à 2.
Concernant VB, Il s'agit seulement de donner un exemple de ce que l'effort de "vulgarisation" peut aider à populariser la programmation et à la rendre tyrès accessible.

Après je ne pense absoluement pas qu'elle pensait à VB pour autre chose.
C'est peut être ma traduction qui est mauvaise ?
- [^]Re: J'étais en train d'essayer de lire et de tout capter.... quand ...
  
  Posté par Guillaume Knispel () le 07/10/2005 à 01:00. (lien). Évalué à 3.
  J'ai pas encore attaqué les articles proprement dit, mais la traduction laisse comprendre les idées générales c'est l'essentiel.
  
  C'est marrant j'ai l'impression que la recherche de nouveau concept de prog bouge pas mal en se moment, et ca coincide avec quelques reflexions perso que je me fais depuis quelques mois. Coincidance amusante...et ultra interressante puisque du coup je découvre un tas d'idées excellentes à droite à gauche :) Le problème pour moi ca va être pour trier tout ça et en ressortir quelque chose d'utile pour moi (et si possible pour les autres ça serait le top...) :P
  
  Concernant ton texte ya un point qui m'échappe un peu sur le passage du jeu de sous marin : en quoi un framework serait inexploitable au point qu'il faudrait carrement faire un OS, temps réel en plus (? pourquoi temps réel, d'ailleurs, puis avec quel algorithme de scheduling, etc ?). Autre point douteux : comment et pourquoi prouver l'arrêt ? Ces deux points + toutes les autres necessités de fonctionnalités du langage me font penser à la quadrature du cercle tant resoudre chacun est en soit non trivial. Il va falloir faire cohabiter des tas de restriction ce qui à mon avis va être guère compatible avec la volonté d'intuitivité initiale...
  
  Bref refaire le monde (enfin reconcevoir de nouvel et nouveaux outils de prog, en soit c'est déjà pas mal) est un boulot vraiment ambitieux... Faut que jm'y mette d'ailleurs :))

Mes deux centimes ...

Posté par harbort1 () le 07/10/2005 à 05:26. (lien). Évalué à 6.

Bon, déjà sur la traduction :
ndr : en anglais inheritance signifie généalogie, terme que je préfère au moins approprié français "héritage"
Alors 1 - c'est faux, selon le Merriam-Webster, inheritance signifie "l'action d'hérité de biens, la réception de traits généalogiques, ..." donc c'est bien "héritage" qui est le plus proche. 2 - je trouve perso que "héritage" est bien plus pertinent que généalogie. Un héritage met l'accent sur ce que le descendant a acquis de son parent et c'est exactement ça qu'on veut dire pour les langages OO ...

Sur la discussion maintenant ... la première impression que j'ai est qu'ils ont tous les deux une vision étriquée de ce qu'on peut faire avec un langage moderne ! Le paradigm courant est le plus répandu est l'objet et l'envoie de message. C'est tout de même un paradigme qui s'est montré efficace et qui m'a l'air de fonctionner dans au moins 90% des cas. Par exemple, dire que les seules relations sont 'is_a' et 'has_a' montre plus les limites des rédacteurs que du concept ... ou alors il faut qu'il nomme des concepts qui ne soient pas réductible à ces deux là ! Pour l'instant, je n'en ai pas rencontré ... en gros, il ne faut pas confondre limitation du paradigme et limitation de l'imagination de celui qui l'utilise !!!

Sinon, mon avis est que le concept le plus limitant aujourd'hui est celui de l'envoie de message ! Certes il est très simple à comprendre et fonctionne dans 90% des cas, mais il reste ces 10% où les gens imaginent des convonlutions invraisemblables pour combler le manque de multi-méthode (i.e. de méthodes résolues sur plusieurs arguments et non un seul). Et à ma connaissance, seul LISP dans les langages répandus permet la création de multi-méthodes.

Ensuite, je trouve qu'il est préférable de séparer structure de donnée et définitions des fonctions qui s'appliquent dessus. Ça permet de faire des logiciels plus extensibles et mieux découpés. Encore une fois, c'est ce que propose LISP, mais pas seulement !
Par exemple, Ruby *permet* cette approche (c'est encore mieux que de la forcer je trouve) !

Et puiss chaque niveau d'abstraction est plus complexe que le précédent à comprendre et à utiliser ! Il a fallu une dizaine d'année (au moins ?) pour que le concept d'objet soit correctement utilisé par une majorité de programmeurs et il faudra encore du temps pour qu'une majorité d'informaticien utilise la programmation OO à bon escient !

Enfin, si un nouveau paradigme apparaît je suis prêt à parier à 1 contre 100 que ça ne viendra jamais de ces gentils agitateurs de mains ! Ce qu'il faut pour ce genre d'innovation c'est un concept complètement nouveau, qui soit implémentable facilement dans les langages actuels (comme l'a été le concept d'objet) et qui vienne d'un programmeur car on dira ce qu'on veut mais seul un programmeur comprend un programmeur ;)

[^]Re: Mes deux centimes ...

Posté par ygo () le 07/10/2005 à 07:30. (lien). Évalué à 2.
D'accord avec toi pour le LISP
a un petit détail près: Ce n'est, généralement, pas le langage qui qui fait la différence mais la richesse des librairies qui y sont associé. En ce sens Java et Python tirent leur épingle du jeux alors que les multiples LISP font moins bien et que, Ocaml, qui est un excellent langage reste marginal.

Pour l'aspect BUG peut être que la bonne solution est celle suivie par Erlang avec sa tolérence aux bugs (voir la thèse de Joe Armstrong sur ce sujet http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf(...) )

Pour le nouveau paradigme et pour le FUN je suis actuellement en train de jouer avec un nouveau langage qui m'apporte beaucoup de plaisir ( même si il n'est pas (encore)utilisable dans un contexte industriel).
Factor (c'est son nom) reprend certains des concepts vu trouvé dans Forth, Joy, Common Lisp, K, et Slate te offre enormément de possibilités tout en restant à taille humaine (a comparer avec l'usine à gaz de la JVM HotSpot).
http://factor.sourceforge.net/(...)

[^]Re: Mes deux centimes ...

Posté par gc (page perso, ) le 07/10/2005 à 12:51. (lien). Évalué à 2.
il reste ces 10% où les gens imaginent des convonlutions invraisemblables pour combler le manque de multi-méthode (i.e. de méthodes résolues sur plusieurs arguments et non un seul). Et à ma connaissance, seul LISP dans les langages répandus permet la création de multi-méthodes.

Je suis pas du tout convaincu. Dans la pratique c'est vachement rare de se faire flinguer par le manque de multiméthodes. Par exemple je vais du java au taf (ne moquez pas, ça me permet de me nourrir et de rester propre), c'est surtout le manque de sucre fonctionnel qui fait chier (et d'ailleurs le prochain C# en aura beaucoup apparemment), style map/grep, initialisation de listes statiques, fermetures. Après, ça dépend peut-être du type de programme et des connaissances ou du style du programmeur...
- [^]Re: Mes deux centimes ...
  
  Posté par harbort1 () le 08/10/2005 à 14:38. (lien). Évalué à 2.
  Bon, 10% c'était à titre indicatif ... mais jette un oeil aux moteurs 3D. Tous ceux que je connais (bon ça fait 2 ou 3 seulement) utilisent des systèmes complexe d'actions et de visiteurs pour au final recréer en C++ ou en Java les multi-méthodes.
  
  De mon côté j'ai déjà eu plusieurs cas où une multi-méthode aurait permis une factorisation élégante de mon code ! A la place ... bah je suis obligé de dupliquer ...
  - [^]Re: Mes deux centimes ...
    
    Posté par gc (page perso, ) le 08/10/2005 à 19:17. (lien). Évalué à 2.
    De mon côté j'ai déjà eu plusieurs cas où une multi-méthode aurait permis une factorisation élégante de mon code ! A la place ... bah je suis obligé de dupliquer ...
    
    En Java (je ne suis pas sur que tu parles de Java encore ou pas) je choisirais l'héritage multiple bien avant les multiméthodes. A cause du manque d'héritage multiple on se retrouve obligé de faire de la délégation kilométrique (ou pire). A mon avis ça manque bien plus.
    
    D'ailleurs à propos du manque d'héritage multiple, je me heurte sans arrêt aux javaïens qui me disent qu'il faut « concevoir différemment » mais je cherche toujours une solution au problème simple suivant :
    
    http://zarb.org/~gc/t/prog/lack_multiple_inheritance/(...)
    - [^]Re: Mes deux centimes ...
      
      Posté par Sylvain Sauvage () le 09/10/2005 à 13:08. (lien). Évalué à 6.
      Dans ton problème, tu prends la relation d'héritage à chaque fois que tu peux dire « est-un ». C'est une simplification qui est souvent utilisée pour enseigner l'OO mais rarement expliquée comme telle.
      
      Java a été conçu après 20 ans d'expériences en POO, après que l'on a pu conceptualiser pas mal de zones d'ombre. Et, à ce moment, l'on s'était rendu compte que l'héritage multiple posait beaucoup de problèmes et qu'il fallait faire une différence entre l'héritage de structure (classes) et l'héritage de comportements (interfaces). On s'est aussi rendu compte que la majorité des problèmes de l'héritage multiple sont dus à l'héritage multiple de structures (problèmes de l'héritage en diamant, p.ex.). On s'est aussi rendu compte que les autres cas d'héritage multiple sont relativement rares (comparativement aux ennuis) et facilement contournables par délégation.
      
      Maintenant, on s'apperçoit qu'il y a d'autres problèmes en POO, comme les aspects p.ex.
      
      Pour en revenir à ton exemple précis (que j'ai eu du mal à obtenir hier, d'où une réponse seulement aujourd'hui), tu fais plusieurs choix discutables, p.ex. que Laguna est une classe et que Renaut est une classe. Voiture est bien une classe, mais Renault est une instance de la classe Constructeur et Laguna une instance de la classe Modèle. Voiture aura donc deux attributs : constructeur et modèle.
      Alors tu me répondras : c'est de la délégation, c'est plus joli avec de l'héritage. Mais l'héritage n'a rien à voir dans ces relations. Le fait que tu puisses remplacer de l'utilisation (composition/aggrégation) par de l'héritage et que cela soit plus court à écrire n'est pas une raison pour le faire. Conceptuellement, ça ne tient pas.
      - [^]Re: Mes deux centimes ...
        
        Posté par gc (page perso, ) le 09/10/2005 à 17:21. (lien). Évalué à 4.
        Et, à ce moment, l'on s'était rendu compte que l'héritage multiple posait beaucoup de problèmes et qu'il fallait faire une différence entre l'héritage de structure (classes) et l'héritage de comportements (interfaces).
        
        Pourquoi ?
        
        Quand je me heurte concrètement à ce problème, les interfaces ne sont pas une solution pratique parce que je veux attacher des données ou du code en plus de l'API.
        
        On s'est aussi rendu compte que la majorité des problèmes de l'héritage multiple sont dus à l'héritage multiple de structures (problèmes de l'héritage en diamant, p.ex.).
        
        C'est a dire ? L'héritage en diamant me semble poser un problème dans l'implémentation du langage, pas pour le programmeur, je me trompe ?
        
        On s'est aussi rendu compte que les autres cas d'héritage multiple sont relativement rares (comparativement aux ennuis) et facilement contournables par délégation.
        
        D'une part je continue à penser que ça m'arrive bien plus souvent que le manque de multiméthodes, même si je suis d'accord que le besoin ne s'en fait pas sentir tous les jours[1]. D'autre part je continue à ne pas apprécier la délégation qui impose du code "dupliqué" au kilomètre.
        
        tu fais plusieurs choix discutables, p.ex. que Laguna est une classe et que Renaut est une classe. Voiture est bien une classe, mais Renault est une instance de la classe Constructeur et Laguna une instance de la classe Modèle. Voiture aura donc deux attributs : constructeur et modèle.
        
        C'est un exemple rapidement fait pour montrer qu'on peut avoir besoin de d'hériter de deux classes distinctes. D'ailleurs quelle est vraiment la différence ave le fait d'hériter d'une classe et d'implémenter une ou plusieurs interfaces ? Conceptuellement, on "suit", on "adhère" à différents "traits", "comportements", la seule différence est qu'on partage aussi des données ou du code dans un cas et pas dans l'autre. Je considère donc une interface comme une classe "réduite" mais je serais content qu'on me convainque du contraire ?
        
        Je vais te donner un autre cas concrêt qu'il m'est arrivé, et dis-moi ce que tu penses de la conception.
        
        Nous avons un ensemble de formes géométriques : Ligne, Rectangle, Polygone. On utilise une classe pour chacun, ce qui permet de stocker des données comme les deux points d'une Ligne ou les quatre points d'un Rectangle par exemple. On les manipule dans une application de calcul scientifique pour générer des espaces discrets.
        
        D'autre part, nous avons un éditeur graphique pour dessiner des formes géométriques. Chaque forme géométrique devra donc implémenter certains comportements supplémentaires, comme se dessiner dans un espace graphique, mais elles ont aussi toutes en commun de posséder une couleur. Cette couleur est une donnée, et on veut rajouter des accesseurs pour la manipuler. On veut aussi rajouter du code (une méthode) pour marquer visuellement que cette forme est sélectionnée (la couleur passera à une couleur fixée, le gris en l'occurrence). Cela a été implémenté (en C++) par une classe mère GtkForme, chaque forme géométrique héritant ensuite de cette classe pour obtenir la couleur, et de sa classe de forme géométrique de base pour hériter de ses coordonnées.
        
        Est-ce une mauvaise conception ? A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
        
        Alors tu me répondras : c'est de la délégation, c'est plus joli avec de l'héritage. Mais l'héritage n'a rien à voir dans ces relations. Le fait que tu puisses remplacer de l'utilisation (composition/aggrégation) par de l'héritage et que cela soit plus court à écrire n'est pas une raison pour le faire. Conceptuellement, ça ne tient pas.
        
        Uniquement parce que dans mon exemple tu suggères de remplacer des classes par des instances ? Est-ce que tu peux m'expliquer pourquoi il est conceptuellement correct d'avoir un héritage simple et de l'implémentation d'interface(s), mais pas correct d'avoir un héritage multiple ? (en fait cette question se rapproche beaucoup de ma question du paragraphe précédent)
        
        Enfin, pour mettre en perspective la pensée que l'héritage multiple est un symptôme de mauvaise conception, je citerais le fameux Craig R. McClanahan (monsieur struts, un des monsieur tomcat) dans la javadoc de org.apache.catalina.core.ApplicationHttpRequest (source de tomcat donc ) :
        
        * WARNING: Due to Java's lack of support for multiple
        * inheritance, all of the logic in ApplicationRequest is
        * duplicated in ApplicationHttpRequest. Make sure that you
        * keep these two classes in synchronization when making changes!
        
        [1] je rapproche d'ailleurs ce problème du manque de destructeur dans les GC dits "modernes" ou "vrais" (java, ruby) avec mark & sweep, par rapport aux GC dits "faux" (perl, python) fonctionnant par compteur de référence ; concrètement il est assez rare d'avoir besoin de destructeurs vrais (c'est à dire qui sont vraiment appelés quand l'objet est déscopé), mais quand on en a besoin c'est très chiant de ne pas en avoir ; surtout utile pour les IOs, et les gens de jakarta-httpclient (pour java) sont obligés d'imposer un HttpMethod#releaseConnection bien crade et bien chiant à cause de ça.
        
        [^]Re: Mes deux centimes ...
        
        Posté par serge_kara () le 09/10/2005 à 17:58. (lien). Évalué à 3.
        pour le coup du destructeur, c'est pas cense etre le but de la methode finalize()?
        
        [^]Re: Mes deux centimes ...
        
        Posté par Sylvain Sauvage () le 09/10/2005 à 22:35. (lien). Évalué à 5.
        Non, on est jamais sûr que finalize sera appelée. Cette méthode n'est appelée _que_ lorsque la VM veut réutiliser la mémoire utilisée par un objet qui n'est plus référencé. Si la VM ne réutilise pas la mémoire (p.ex. si elle termine ou si elle peut augmenter la mémoire allouée auprès du SE), finalize ne sera jamais appelé.
        
        [^]Re: Mes deux centimes ...
        
        Posté par serge_kara () le 10/10/2005 à 07:10. (lien). Évalué à 1.
        ok, au temps pour moi, j'avais pas vu sous cet angle la..
        
        [^]Re: Mes deux centimes ...
        
        Posté par Antoine () le 09/10/2005 à 21:25. (lien). Évalué à 4.
        je rapproche d'ailleurs ce problème du manque de destructeur dans les GC dits "modernes" ou "vrais" (java, ruby) avec mark & sweep, par rapport aux GC dits "faux" (perl, python) fonctionnant par compteur de référence ; concrètement il est assez rare d'avoir besoin de destructeurs vrais (c'est à dire qui sont vraiment appelés quand l'objet est déscopé)
        
        Si tu penses que __del__ en Python te garantit d'être appelé lorsque tu sors du "scope" où est défini l'objet, tu te gourres. Rien de tel n'est spécifié, d'ailleurs cela peut être faux selon l'implémentation (par exemple Jython). C'est une erreur courante de penser que __del__ est équivalent aux destructeurs C++.
        
        D'ailleurs, ton souhait n'a un sens que si la notion de "scope" a un sens pour les objets. En Python seuls les noms ont un "scope" alors que les objets vivent indépendamment dans leur monde à eux, quoiqu'ils soient susceptibles d'être détruits quand plus aucun nom ne les réfère directement ou indirectement.
        
        Pire, __del__ peut poser des problèmes avec la destruction de cycle :
        
        >>> class A: pass
        ...
        >>> a = A()
        >>> a.a = a
        >>> del a
        >>> class B:
        ... def __del__(self): print "hop"
        ...
        >>> b = B()
        >>> b.b = b
        >>> del b
        >>> import gc
        >>> gc.garbage
        []
        >>> gc.collect()
        4
        >>> gc.garbage
        [<__main__.B instance at 0xb7bed96c>]
        
        [^]Re: Mes deux centimes ...
        
        Posté par Damien (page perso, ) le 09/10/2005 à 22:12. (lien). Évalué à 3.
        Est-ce une mauvaise conception ?
        
        Non. En fait l'héritage multiple est bien. Ou plutôt serait bien si on savait l'implémenter correctement et rendre son utilisation claire dans le langage...
        
        A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
        
        Subtil troll :-) On peut faire des choses élégantes en C++ ?
        
        Personnellement je trouve les mixins ou les traits [1] bien plus clairs que l'héritage multiple. En gros, un trait est un groupe de méthodes, de la même manière qu'une interface est un groupe d'opérations (envoyer un message = appeler une opération, et la méthode est le code effectivement appelé en fonction du type de l'objet récepteur).
        
        Ça permet de réutiliser proprement du comportement (quand une classe utilise un trait c'est comme si elle incluait directement les méthodes, moyennant renommages ou oublis de méthodes si nécessaire, comme en Eiffel). Avec ça tu factorises tes méthodes gérant la sélection et la couleur de toutes les formes. Par contre comme un trait ne peut pas définir d'état, il faut que tu déclares ton attribut couleur toi-même (mais du coup plus de casse-tête ou de duplication d'attributs comme avec l'héritage multiple)
        
        [1] http://www.iam.unibe.ch/~scg/Research/Traits/(...)
        
        [^]Re: Mes deux centimes ...
        
        Posté par Sylvain Sauvage () le 10/10/2005 à 00:11. (lien). Évalué à 7.
        Ok. Ça va être long alors je coupe un peu. J'espère ne rien oublier...
        
        Pourquoi ?
        
        Je suppose que tu veux savoir pourquoi héritage structurel et héritage comportemental sont différents (si c'est « pourquoi l'héritage multiple pose problème », j'en reparle plus bas).
        
        L'héritage de structure, c'est lorsque l'on hérite des composants, des attributs, au niveau du modèle (donc lorsque l'on est proche du monde réel). Conceptuellement, il est très rare (même dans les cas d'école) d'avoir besoin d'hériter de plusieurs structures.
        P.ex. un Point2DColoré hérite d'un Point2D sa structure (en gros, x et y). Mais un Rectangle ne devrait pas hériter d'un Point2D : un rectangle peut être défini de bien des manières (= 2 points, = 1 point + largeur + hauteur, etc.) mais on ne peut pas dire « un rectangle est un point ».
        
        L'héritage de comportement, c'est lorsque l'on hérite de la façon de se comporter, des services donnés.
        P.ex. un Point2DTranslatable promet l'interface Translatable, tout comme un RectangleTranslatable.
        
        La différence entre classe et interface tient aussi de la différence entre type et classe.
        P.ex., une interface qui pour moi est simple et qui n'est incontestablement pas une classe, c'est Comparable. Deux entiers sont comparables entre eux, deux voitures peuvent être comparables entre elles (p.ex. suivant un ordre de préférence qu'aurait le programmeur), mais un entier n'est pas une voiture et une voiture n'est pas un entier. Par contre, grâce à ce type Comparable, je peux écrire une fonction de tri d'un tableau d'objets de ce type et je pourrais utiliser cette fonction sur un tableau de voitures ou un tableau d'entiers sans avoir à redéfinir la fonction et, ce qui est important¹, avec un typage fort.
        
        ¹ : c'est important ici car si le typage fort n'est pas dans le langage, alors les concepts ne sont plus les mêmes et la différence type / classe ne sert plus à rien.
        
        Pour éclairer un peu la différence type / classe, une variable a un type (en Java, C++...), et un objet a une classe et des types.
        
        Quand je me heurte concrètement à ce problème[...] l'API.
        
        Oui. P.ex. si je propose une interface Coloré pour mes points et rectangles : se pose le problème de l'attribut couleur qui a de fortes chances de se retrouver dans toutes les classes promettant le service.
        
        C'est parce que :
        - soit il fallait prévoir dès le début qu'un objet géométrique pouvait avoir une couleur (pas deux classes : Point2D et Point2DColoré mais seulement ObjetGéoColoré et les autres qui en héritent) ;
        - soit il faut utiliser un autre mécanisme, absent des primitives Java (mais que l'on peut simuler par délégation), les Mixin ou les Traits.
        
        C'est a dire ? L'héritage en diamant me semble poser un problème dans l'implémentation du langage, pas pour le programmeur, je me trompe ?
        
        Oui. Le classique cas: classe A avec attribut a, classe B et C qui héritent de A et classe D qui hérite de B et C. L'attribut a est hérité deux fois par D. Comment gérer ça ? Qu'est-ce que cela peut bien signifier ?
        Parfois, le programmeur voudrait deux a, parfois il n'en veut qu'un. C'est donc aussi un problème dans la tête du programmeur.
        
        D'autre part je continue à ne pas apprécier la délégation qui impose du code "dupliqué" au kilomètre.
        
        Des automatismes sont maintenant utilisés pour simplement noté qu'un attribut est en fait délégué et ses fonctions sont « proxysées » automatiquement.
        
        C'est un exemple rapidement fait [...]
        
        C'est un peu le problème avec tous les exemples que l'on me sort pour dire que l'héritage multiple est plus utile que néfaste ;o)
        
        D'ailleurs quelle est vraiment la différence ave le fait d'hériter d'une classe et d'implémenter une ou plusieurs interfaces ?
        
        Aucune et plein.
        Une interface est une classe abstraite, donc c'est une classe, donc on en hérite.
        Mais cela correspond à un héritage de comportement, pas de structure. (Voir plus haut type / classe...)
        
        Je vais te donner un autre cas concr[e]t [...] Est-ce une mauvaise conception ? A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
        
        Oui, c'est une mauvaise conception : le modèle de calcul (= les classes qui servent à représenter tes données géométriques) doit être découplé du modèle de dessin (UI).
        C'est le MVC.
        Ok. Tu vas me dire que tu dois dupliquer encore ton arbre d'héritage mais c'est à toi de choisir :
        - ou tu sépares proprement application et interface (c'est-à-dire que tu fais un modèle pour le calcul, un modèle-proxy pour donner à l'UI et une UI (avec ses objets à elle : widgets de toutes sortes)) ;
        - ou tu ne fais qu'un modèle qui mélange à la fois les structures et les services pour le calcul et pour l'UI.
        
        Uniquement parce que dans mon exemple tu suggères de remplacer des classes par des instances ?
        
        Tu admettras quand même que les concepts d'instance et de classe sont suffisamment distincts pour faire que, pour un même modèle, seulement un seul peut s'appliquer (c.-à-d. que tu n'as pas le choix entre l'un ou l'autre : il y en a un qui s'applique et l'autre qui ne veut rien dire).
        
        Est-ce que tu peux m'expliquer pourquoi il est conceptuellement correct d'avoir un héritage simple et de l'implémentation d'interface(s), mais pas correct d'avoir un héritage multiple ? (en fait cette question se rapproche beaucoup de ma question du paragraphe précédent)
        
        Conceptuellement, il y a un problème dans le cas du diamant : que veut dire hériter de deux fois la même structure ?
        
        Conceptuellement, l'héritage multiple englobe aussi les Mixin. (Ruby les différencie en utilisant des modules, j'aurais peut-être préféré un mot-clef mixin.)
        
        Donc, je ne dis pas que ce n'est pas correct, mais, comme on est parfois obligé lorsque l'on enseigne des concepts complexes, on exagère un peu les mises en garde (parce que tout le monde se croit assez malin pour les transgresser) en en faisant des interdictions (puisque, de toute façon, on peut s'en passer).
        Donc, comme la plupart des problèmes de l'héritage multiple (tous ?) se posent pour l'héritage de structure multiple, une solution pour les éviter est de l'empêcher. Par contre, l'héritage multiple de services ne pose pas de problème (si deux services ont le même nom, ils doivent représenter la même chose, sinon il y a un problème de nommage dans le modèle).
        
        Enfin, pour mettre en perspective la pensée que l'héritage multiple est un symptôme de mauvaise conception [...]
        
        Je pense en fait que l'on est en train d'arriver à des concepts plus précis.
        
        Au départ, il n'y a que l'objet, tout est objet, blabla... Mais on s'est vite rendu compte qu'il y avait plein de concepts différents et on a pas encore fini de les différencier correctement. On différencie maintenant héritage de structure et de services, on parle d'aspects, de mixins... Il faut encore poser tout ça pour que ça ressemble à quelque chose.
        
        [1] je rapproche [...]
        
        1. Le GC de Java fonctionne aussi avec compteur de références. Je pense que tu voulais plutôt dire que le nettoyage est, dans un cas, seulement fait lorsqu'il y a besoin de place, et dans l'autre cas, dès que la référence arrive à zéro.
        
        2. Pour les histoires de propreté avec les E/S etc., il est à mon avis bien plus propre de le faire explicitement (et même dans le finally d'un try pour être bien sûr que c'est fait).
        
        [^]Re: Mes deux centimes ...
        
        Posté par golum () le 10/10/2005 à 08:53. (lien). Évalué à 3.
        Je ne sais pas si j'ai bien compris ton pb concret. Mais en général la délegation n'implique pas de dupliquer le bout de code à tout bout de champ comme tu le prétends
        
        Soit A une interface avec un méthode m.
        On crée une classe B qui implémente l'interface A avec un comportement par defaut et uniquement cette interface
        
        Lorsqu'on on a besoin d'implementer l'interface A dans une classe C qui hérite d'une autre classe et qui impléménte peut-être d'autres interfaces. On se contente d'encapsuler une instance b de B et dans l'implementation de m dans la classe C on se contente d'appeler b.m().
        
        Ce qui manque dans la sémantique des langages est justement la délégation. Je ne sais plus où j'avais lu ca mais il suffirait
        de dire. pour la méthode m de C:
        void m() delegates to c
        
        Les avantages de cette technique, outre la factorisation sont que tu peux simplement changer d'implémentation par défaut en créant une nouvelle classe D d'implémentation par défaut, en ne changeant que la classe de l'instance c encapsulée dans la classe C.
        
        L'autre avantage par rapport au mutil-héritage cette fois, c'est que le couplage est faible et dynamique. Ainsi si Renault se fait racheter par un autre boîte tu peux changer l'instance de constructeur que la voiture agrège, si tu veux changer de classe mère, il te faudra un langage qui supporte ce comportement ou supprimer et recréer une instance de la voiture et remplacer toutes les references à cette voiture. Une autre paire de manche.
        
        [^]Re: Mes deux centimes ...
        
        Posté par golum () le 10/10/2005 à 09:06. (lien). Évalué à 3.
        
        C'est a dire ? L'héritage en diamant me semble poser un problème dans l'implémentation du langage, pas pour le programmeur, je me trompe ?
        
        Je ne pense pas, le pb est bien pour le developpeur.
        
        Soit une classe A qui définit une méthode m.
        Soit B et C qui héritent de A et qui redéfinissent m.
        Soit D qui hérite de B et C mais qui ne redéfinit pas m.
        Quel redéfinition de m va utiliser un appel à la méthode de m par une instance de D ? Le langage résoudra le pb (descente en profondeur d'abord pour Pyhton par exemple) , mais le developpeur devra l'anticiper. Pour certains langages ,il peut indiquer explicitement la méthode m de la classe mère qu'il souhaite utiliser. Mais dans la réalite la classe B a pu n'être créer qu'après la classe D. Donc il faut repasser sur tout le code utilisateur pour désambiguer, ce qui va à l'encontre des concepts d'evolutivité de l'appproche objet.
        
        [^]Réponse groupée
        
        Posté par lcld () le 10/10/2005 à 11:50. (lien). Évalué à 5.
        
        Sylvain Sauvage :
        Oui. Le classique cas: classe A avec attribut a, classe B et C qui héritent de A et classe D qui hérite de B et C. L'attribut a est hérité deux fois par D. Comment gérer ça ? Qu'est-ce que cela peut bien signifier ?
        Parfois, le programmeur voudrait deux a, parfois il n'en veut qu'un. C'est donc aussi un problème dans la tête du programmeur.
        
        golum :
        Soit une classe A qui définit une méthode m.
        Soit B et C qui héritent de A et qui redéfinissent m.
        Soit D qui hérite de B et C mais qui ne redéfinit pas m.
        Quel redéfinition de m va utiliser un appel à la méthode de m par une instance de D ? Le langage résoudra le pb (descente en profondeur d'abord pour Pyhton par exemple) , mais le developpeur devra l'anticiper. Pour certains langages ,il peut indiquer explicitement la méthode m de la classe mère qu'il souhaite utiliser. Mais dans la réalite la classe B a pu n'être créer qu'après la classe D. Donc il faut repasser sur tout le code utilisateur pour désambiguer, ce qui va à l'encontre des concepts d'evolutivité de l'appproche objet.
        Le C++ prévoit très bien ce cas avec la présence ou non du mot-clé 'virtual'.
        Soit une classe de base A avec un membre a, plusieurs classes B0, B1... Bn qui hérite de A, et une classe C qui hérite de B0, B1... Bn. A la définition de 2 classes Bi et Bj, si le mot-clé 'virtual' apparaît pour A, alors A sera le même -> structure en diamant. Autrement, à la définition d'une classe Bi où 'virtual' n'apparaît pas, Bi aura sa propre copie de A.
        Dès lors que le mot-clé 'virtual' est absent pour un Bi, il y a conflit dans C et il faudra préciser le Bi.
        Ca manque d'image ? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vc(...)
        
        Je suis d'accord. Qu'est-ce que tout cela peut bien signifier.
        Peut-on encore parler d'héritage ou juste de sucre syntaxique.
        En C++, il ne faut plus voir une utilisation de l'héritage comme étant systématiquement de l'héritage. Quelle différence entre class B : private A {}; et class B { A a; }; ?
        Une implémentation en C++ n'est plus un simple calque du diagramme UML. Mais en l'absence de syntaxe pour déléguer facilement, je suis bien content d'avoir l'héritage multiple.
        
        [^]Re: Réponse groupée
        
        Posté par golum () le 10/10/2005 à 12:47. (lien). Évalué à 2.
        Intéressante ta précision pour le C++. Je me souvenais du mot clé virtual pour les méthodes mais plus pour les classes. Ici ca désambigue la structure.
        Mais concernant le comportement si la méthode m() est redéfinie dans B (virtual A)
        et C (virtual A) mais pas dans D? Comment ca se passe si j'appelle d.m(). Il faut que le code appelant caste avec la bonne superclasse pour le polymorphisme ?
        
        Même si ca permet d'aller plus loin que de la simple délégation de comportement (où il n'y a pas d'héritage en diamant puisque mono-héritage), ca commence à ressembler à un casse tête.
        L'approche délégation à au moins le mérite d'expliciter le mécanisme au niiveau du diagramme UML et reste simple à appréhender.
        
        En tout cas ca ne change rien sur le fond, c'est bien au programmeur de prendre en charge la problématique et ce dès la conception.
        Et ca me conforte dans l'idée qu'une syntaxe de delagation serait plus que suffisante.
        
        [^]Re: Réponse groupée
        
        Posté par lcld () le 10/10/2005 à 13:27. (lien). Évalué à 2.
        Comment ca se passe si j'appelle d.m().
        "error"
        
        Il faut que le code appelant caste avec la bonne superclasse pour le polymorphisme ?
        Possible mais on écrira plutôt d.B::m() ou d.C::m().
        
        [^]Re: Réponse groupée
        
        Posté par golum () le 10/10/2005 à 13:28. (lien). Évalué à 2.
        C'est bien ce que je pensais .
        
        Merci
    - [^]Re: Mes deux centimes ...
      
      Posté par d-jo (page perso, ) le 10/10/2005 à 11:26. (lien). Évalué à 5.
      D'ailleurs à propos du manque d'héritage multiple, je me heurte sans arrêt aux javaïens qui me disent qu'il faut « concevoir différemment » mais je cherche toujours une solution au problème simple suivant :
      
      http://zarb.org/~gc/t/prog/lack_multiple_inheritance/(...)(...)
      
      J'aimerai comprendre ce qui te chagrine. Parceque mis à part le fait que java n'est pas du C++. On peut quand même faire quelque chose du genre :
      
      abstract class Voiture {
      public int getVitesseMin() { return 0; }
      public abstract int getVitesseMax();
      }
      
      interface Marque {
      public abstract String getPaysOrigine();
      }
      
      abstract class VoitureRenault extends Voiture implements Marque {
      public abstract int getVitesseMax();
      public String getPaysOrigine(){return "France";}
      }
      
      //Rappelons l'implémentation pour être lisible
      class Laguna extends VoitureRenault implements Marque {
      public int getVitesseMax() { return 200; }
      }
      
      class TestVoiture{
      public static void main( String args[] ) {
      VoitureRenault v = new Laguna();
      System.out.println( "Pays d'origine Laguna : " + v.getPaysOrigine() );
      System.out.println( "Vitesse max Laguna : " + v.getVitesseMax() );
      
      }
      }
      
      Ça me semble assez propre
      - [^]Re: Mes deux centimes ...
        
        Posté par gc (page perso, ) le 10/10/2005 à 12:53. (lien). Évalué à 2.
        Voir l'exemple avec les formes géométriques et le besoin d'héritage multiple lorsqu'on veut faire un éditeur graphique pour ces formes, dont je parle un peu plus haut en réponse à Sylvain.
        
        [^]Re: Mes deux centimes ...
        
        Posté par Pierre Tramonson () le 11/10/2005 à 08:38. (lien). Évalué à 3.
        Moi non plus comme Sylvain je ne vois pas le besoin d'héritage multiple dans ces exemples.
        On peut très bien s'en passer à mon avis.
        Si on rencontre des cas où on a besoin d'hériter de plusieurs classes à la fois, n'est ce pas parce que la classe mère n'est pas assez complète ?
        
        [^]Re: Mes deux centimes ...
        
        Posté par d-jo (page perso, ) le 11/10/2005 à 08:54. (lien). Évalué à 2.
        Je rajouterai qu'on peut également faire une classe fille pour en compléter d'autres sans que celà pose de problèmes.
        
        Regarde l'exemple des Streams en java. Tu les emboites pour rajouter des fonctionnalitées sans avoir besoin d'héritage multiple.
        
        abstract class Abs{
        /*...*/
        }
        
        class A extends Abs{
        /*....*/
        }
        
        class B extends Abs{
        public B(A a){
        /*....*/
        void ajoutD1Methode{/*...*/}
        }
        
        [^]Re: Mes deux centimes ...
        
        Posté par golum () le 11/10/2005 à 09:11. (lien). Évalué à 2.
        C'est même un motif de conception:
        "Chaine de resposabilité"
        http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern(...)
        
        [^]Re: Mes deux centimes ...
        
        Posté par gc (page perso, ) le 11/10/2005 à 10:31. (lien). Évalué à 3.
        Moi non plus comme Sylvain je ne vois pas le besoin d'héritage multiple dans ces exemples.
        On peut très bien s'en passer à mon avis.
        
        Alors montre concrètement comment faire pour modéliser l'exemple avec les formes géométriques.
        
        Si on rencontre des cas où on a besoin d'hériter de plusieurs classes à la fois, n'est ce pas parce que la classe mère n'est pas assez complète ?
        
        Tu restes dans la théorie. Raisonne sur mon exemple. Je ne vois pas en quoi les classes mères de formes géométrique ou la classe mère des formes éditables graphiquement sont incomplètes.
        
        J'en profite pour répondre à sa réponse pour pas te laisser faire la même :
        
        - ou tu sépares proprement application et interface (c'est-à-dire que tu fais un modèle pour le calcul, un modèle-proxy pour donner à l'UI et une UI (avec ses objets à elle : widgets de toutes sortes)) ;
        
        Ca veut dire quoi séparer proprement ? Je vais pas m'amuser à dupliquer (proxy) pour le plaisir d'avoir un beau design qui plait aux théoriciens. Avoir plusieurs classes permet de "séparer", et au contraire je trouve bien plus élégant de réutiliser dans l'interface des composants du backend (hériter de ses classes). On est ici dans un cas de réutilisabilité utile et pratique.
        
        Dans la pratique, le backend définit des classes pour des formes géométriques avec des données précises ; dans l'interface je veux éditer ces formes géométriques, je trouve ça troublant de suggérer de ne pas utiliser ces classes existantes.
        
        - ou tu ne fais qu'un modèle qui mélange à la fois les structures et les services pour le calcul et pour l'UI.
        
        Je ne comprends pas ce que ça veut dire (est-ce que parler de « services » est une façon cachée de parler d'interfaces ?).
        
        [^]Re: Mes deux centimes ...
        
        Posté par Sylvain Sauvage () le 11/10/2005 à 16:02. (lien). Évalué à 3.
        Je vais répondre dans le désordre, ça évitera les redites.
        
        Je ne comprends pas ce que ça veut dire (est-ce que parler de « services » est une façon cachée de parler d'interfaces ?).
        
        Services, interface (au sens Java ou CORBA), fonctions, méthodes, comportements, ça représente à peu de choses près la même chose : les messages auxquels l'objet peut répondre.
        
        Ca veut dire quoi séparer proprement ? Je vais pas m'amuser à dupliquer (proxy) pour le plaisir d'avoir un beau design qui plait aux théoriciens.[...] existantes.
        
        Cela dépend de ce que tu veux au final. P.ex. si tu veux pouvoir réutiliser la partie calcul avec une UI totalement différente ou si tu es à peu près sûr que cela ne te reservira jamais.
        
        Dans tous les cas tu réutilises les classes existantes, mais pas de la même façon, donc pas avec les mêmes avantages/inconvénients.
        
        En gros, tu as trois façons :
        1. une seule hiérarchie ou tu mélanges tout,
        - avantage : tout au même endroit ;
        - inconvénients : tout au même endroit, pas de modularité, ce n'est plus du couplage fort, c'est de la fusion ;
        - avis personnel : vilain, caca, pouah, pas glop !
        2. une hiérarchie calcul et une hiérarchie UI, avec les classes de l'UI qui utilisent (agrégation) les classes calcul,
        - A : couplage faible entre calcul et UI ;
        - I : une indirection supplémentaire (pour accéder à une donnée, il faut passer par l'agrégé ) ;
        3. une hiérarchie calcul et une hiérarchie UI, avec les classes de l'UI qui héritent des classes de calcul,
        - A : couplage plus faible que 1. ;
        - I : mais plus fort que 2. ;
        - autre A : un peu moins d'indirections ;
        - autre I : confusion possible entre utiliser et hériter.
        
        Je pense qu'hériter au lieu d'utiliser est une mauvaise chose car ce sont deux mécanismes conceptuellement différents. Ce que tu proposes c'est d'utiliser l'héritage à la place de l'agrégation pour
        - raccourcir le code (mauvaise raison) ;
        - simuler un mixin (meilleure raison mais encore faut-il :
        1. le savoir ;
        2. le noter (commentaires)).
        
        Maintenant, tout ce que je dis ne sert à rien et n'avancera à rien si, comme pourrait sembler le faire penser l'exemple Laguna, tu ne fais pas la différence entre hériter et utiliser.
        
        [^]Re: Mes deux centimes ...
        
        Posté par gc (page perso, ) le 12/10/2005 à 08:03. (lien). Évalué à 1.
        Je pense qu'hériter au lieu d'utiliser est une mauvaise chose car ce sont deux mécanismes conceptuellement différents. Ce que tu proposes c'est d'utiliser l'héritage à la place de l'agrégation pour
        - raccourcir le code (mauvaise raison) ;
        - simuler un mixin (meilleure raison mais encore faut-il :
        1. le savoir ;
        2. le noter (commentaires)).
        
        Je propose d'hériter puisque lorsque je veux éditer visuellement une forme, le "concept" dont j'ai besoin est clairement pour moi "une forme qui possède des propriétés supplémentaires", donc ça me parait clair que ca tient complètement de "is_a" et pas du tout de "has_a". Une forme visuellement éditable est une forme, et en plus elle est visuellement éditable.
        
        Maintenant, tout ce que je dis ne sert à rien et n'avancera à rien si, comme pourrait sembler le faire penser l'exemple Laguna, tu ne fais pas la différence entre hériter et utiliser.
        
        Au moins tu n'y vas pas avec le dos de la cuillère.
        
        [^]Re: Mes deux centimes ...
        
        Posté par Sylvain Sauvage () le 12/10/2005 à 16:42. (lien). Évalué à 3.
        
        Je propose [...] éditable.
        
        Oui et non.
        
        Oui, car on peut considérer qu'une forme éditable est bien une spécialisation d'une forme.
        
        Et non, car on peut considérer que ce n'en est pas une ; p.ex. parce qu'une forme éditable est une représentation manipulable d'une forme-de-calcul, et la relation « est une représentation manipulable » peut être considérée comme de l'utilisation. De plus, suivant les différences d'utilisation, en gros le nombre d'attributs et de fonctions utilisés seulement dans le calcul ou seulement dans l'UI, il peut être intéressant d'avoir une classe mère commune et abstraite (mais qui n'empêche pas la relation « est une représentation manipulable » de se retrouver sous la forme d'une agrégation).
        
        Au passage, je serais enclin à penser que les classes internes à la hiérarchie devraient être abstraites (= pas d'instance).
        
        Prenons un autre cas, celui des objets CORBA. Les objets qui passent dans les tubes CORBA ont besoin d'être du même type pour pouvoir être manipulés de la même façon, ils ont aussi besoin d'une structure commune pour contenir un état relatif à CORBA. En plus, les types CORBA sont déjà organisés en hiérarchie. Les objets CORBA sont donc des classes.
        
        Maintenant, on a déjà nos classes et nous voulons les CORBAtiser.
        Si nos classes héritent déjà d'autres classes qui ne sont pas CORBAtisables, comment leur donner la possibilité d'être CORBAtisables ?
        
        Une solution est la délégation, et on se retrouve avec des classes helper, holder et des fonctions d'indirection (p.ex. _this pour récupérer l'objet CORBA correspondant à this). Certains trouvent cela élégant. D'autres trouvent cela très lourd et très moche. (Moi, ça dépend des jours :o)
        
        Une autre solution est l'héritage multiple (hériter de CORBA::Object en plus de son héritage normal). Mais cet héritage n'est pas de la même sorte que l'héritage précédent (qui est un héritage dû à la modélisation : on est proche du « monde réel » modélisé, la CORBAtitude est un aspect de la mise en ½uvre du système d'information, pas de son modèle). Mélanger les deux héritages (le premier est « conceptuel », le second (CORBA) est « pratique ») dans le code n'est pas considéré comme très propre. Certains aiment, d'autres non.
        
        Une troisième solution est le mixin : la CORBAtitude est un aspect, un ensemble de services, ajouté à la classe et il existe aussi en dehors de la classe (pas forcément sous la forme d'une classe complète). C'est la solution que je préfère : elle est propre conceptuellement et claire dans le code.
        
        Pour revenir aux formes géométriques et sur le fait q'une « forme visuellement éditable est une forme, et en plus elle est visuellement éditable », et pour expliciter le fait que l'on peut considérer que non, on peut prendre l'exemple d'un formulaire pour une BD : le formulaire contient des champs et donc une structure similaire à celle de l'entrée de la BD qu'il permet d'éditer. Pourtant, dans ce cas, je vois mal quiconque soutenir que la classe Formulaire devrait hériter de la classe ObjetDeLaBDquivabien (même si les champs du formulaire ne sont pas directement représentés par des Textfield). Avec les formes géométriques, la séparation est plus subtile : on avait String contre Textfield pour le formulaire, avec les formes, on a ensemble de points contre ensemble de points, mais on peut toujours discuter de cette distinction.
        
        Pour finir, il faut aussi dire que les discussions sur des cas théoriques, dont le « monde réel » est coupé ou mal cerné, peuvent être considérées comme de la masturbation intellectuelle. Dans un cas réel, il y a toujours différentes solutions, chacune avec ses avantages et ses inconvénients, et les circonstances feront en choisir une. Dans la théorie, il n'y a pas d'absolu, tout est discutable.
        
        Au moins tu n'y vas pas avec le dos de la cuillère.
        
        Ben si, j'ai dit « pourrait sembler le faire penser » :oP

[^]Et perl 6

Posté par Sytoka Modon (page perso, ) le 07/10/2005 à 19:18. (lien). Évalué à 5.
> connaissance, seul LISP dans les langages répandus permet la
> création de multi-méthodes.

Depuis le début de cette discution, tout çà me fait penser à Perl6.

Car s'il y a un nouveau langage qui ne veut pas suivre le 100% OO et s'amuse à mettre plein de concepts de manière plus ou moins orthogonale, c'est bien celui là. En plus, c'est une construction communautaire.

Bref, que du sympathique.

Comme d'habitude....

Posté par woopla () le 07/10/2005 à 06:59. (lien). Évalué à 9.

... Le problème se situe entre la chaise et le clavier.

A mon avis, ca n'est pas une question de méthode, de langage ou de buzzwords, mais de volonté des développeurs.

Pourquoi je dis ca ? En microélectronique, on utilise des langages de description matérielle qui s'apparentent à des langages de programmation, e.g. VHDL et Verilog. On peut considérer que les designers font du développement, avec des sources qui peuvent être conséquentes, etc. Et pourtant les bugs sont minimums. Il y en a bien quelques uns de temps en temps, mais ils sont tellement rares que ca fait presque la une des journaux (cf le bug FDIV du Pentium).

Si les bugs sont rares, c'est parce que faire une erreur ca coûte très cher - avec des jeux de masques qui coûtent actuellement dans les 50M d'euros, et qu'il faut refaire dès qu'il y a une correction à apporter, on fait gaffe. Le problème, c'est que info beaucoup de développeurs se disent que c'est pas très grave s'il

Journal : Repenser les langages et le développement logiciel

Ouf

[^]Re: Ouf

[^]Re: Ouf

[^]Re: Ouf

[^]Re: Ouf

Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

[^]Re: Bof

J'étais en train d'essayer de lire et de tout capter.... quand ...

[^]Re: J'étais en train d'essayer de lire et de tout capter.... quand ...

[^]Re: J'étais en train d'essayer de lire et de tout capter.... quand ...

Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Réponse groupée

[^]Re: Réponse groupée

[^]Re: Réponse groupée

[^]Re: Réponse groupée

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Re: Mes deux centimes ...

[^]Et perl 6

Comme d'habitude....