Journal Repenser les langages et le développement logiciel

Posté par  (site web personnel) .
Étiquettes : aucune
0
7
oct.
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 ?

  • # Ouf

    Posté par  (site web personnel) . Évalué à 10.

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

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

    • [^] # Re: Ouf

      Posté par  (site web personnel) . É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 ;-)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Ouf

        Posté par  (site web personnel) . É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.

        • [^] # Re: Ouf

          Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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 :-)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Bof

        Posté par  . É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  (site web personnel) . É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  (site web personnel) . É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..

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Bof

            Posté par  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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.

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Bof

                Posté par  . É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.

                • [^] # Re: Bof

                  Posté par  (site web personnel) . É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 !

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Bof

            Posté par  (site web personnel) . É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  (site web personnel) . É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é.

            • [^] # Re: Bof

              Posté par  . É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  . É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  . É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  . É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  . É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  . É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 .

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

    Posté par  . É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  (site web personnel) . É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 ?

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

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

        Posté par  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . Évalué à 3.

                pour le coup du destructeur, c'est pas cense etre le but de la methode finalize()?

                • [^] # Re: Mes deux centimes ...

                  Posté par  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . É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: Mes deux centimes ...

            Posté par  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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 y a des bugs, ils pourront toujours ressortir une nouvelle version.

    Tant qu'une bonne partie des développeurs ne seront pas dans cet état d'esprit, les plus beaux langages du monde n'y changeront rien...

    PS : ta NDR sur l'origine du mot bug est fausse. Ca vient tout simplement du fait que les insectes aimaient bien venir se coller sur les tubes (chauds !) des premiers ordinateurs, et que ca pouvait causer des problèmes sur les tubes en question.

    • [^] # Re: Comme d'habitude....

      Posté par  (site web personnel) . Évalué à 8.

      "On peut considérer que les designers font du développement, avec des sources qui peuvent être conséquentes"

      je ne dis pas que c'est pas complexe aussi, mais en microelectronique, on est :

      - En systeme fermé
      - Avec des entrees sorties tout a fait caractérisees, bornées.

      Bref, le rêve pour un developpeur.

      Ce n'est malheureusement pas comparable a l'envirronemment de développement logiciel.

      Avec le logiciel, on est confronté à :

      - Multiplicité des configurations de l'os, rendant impossibles les tests par le developpeurs sur toutes lse plates-formes (os, noyaux, patches, etc...)

      - Multiplicité du materiel rendant impossibles les tests par le developpeurs sur toutes lse plates-formes (intel, ppc, ram, ddram, cartes video differentes, souris, pad, vitesse de bus, taille de l'ecran, etc...)

      - Multiplicité des entrées-sorties rendant impossibles les tests de toutes les combinaisons possible (les cas de tests de courverture complete sont tres rare, voire inexistants en cas réels.)

      - Contexte (autres logiciels en marche qui modifient le comportement de l'ordinateur)

      Tout ca rend tres difficile le développement... et le débogage encore plus : le plus grand probleme étant souvent d'arriver a reproduire un bug, tellement le nombre de conditions a remplir est grand.

      "Si les bugs sont rares, c'est parce que faire une erreur ca coûte très cher"
      c'est le cas en developpement de gros logiciels... combien coute une Ariane explosée ou une journée de panne SNCF a ton avis ?

    • [^] # Re: Comme d'habitude....

      Posté par  (site web personnel) . Évalué à 2.

      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 y a des bugs, ils pourront toujours ressortir une nouvelle version.

      Et ils ont raison, tu le démontres toi même :)

      D'ailleurs faire des programmes prouvés c'est possible, c'est réalisé dans certains domaines critiques/importants. Et même par exemple dans les jeux vidéos pour console il y a très peu de bugs puisque l'éditeur sait très bien qu'il ne pourra pas patcher.

      • [^] # Re: Comme d'habitude....

        Posté par  . Évalué à 10.

        D'ailleurs faire des programmes prouvés c'est possible, c'est réalisé dans certains domaines critiques/importants.

        C'est possible pour des cas tres precis, et ca s'arrete la, des que la complexite du soft est trop grande ca devient impossible.

        Et même par exemple dans les jeux vidéos pour console il y a très peu de bugs puisque l'éditeur sait très bien qu'il ne pourra pas patcher.

        Il y a tres peu de bugs car :

        - Le materiel est fige
        - Les conditions du systeme sont figees aussi, il n'y a pas un OS avec scheduler qui interrompt pour faire tourner la tache Y, etc... qui tourne dessous

        resultat, quand les gars testent le jeu sur la console, ils sont quasiment sur de passer par le cheminement que l'utilisateur suivra et deceleront les bugs avant lui dans la plupart des cas, alors que sur des PC ayant 3000 configurations differentes, dans des conditions de lancement differentes, c'est tres loin d'etre le cas. Bref, il pourrait y avoir des dizaines et dizaines de bugs dans un jeu de console, simplement ils ne sont pas dans les chemins de code que 99% des clients voient, alors que pour un jeu sur PC, les chemins de code les plus courants sont plus divers et la les bugs se voient.

        Le developpement de jeux ne change quasiment pas entre la version PC et la version console, c'est tres tres souvent un code commun, ca n'empeche pas la version PC de planter.

    • [^] # Re: Comme d'habitude....

      Posté par  . Évalué à 6.

      pas de volonté des développeurs, mais ceux qui leur donnent des ordres et un salaire (indice, ils ont une cravate et promettent n'importe quoi). on les appelle des décideurs. ils ont des objectifs, et des clients à livrer.

      les développeurs sont rarement aux commandes et ont leur employeur, leurs supérieurs comme premier clients.

      le seul reproche qu'on peut leur faire est de ne pas dire non quand il faut

  • # python because it fits your brain

    Posté par  . Évalué à -1. Dernière modification le 24 août 2019 à 15:31.

    Personnellement je crois énormément à un langage comme python.

    Il n'y a qu'a aller faire un tour sur le livre de recette (http://aspn.activestate.com/ASPN/Cookbook/Python/ pour s'en rendre compte. En effet son introspection et sa flexibilité (dynamique+presque tout peut être changé) permet d'exprimer de nouveaux concepts clairement.

    Autre lieu illustratif : le blog de Philip Eby (http://dirtsimple.org.) Les fonctions distribuées par prédicas (prédicate dispatch) ne sont qu'un exemple de ce que l'on peut exprimer clairement en python (je précise que ces concepts viennent de lisp).

    Perso je pense que ce qui peut réellement révolutionner l'informatique est aussi l'intelligence artificielle, mais elle ne remplacera pas la programmation. Peut-être que l'intelligence artificielle sera le guide, les programmes les organes. (mais là je deviens un agitateur de mains!).

    • [^] # Re: python because it fits your brain

      Posté par  (site web personnel) . Évalué à 9.

      A part faire de la pub pour ton langage préféré en nous disant qu'il va révolutionner ta life et enlarger ton 5ème membre, tu nous expliques le rapport avec le journal ?

      • [^] # Re: python because it fits your brain

        Posté par  . Évalué à 2.

        Euh, désolé si mon commentaire est apparu comme tel.
        Pour ma part c'était une approche plus pragmatique mais pour répondre aux même exigences dans le sens ou je pense que l'on peut aller loin en partant d'une base et en modifiant modifiant modifiant....
        Notament, l'ajout de rêgles prolog dans le langage, la reformulation d'un langage par dessus l'autre.... et je ne sais quelle autre (r)évolution...
        Mon commentaire en fait voulait ouvrir sur les langages dit agiles et le typage dynamique vu comme une solution d'avenir.
        Perso, quand on parle du fil du télégraphe, je le vois comme une limitte plus forte dans les langages à typage static. Les langage dynamique + exceptions ... ne compte pas que sur ce message de type télégraphique.

        • [^] # Re: python because it fits your brain

          Posté par  (site web personnel) . Évalué à 3.

          La problématique est ici de réduire le nombre de bugs dans des projets conséquents.
          Python et les langages à typage dynamique n'ont jamais aidé dans ce sens, de part leur nature.

          • [^] # Re: python because it fits your brain

            Posté par  . Évalué à 2.

            ceic ressemble pour moi à un a priori.
            Pour moi le typage dynamique fait partie des choses qui apportent l'expressivité et plus d'expressivité = potentiellement moins de bug.
            C'est en tout cas ce que semble dire Victoria Livschitz (mais j'avoue que je n'ai pas lu l'article original).
            Maintenant c'est une approche, celle en laquelle je crois plus. Je ne dis pas qu'il n'y en a pas d'autres.
            Pour chasser le bug je crois aussi beaucoup aux tests (et leur automatisation). Le test me semble un peu ce que la physique expérimentale est à la phisique théorique (le programme source dans l'analogie).

            • [^] # Re: python because it fits your brain

              Posté par  (site web personnel) . Évalué à 4.

              Montre moi un morceau de code en Python qui apporte une expressivité conséquente, susceptible de produire moins de bug.
              Un langage dynamique est avant tout permissif avant d'être expressif.
              Evidemment que les tests contribuent à améliorer la qualité du code.
              Mais c'est une vérité générale, appliquée depuis longtemps, mais qui ne résoud absolument pas le problème de la complexité des grands projets.
              Ici on cherche d'éventuelles nouvelles approches, Python n'a absolument rien de révolutionnaire, et les tests unitaires sont plutôt au stade de pratique industrielle extrêment courante.

              Ah oui une autre question : combien de projets en Python de plusieurs millions de ligne de code ont été produits dans des délais impartis par un cahier des charges ? (bref pas un logiciel libre avec un roadmap "dynamique" si tu vois ce que je veux dire)

              • [^] # Re: python because it fits your brain

                Posté par  . Évalué à 1.

                Bon ce sera mon dernier commentaire car je ne cherche pas la confronattion.
                Pour l'expressivité, j'ai déjà cité le python cookbook qui contient des exemples très intéressants. Les décorateurs sont en eux même un bon exemple. Encore un exemple : SQLObject.
                Un exemple de la puissance que porte l'expressivité : Zodb
                Un bon exemple de projet python conséquent est, je pense, Erp5 qui avait remporté un prix 01 Informatique l'année dernière.

                Pour ce qui est des tests je suis d'accord avec toi, je ne le liais pas à Python dans mon commentaire.

                • [^] # Re: python because it fits your brain

                  Posté par  (site web personnel) . Évalué à 3.

                  Nan mais donne moi un morceau de code qui me montre la puissance de Python en diminuant le nombre potentiel de bug.
                  Quand à Erp5, j'ai dis pas un logiciel libre, qui pour la plupart ne répondent pas à un besoin spécifique à un temps donné avec un temps et un coup imparti.

                  • [^] # Re: python because it fits your brain

                    Posté par  . Évalué à 2.

                    Tu n'a pas regardé ce que je te dis ! Peut être avec plus d'url, je pensais qu'un petit google suffirait.

                    Erp 5 est un logiciel certes libre mais qui a été livré en temps et en heure pour un industriel (ce qui a valut le prix) http://pythonology.org/success&story=nexedi(...)

                    Pour les bout de codes python : http://sqlobject.org/SQLObject.html#declaring-the-class(...)
                    et regarde le nombre de ligne de ce projet. Hibernate pour faire la même genre de chose en a 10 fois plus et doit manipuler le bytecode. Si ça ce n'est pas un facteur qui réduit les bugs !

                    C'est mon opinion, je conçois que tu en ai une différente, j'ai donné assez d'élément pour te permettre de comprendre sur quoi repose cette conviction.

                    Je sais que tu vas encore me répondre que non c'est pas ça mais moi je m'arrête là.
                    Je suis désolé mais je n'ai pas le temps de poster 10.000 message.
                    A une prochaine !

                    • [^] # Re: python because it fits your brain

                      Posté par  (site web personnel) . Évalué à 1.

                      Oué enfin tu vois j'ai pas envie de me taper toute la doc et le cvs pour aller y décrouvrir les quelques lignes de Python révolutionnaire. Je voulais que tu me donne l'exemple de code académique.
                      Pour Erp 5 effectivement j'avais pas approfondi.

                      • [^] # Re: python because it fits your brain

                        Posté par  . Évalué à 3.

                        Justement l'intérêt de python c'est que tu n'as pas besoin de te taper la doc pendant 5 ans pour en voir l'intérêt. Il n'y a rien de révolutionnaire là dedans, juste que de ne pas avoir à ce casser la tête pour comprendre le langage lui-même permet de se casser la tête pour autre chose, les specs par ex dont on a vu qu'elles étaient bien plus importantes.

                        Pour ce qui est des millions de lignes de code, on a vu aussi que c'était une abération de conception et qu'il faut impérativement découper tout ça en de plus petits projets. Donc chercher des exemples de mauvaise conception pour voir comment on s'en est sortie quand même n'as aucun intérêt.

                        Une ligne de python révolutionnaire ? c'est simple : print "hello world"

                        Pourquoi c'est révolutionnaire ? parcequ'on peut rester simple pour ce qui est simple.

                        L'exemple le plus connu est la comparaison entre la lecture d'un fichier en java et en python...

          • [^] # Re: python because it fits your brain

            Posté par  . Évalué à 2.

            Ha bon ? demande à google pour voir ;-)

            Si les langages de la nature de python aident à réduire le nombre de bugs c'est tout simplement parcequ'ils sont agréable à utiliser. Se faire plaisir en programmant est sûrement la meilleure garantie contre les bugs. L'esprit humain est ainsi fait, et non seulement de logique. Il n'y a qu'à regarder un enfant à l'oeuvre, s'il s'amuse ça marche, s'il se fait chier il n'avance pas. Les statistiques montrent par exemple que les personnes qui font de l'informatique à la maison (pour le plaisir) n'ont pas du tout les même problèmes (douleur au dos, maux de tête etc.) que ceux qui travaillent.

  • # Erlang

    Posté par  (site web personnel) . Évalué à 5.

    Le langage que tu décris, basé sur le passage de message asynchrone existe: Il s'appelle Erlang (http://www.erlang.org)(...) et a été conçu pour permettre de réaliser des applications industrielles robustes, scalables et tolérantes aux pannes.

    Le langage est orienté concurrence. Il manipule des processus plutôt que des objets.Une des approches pour réduire le nombre de bugs dans le langage est l'expressivité du langage: Le nombre de bugs dans un code est plus que proportionnel par rapport au nombre de lignes de code. Réduire le nombre de lignes de code réduit considérablement le nombre de bug.

    Il se trouve qu'Erlang a été utilisé avec succès sur des très gros projets industriel chez Ericsson (entre autres).

    --
    Mickaël Rémond
    http://www.3pblog.net/(...)

    Mickaël

  • # dsqdsq

    Posté par  (site web personnel) . Évalué à 9.

    J'ai un peu du mal à trouver une cohérence à l'ensemble de l'article mais bon y'a des réflexions intéressantes :)

    Ca commence par un constat : y'a des bugs.
    Oué bah oué. Au niveau langage on a déjà atteind l'objectif de perfection dans ce domaine : convertir tout programme en preuve mathématique.
    Exemple : langage formel B. Tu peux t'assurer qu'il n'y a pas de bug dans le programme. Mais on arrive à un constat : bien que le programme est correct, on n'obtient pas le résultat escompté : pourquoi ?

    L'article laisse sugérer des bugs "architecturaux". Les bugs sont tout simplement dans les spécifications elles-même. On s'en rend compte en utilisant les langages de type langage B : toute la difficulté consiste à poser sur le papier TOUTES les spécifications, et des spécifications justes.

    Et là on sort des langages informatiques, les spécifications sont écrites (dans un premier temps avant d'êtres traduites en langaeg formel) en langage naturel. Difficile de trouver plus intuitif. Malheuresement si cette étape là n'est pas correcte, tout ce qui en découlera ne pourra pas l'être.
    Hors plus un logiciel est complexe, plus ses spécifications sont conséquentes, et plus il est difficile de les appréhender et de les formaliser sur le papier.

    D'où l'idée qui date pas d'hier de découper le problème en sous-problème, INDEPENDAMENT de tous langages informatique.

    Après coder les spécifs reste relativement simple et automatique si celles-ci sont correctes.

    Voilà tout ca pour dire qu'il ne faudrait pas faire l'erreur d'introduire trop de complexité dans le langage en introduisant de nouveaux concepts, alors que paradoxalement cela aurait été fait dans le but de mieux appréhender la complexité de la tâche à accomplir.

    Un langage doit être là pour fournir des outils permettant au programmeur d'exprimer la plus large gammes de concepts et d'idée. La seule véritable contrainte, c'est de faciliter la solution n°1 : découper le problème en sous-problème. Bref, proposer la sémantique de grosses et petites boîtes. Le concept objet est parfait pour cela.

    • [^] # Re: dsqdsq

      Posté par  . Évalué à 2.

      Un langage doit être là pour fournir des outils permettant au programmeur d'exprimer la plus large gammes de concepts et d'idée. La seule véritable contrainte, c'est de faciliter la solution n°1 : découper le problème en sous-problème. Bref, proposer la sémantique de grosses et petites boîtes. Le concept objet est parfait pour cela.

      C'est tout a fait exact; l'OO permet une approche verticale du problème.
      Seulement, il y a des problématiques transverses qui impactent plusieurs classe sans liens hiérarchiques entre elles (logging, persistence, ...)

      Et là son petit frère l'Aspect promet beaucoup.

      AOP+OOP et le maillage est complet

      http://www.aopsys.com/aop.html(...)

    • [^] # Re: dsqdsq

      Posté par  (site web personnel) . Évalué à 2.

      1/ Tout le monde n'est pas capable de maîtriser B et même les bases de la logique. Tu fait partie d'une élite, ne l'oublie pas :-) Voir mes posts plus haut.

      2/ Les spécifications peuvent être limitatives en soi, par exemple UML qui t'impose de découper en hiérarchie d'objets avec mono-héritage.


      3/ Découper en sous problème, fort bien, mais l'idée de mon journal et de V.L est que l'OO oblige souvent à des contortionnement pas possible pour gérer des choses simple ( cause à effet, protocole basé sur le temps, etc...) et que l'on pourrait mieux découper en élément simple avec des primitives un peu plus fourni que l'héritage et le polymorphisme.

      Et je le répète, Timaniac : tout le monde n'a pas ton (excellent) niveau, ne l'oublie pas :-)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: dsqdsq

        Posté par  (site web personnel) . Évalué à 6.

        1/ Tout le monde n'est pas capable de maîtriser B et même les bases de la logique. Tu fait partie d'une élite, ne l'oublie pas :-) Voir mes posts plus haut.
        C'est justement là où je voulais en venir : la difficulté n'est pas de coder en soit, mais de réussir à formaliser toutes les spécifs, parcque la plupart du temps on fait confiance à notre intuition qui nous "vas y fonce t'as à peu prêt capter, code !"
        B nous force à écrire ce qu'on croit savoir de manière intuitive, et c'est là que justement on tombe sur de nombreux problèmes : spécifs foireuses, absente ou partielle, etc.
        Soit on veut un truc sans bug, c'est possible mais ca prend ouachement de temps (à poser nickel les spécifs), soit on prend une solution intermédiaire, en posant plus ou moins bien les spécifs.

        Ce que je veux dire, c'est qu'il n'y pas de miracle : tant qu'on n'a pas réussi à mettre "carr"" les spécifs, on ne codera rien sans bug. Et l'intuition va souvent à l'encontre de cet objectif en court-circuitant l'étape de la mise au "carré".

        2/ Les spécifications peuvent être limitatives en soi, par exemple UML qui t'impose de découper en hiérarchie d'objets avec mono-héritage.
        gni ? Tu peux faire du multi-héritage. Et je vois pas trop le rapport avec UML, UML est un langage de modélisation, pas de spécification.

        l'OO oblige souvent à des contortionnement pas possible pour gérer des choses simple
        ? Un exemple ?
        Non parcque en objet tu peux tout modéliser, à n'importe quel niveau d'abstraction. Un objet peut être une entité de donnée comme une entitée manipulant des données ou un concept de baeucoup plus haut niveau, il peut encapsuler un protocole, une notion temporelle, il y a une liberté totale.
        Donne moi un exemple qui demande des contorsions en objet.

      • [^] # Re: dsqdsq

        Posté par  . Évalué à 3.


        2/ Les spécifications peuvent être limitatives en soi, par exemple UML qui t'impose de découper en hiérarchie d'objets avec mono-héritage.

        Où es-tu allé pêcher ca! La notation UML supporte parfaitement l'héritage multiple (c'est juste un ptite flêche en plus). Le fait de le contourner par une délégation est défini au moment de la conception en fonction du langage cible(C++ vs Java) ou pour des besoins de souplesse du modèle.
        Cette approche à l'avantage d'eviter les ambiguités d'heritage (héritage diamant) et de rendre les liens dynamiques (héritage = lien fort et permanent)

        Par contre , il est evident que si les paradigmes objets ne t'intéressent pas , UML ne va pas te servir à grand chose(hormis les use case).

        Donc tout ca c'est très bien mis si tu inventes une nouvelle sémantique tu devras créer un nouveau langage mais aussi tout ce qui va avec , notation, méthode projet .... .

  • # ...

    Posté par  . Évalué à 2.

    Je sais pas si ca existe, si ca a été abordé dans ce journal ou quoi que ce soit mais depuis un ptit moment je pense à un truc : avec les avancées qu'on a fait en IA ces dernières années pourquoi personne n'a inventé un "programmeur virtuel" : un moyen de décrire un problème qui soit compréhensible par un programme d'intelligence artificiel qui s'occuperais d'écrire le code qui soit à même de résoudre ce problème. Exemple : je veux classer des données qui ont tel format dans tel ordre. Je décris ce problème dans le langage qui va bien et je le donne à manger à mon "programmeur virtuel" et il me pond le code dans le langage que je veux. L'interet de cette méthode est qu'on pourrait faire en sorte que le "programmeur virtuel" code proprement et vérifie qu'il ne crée pas de bugs...

    • [^] # Re: ...

      Posté par  (site web personnel) . Évalué à 3.

      " avec les avancées qu'on a fait en IA ces dernières années"

      Lesquelles ?
      Les IA est tres loin de pouvoir faire le "programmeur virtuel"

      Ton probleme est un peu le probleme du compilateur des langages formels... cf http://fr.wikipedia.org/wiki/Langage_formel(...)

      • [^] # Re: ...

        Posté par  . Évalué à 2.

        Je sais pas lesquelles (je suis pas expert dans ce domaine) mais il me semble quand même que de gros progrès ont été fait en la matière depuis ces 10 ou 20 dernières années (même si à l'echelle de l'informatique 20 ans représente beaucoup de temps). Enfin peu-être que dans 20 ans on aura fait sufisamment de progrès pour en arriver la...

        • [^] # Re: ...

          Posté par  (site web personnel) . Évalué à 3.

          Pas de progres ces 10-20 dernieres années du coté theorique.

          En pratique on peut plus facilement les appliquer. Par exemple, les reseaux de neurones demandant beaucoup de puissance de calculs, on commence a s'en servir (la théorie date des années 80).
          Pour des problemes comme celui-la il faudrait des avancées théoriques significatives...

  • # "Management", Modules et Apprentissage.

    Posté par  (site web personnel) . Évalué à 3.

    pour résoudre le problemes des bugs et des couts associes :

    Management => Extreme programming. (programmation par paires, test unitaires, client-dev synchro le + possible, etc...)

    Modules => Utilisation de librairies, modules le plus possible (revient a decouper en petit probleme les grands). L'Open Source donne ici de grands résultats.
    Un bon exemple est de developpement de jeux video (million de dollars de budgets) lire ce papier :
    A FLEXIBLE AND EXPANDABLE ARCHITECTURE FOR COMPUTER GAMES Jeff Plummer => http://www.jeffplummer.com/Writings/Thesis/Thesis_with_Appendix.pdf(...)

    Apprentissage => Tous les developpeurs devraient connaittre par coeurs les motifs de conception basique. (design patterns du gof)

    Pour l'écriture de logiciel moins complexe, mon opinion personnelle:

    Plus un language est de haut niveau, moins les "programmeurs" l'utilisant ont a manier de concept abstrait.

    On va vers la multiplicité des languages et leurs adaptation a la tache (qui explique le succes de php pour le web, le succes de VB pour excel et access).

    Quand on recupere des sources VB et PHP, on le voit bien : Pas de fonction, que des variables globales, pas de gestion memoires, etc... et souvent les codeurs sont pas tres vieux.
    Mais ca marche.

    Pour les taches complexes non standard (pas du web, access, excel), il faut assembler des modules en langage de bas niveau pour gagner en expressivité du langage (et ne surtout pas tout recoder soi-meme.)
    C'est tout le succés de Java de proposer des librairies standard tres etoffées, l'assemblage est alors tres simple, et le gain en expressivité est tres vite réalisé.

    • [^] # Re: "Management", Modules et Apprentissage.

      Posté par  (site web personnel) . Évalué à 3.

      Pour l'écriture de logiciel moins complexe, mon opinion personnelle:

      Plus un language est de haut niveau, moins les "programmeurs" l'utilisant ont a manier de concept abstrait.
      Moi j'ai l'opinion inverse : plus le langage est de haut niveau, plus il laisse le temps au programmeur de manipuler des concepts abstraits, bref à se focaliser sur la conception de l'appli.

      Tu parles du succès de VB et PHP : ce n'est pas tant le fait qu'ils soient des langages de haut niveau (tu parles plus bas de Java qui est d'aussi au niveau), c'est qu'ils sont des langages "simples" et accessibles aux débutants.

      "Pas de fonction, que des variables globales, pas de gestion memoires, etc... et souvent les codeurs sont pas tres vieux.
      Mais ca marche."
      Ca marche, je dirais plutôt ca marchouille : mais c'est pas réutilisable, c'est inmaintenable, bref, c'est rarement concluant. Ou alors il faut revenir en arrière en suivre la démarche traditionnelle contenant étape de conception avec expression de concepts de haut niveau etc. Auquels cas ces langages deviennent tout de suite moins adaptés.


      Apprentissage => Tous les developpeurs devraient connaittre par coeurs les motifs de conception basique. (design patterns du gof)
      Tout à fait : mais t'en vois beaucoup dans les projets PHP/VB codés par des geeks de 13 ans ?
      Bof hein :)

      • [^] # Re: "Management", Modules et Apprentissage.

        Posté par  (site web personnel) . Évalué à 2.

        Tu as raison, je reformule ma pensee :
        Plus un language est de haut niveau, moins les "programmeurs" l'utilisant ont a manier de concept informatique abstrait. (fonction, variables, memoires, objets, heritages, etc...)

        Pour VB et PHP je donnais des pistes de leurs succes aupres de "apprenti codeurs" capable de coder des logiciels complexes qui marchent. On est d'accord, c'est un nid a problemes... mais ils arrivent a leur fins et c'est la le point que je voulais souligner :
        Ce qu'ils arrivent a faire la, il ne pourraient le faire avec des languages plus bas niveau.


        Il faut bien differencier les 2 pistes dans mon post:

        ->codage simple : sans apprentissage de concepts informatiques)

        ->resoudre le probleme de couts, bug des logiciels complexes : la il faut renforcer l'apprentissage de concepts (comme les designe patterns) permettant a l'informaticien d'exprimer ses intuitions plus facilement.

  • # Facteur limitant II : La revanche

    Posté par  . Évalué à 10.

    Hello,

    Journal intéressant, mais malheureusement,

    "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."

    Et la marmotte, elle empaquete le chocolat dans le papier d'alu ?

    Dans la vraie vie et même à horizon de 10 à 20 ans, même si on sort un langage super balèze qui par conception divise en moyenne le nombre de bugs par 100, je peux te garantir que les décideurs pressés n'en auront rien à battre de l'intuition et de l'expérience du développeur qui de toute façon sera chinois, indien ou autre, et à qui on enverra des spécifications monolithiques mal ficelées, dans un mauvais anglais et qui seront toujours codées en VB, C, PL/SQL ou autre.

    Bon courage quand même,

    Enzo Bricolo

  • # Facteur limitant II : La revanche

    Posté par  . Évalué à -2.

    Hello,

    Journal intéressant, mais malheureusement,

    "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."

    Et la marmotte, elle empaquete le chocolat dans le papier d'alu ?

    Dans la vraie vie et même à horizon de 10 à 20 ans, même si on sort un langage super balèze qui par conception divise en moyenne le nombre de bugs par 100, je peux te garantir que les décideurs pressés n'en auront rien à battre de l'intuition et de l'expérience du développeur qui de toute façon sera chinois, indien ou autre, et à qui on enverra des spécifications monolithiques mal ficelées, dans un mauvais anglais et qui seront toujours codées en VB, C, PL/SQL ou autre.

    Bon courage quand même,

    Enzo Bricolo

  • # Système multi-agents (SMA)

    Posté par  (site web personnel) . Évalué à 5.

    Salut,

    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

    J'écris juste pour dire que j'ai touché un peu aux SMA. C'est plutôt sympa, et ça se code facilement. En particulier, j'ai expérimenté l'écriture d'un jeu en Python :
    http://www.happyboom.org/Accueil(...)

    En gros, on utilise deux modes de communications :
    - inter-agents : les messages sont déposés dans une boîte au lettre, et l'agent les récupère à l'itération suivante (on appelle une fonction live() à chaque "itération" du serveur)
    - événementiel : on lance un événement qui est reçu par zéro ou plusieurs "handler"

    Les deux modes permettent d'envoyer un message à zéro ou plusieurs entités. C'est quelque chose de nouveau pour moi. Ca permet de développer son agent dans son coin, sans se soucier des autres. Les agents intéressés par tel ou tel message n'ont qu'à le demander.

    Bon, on utilise aussi des événements classiques 1 => 1, car c'est plus rapide et pratique à certains endroits (et pour des raisons de sécurité aussi ...).
    ---
    Pour ceux qui ne voyent pas le rapport avec le journal : c'était pour parler des SMA, modèle qui pourrait servir à de nombreux projets, et pour dire que les SMA peuvent s'implémenter dans les langages classiques.

    Haypo

    • [^] # Re: Système multi-agents (SMA)

      Posté par  . Évalué à 3.

      événementiel : on lance un événement qui est reçu par zéro ou plusieurs "handler"

      Euh... Est-ce que c'est pas tout simplement du signal/slot ca ?

      Il me semble parce qu'en effet:
      pour dire que les SMA peuvent s'implémenter dans les langages classiques.
      Cf Boost.Signals[1] pour dire que ca existe meme en C++

      [1] : http://www.boost.org/doc/html/signals.html(...)

      • [^] # Re: Système multi-agents (SMA)

        Posté par  (site web personnel) . Évalué à 3.

        En dehors de tous langages, c'est le patron de conception observateur, qui peut être implémenté dans à peu prêt tous les langages, pas que C++.

        http://www.dofactory.com/Patterns/PatternObserver.aspx(...)

        • [^] # Re: Système multi-agents (SMA)

          Posté par  (site web personnel) . Évalué à 3.

          Je ne suis pas d'accord avec cette conception consistant à implémenter des modèles en utilisant les outils disponibles. Les outils sont mal adaptés, il faut donc les refaire.

          C'est le coeur de ce qu'explique V.L. : si on veut utiliser des métaphores (la métaphore agent dans le cas qui nous occupe) qui facilite le développement et flatte l'intuition du développeur, il faut créer, dans la syntaxe et dans les axiomes même du langages les relations que l'on peut se prendre la tête à gérer "à la main" avec des objets.

          L'idée c'est que le compilateur va vraiment optimiser ce qu'il faut et pondre un binaire qui correspond à ce que tu veux faire.
          Toi le développeur, tu n'as pas à te prendre la tête à réinventer la roue avec tes quatres concepts de bases que tu possède.


          Autrement dit, bien évidemment que tu peux créer ce que tu veux avec peu d'axiomes (voir LISP), mais il faudrat tout le temps que tu te prenne la tête à tout reconstruire et repenser à chaque fois.
          On peut toujours décider que l'on va dessiner un aditionneur binaire avec la seule porte NON-ET (c'est possible), mais avoir les portes OU, ET, NON, XOR, ça te permet de moins te prendre la tête.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Système multi-agents (SMA)

            Posté par  (site web personnel) . Évalué à 3.

            Tout à fait d'accord, du moment que ca reste justement des "patrons" simples et courament utilisé, sinon le langage risque de devenir trop complexe et/ou élitiste/trop spécialisé.

            Maintenant cela m'amène à une question : le langage doit-il se contenter de s'adapter au programmeur, ou doit-il innover en poussant le programmeur ?

            • [^] # Re: Système multi-agents (SMA)

              Posté par  (site web personnel) . Évalué à 2.

              Les deux mon général.

              Le langage doit permettre au programmeur d'exprimer son intuition ie. en lui évitant de passer des heures à formaliser on intuition

              Le langage doit aussi pousser le programmeur à utiliser d'autres manière de conceptualiser. Mais il faut être très prudent avec ça, car beaucoup de programmeur (voir le fil plus haut sur ce point) n'ont pas la curiosité nécéssaire pour les travailler. N'oublions pas que pour beaucoup d'entre eux, coder est un métier alimentaire, à défaut de mieux et pour éviter le travail en usine...

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Système multi-agents (SMA)

      Posté par  (site web personnel) . Évalué à 1.

      C'est marrant, il y a pas mal d'idée que j'ai défini il y a quelques temps, suite à mon histoire de sous-marin.
      Je l'avais à l'époque conçu comme une extension à lisaac (et j'en cherchais les axiomes pour savoir comment modifier le compilo) mais j'ai envie de travailler un peu moin superficiellement dedans et de voir un plus loin et profondément sa conception pour intégrer des choses radicalement nouvelles comme le fait de dépasser les grammaires LR, LL pour inégrer un embryon d'analyse grammatical un peu plus proche des langages naturels avec un espèce de pigdin (un parler "petit nègre") ou un agent demande aux autres "Toi donner moi pièce d'or".
      Il s'agirai de construire le graphe grammatical de la phrase et ensuite d'en interpréter le sens.

      Je recopie les spécifs que j'avais couche sur le papier à l'époque (il y a 2 mois) :

      - Envoi de messages point à multipoints. Les messages peuvent être envoyés nominativement par leur adresse email ou par des conditions sur leur propriétés ontologiques (voir ontologie, arborescence de données). La syntaxe de l'entête message est le même qu'une entête de fonction lisaac. On propose un mécanisme à la XSL qui permet de définir des conditions fines d'agents éligibles à la reception du message.


      - Arborescence de données, non explicitement ontologique au début, mais changera un jour. Il s'agit de définir une arborescence de données, un cousin syntaxique de XML. On pourra lancer des requêtes de calcul sur ces données.


      - Possibilité de choisir entre asynchronisme et synchronie.


      - Possibilité de choisir entre message express et message ordinaire, le premier permettant d'interrompre une tâche de l'agent à n'importe quel moment pour traiter le message.
      L'agent peut posséder quelques fonctions qui définissent l'entretien de la tâche de l'agent. Une sorte de trigger, autonome, s'exécutant régulièrement ou tout le temps pour maintenir l'« organisme » de l'agent. On pourra définir une politique d'exécution spécifiant par exemple que tel fonction s'exécute 16 fois par secondes, ou que tel message doit être envoyé si un paramètre de l'arborescence est modifié, atteint une certaine valeur, ensemble de valeur, etc... L'agent « Bateau ennemi », si sa position s'approche d'un certain rayon de 30 pixels, envoi un message à la base pour demander procédure réparation, l'agent modifie son comportement en tâche de fond vers un processus d'amarage à la base. On peut définir une IA. On peut définir plusieurs comportement et même réinitialiser les agent pour marquer un nouveau comportement, une nouvelle nature (agents transformer par exemple... *joke)

      - On défini le « ring » qui est un groupe de systèmes multi-agent (SMA) ayant la faculté de s'échanger un message. On peut définir n ring. A creuser : Est-ce qu'on autorise l'échange de messages inter ring et là je vois pas l'intérêt du ring, ou alors habiller le concept, ou est-ce qu'on limite à l'appel objet classique ? Ou à la limite on interdit l'envoi de messages express. C'est l'idée que les communautés doivent négocier entre elles, sans s'interrompre. Un ring est l'association de toutes les arborescences de ses agents, il est lui même un agent qui peut trouver sa place dans un autre ring. C'est le principes des SMA dans lesquel un SMA peut être lui même un agent d'un autre SMA récursivement.

      - Un service de mail avec adresses du type « identite@typeagent.ring ». Gère la file d'attente des messages ordinaires et express(on vide la file d'attente des express en priorité, puis celle des messages ordinaires), la gestion de l'historique (c'est l'idée que les messages peuvent consituer une database dans laquelle on peut puiser), l'horodatage. Voir feuille
      section INIT pour gérer les != réinitialisations si changement de comportement
      - Concurrence : possibilité de contraindre l'exécution d'un block à une limite de temps.



      Pour gérer les messages express, il faut une gestion de thread temps réel, c'est mieux. Et on aimerai l'intégrer dans l'IsaacOS.

      Après il faut que j'y réfléchisse, et il faut que j'en discutte avec des linguistes.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Mon avis de moi

    Posté par  . Évalué à 10.

    Il y a beaucoup de propos intéressants sur cette page ... et beaucoup de langages aussi (Caml, B, ... ca me rappelle l'école). Mais je suis de l'avis de woopla (eux aussi d'ailleurs ;-p http://www.thinkgeek.com/tshirts/sysadmin/6692/):(...)
    Le problème se situe entre la chaise et le clavier.

    au moins pour 80% des cas! Le langage n'est que secondaire.

    ** Constatations **

    Les langages actuels sont certes insuffisants pour exprimer la richesse du monde mais la source primaire des bugs (AMHA) ce sont les personnes travaillant sur le projet. N'est pas développeur de logiciels qui veut. Si, me direz-vous, avec des outils style VB (malheureusement :-(). Je n'ai rien contre ceux qui travaillent avec VB, j'en fait d'ailleurs occasionnellement partie de par mon travail, mais VB vulgarise un peu trop à mon goût le développement d'applications. Pour qu'un programme soit fiable (sans bug ou presque), il faut de bon concepteurs (c'est-à-dire des gens qui réfléchissent à ce qu'il faut réellement faire et comment le faire), des analystes expérimentés qui proposent des solutions techniques (environnement, langages, ...), de bon pisseurs de lignes (qui codent rigoureusement en commentant leurs sources) et enfin de bons testeurs (en unitaire et en intégration). Ca ne résoud pas 100% des bugs mais devrait déjà faire avancer pas mal le schimilibilibilick.

    Allons plus loin, la source de la source, c'est l'argent. Pour être compétent, un développeur/analyste/testeur/pisseur doit avoir étudié la théorie (les maths, le paradigme objet, ...) et doit avoir de l'expérience ... donc va coûter cher à l'entreprise. Et généralement, un DSI préfère prendre un BAC+2 sorti de la fac, le former sur le tas et le payer à coups de bambous, quitte à ce que son boulot ne soit pas « top moumoute » mais qu'il arrive rapidement sur le marché (tant pis, on sortira un service pack ;-)) que de prendre des gens compétents (mais qui vont prendre plus de temps à produire et vont coûter + cher).

    [digression philosphique]
    Pour aller encore plus loin, la source de la source de la source, c'est l'homme: avide d'argent et de technologie pour le conforter dans sa paresse intellectuelle, il en veut toujours plus et contraint le système à aller vite, trop vite pour bien faire.
    [/digression philosphique]

    ** Conclusion **

    A « comment réduire le nombre de bug ? », je répondrais donc « en ayant la volonté de le faire ! ».

    ** Conclusion : la vraie **

    Non je déconne, le problème n'est pas aussi simple. Il est vrai qu'il y a encore beaucoup de travail pour améliorer les langages actuels : l'absence de typage strict des variables en PHP ou Javascript, la possibilité d'omettre la déclaration des variables en VB, le non typage des Objects d'un tableau en Java pre-1.5, l'absence d'assertions natives dans de nombreux langages.

    A ce titre, je proposerai un nouveau langage à la liste déjà longue évoquée ici: Eiffel (et son compilo GNU http://smalleiffel.loria.fr/).(...) On y trouve une implémentation du paradigme objet + poussée qu'en Java, un système de pré et post conditions sur les fonctions, ... des concepts très intéressant permettant une vérification accrue du code à la compil et à son exécution. Pas encore suffisant objecterez-vous, certes mais c'est un petit pas pour l'homme :-)

    Pour conclure, tout est affaire de perte acceptable: puis-je me permettre d'aller vite au détriment de la stabilité (pour des raisons commerciales le + souvent) (Mysql 5.0, Tomb Raider 1 à 6) ou est-ce que je dois prendre mon temps et limiter les bugs au maximum (A380)?

    Sur ce ...

    à non j'oubliais!

    la gestion des exceptions (ndr :les contrats)
    Les contrats n'ont, sauf erreur de ma part due au temps écoulé depuis mes cours de théorie OO, rien à voir avec les exceptions. Un contrat défini un ensemble de règles qu'un client doit respecter. En Java comme en IDL, c'est décrit par des interfaces qui énumèrent les méthodes que doit implémenter une classe cliente (le contrat qu'elle doit respecter).

    • [^] # Re: Mon avis de moi

      Posté par  . Évalué à 3.

      un contrat peut être "la méthode RacineCarree(x) ne peut être employée qu'avec x >= 0"

      et à l'éxecution (éventuellement seulement en mode debug), une assertion, exception ou équivallent sera lancée si RacineCarree s'aperçoit que x < 0

    • [^] # Re: Mon avis de moi

      Posté par  (site web personnel) . Évalué à 3.

      \o/ mon avis de moi aussi !

      J'irais même plus loin : le typage statique c'est une optimisation prématurée.

      En fait le typage est juste un contrat comme un autre (et un peu un problème de documentation ou de nommage). Les systèmes de typage statique qui fournissent une réelle assistance plutôt qu'une contrainte sont rares et complexes (O'Caml j'en suis pas fana, mais j'ai lu du bien de Haskell...)

      Poser des contrats (pré/post-conditions surtout, invariants un peu moins) sur les méthodes est TRÈS efficace pour localiser les erreurs : quand ça explose, le contrat localise très vite l'origine de l'erreur (et pas sa conséquence, comme avec une backtrace).

      À mon avis, une approche très efficace à la fois pour éviter les bugs techniques et les problèmes de compréhension des specs est une combinaison de méthodes agiles / XP / test-driven-development avec un langage typé dynamiquement encourageant la conception par contrats.

    • [^] # Re: Mon avis de moi

      Posté par  (site web personnel) . Évalué à 3.

      la gestion des exceptions (ndr :les contrats)
      Les contrats n'ont, sauf erreur de ma part due au temps écoulé depuis mes cours de théorie OO, rien à voir avec les exceptions. Un contrat défini un ensemble de règles qu'un client doit respecter. En Java comme en IDL, c'est décrit par des interfaces qui énumèrent les méthodes que doit implémenter une classe cliente (le contrat qu'elle doit respecter).

      Je me suis mal exprimé, j'ajoutais la notion de contrat que V.L a oublié de lister.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Mon avis de moi

      Posté par  . Évalué à 2.

      Autant pour moi les gars, et merci de me remettre sur le droit chemin ;-)

  • # Nouveaux matériels

    Posté par  . Évalué à 5.

    De ce que je retiens des articles (enfin de leur traduction et des posts), deux choses sont mises en avant :

    l'utilisation de langage de haut niveau
    l'utilisation de concept le plus proche possible de l'objet à modéliser


    Pour résumer grossièrement la chose (et pour exposer le fruit de mes méditations personnelles) on peut dire :
    "On doit coder en fonction de ce qu'on code, et non pas de qui code, et de comment ou sur quoi il code".

    Jusque là je suis d'accord. Le principe est de séparer au maximum le codeur de l'aspect matériel du problème.

    Est-ce que les nouvelles orientations matérielles (par exemple le Cell) peuvent-elles etre compatibles à cela ? J'ai surtout eu l'impression que l'idée est "ce machin roxxe, si et seulement si le développeur pense qu'il doit coder comme si et comme ca". Pas très cool.

    D'autre part, je voulais faire part d'une critique sur les articles : les propositions du style "un projet de 30.10^45 lignes est trop complexe pour les humains actuellement". Il semble qu'une des exigences est qu'une personne comprenne à elle seule l'ensemble du projet. Pour comparer, c'est un peu comme si on avait dit avant de construire la tour Effeil (ce n'est pas un message subliminal, je ne connais pas le programme du meme nom) "Chaque poutre est cruciale, un homme ne peut pas avec les moyens actuels appréhender toute la complexité du projet, ca va se péter la gueule".
    La solution (meme si elle ne révolutionne rien (dommage) ni n'enlève les problèmes de bugs), et comme il a été dit plus haut le découpage en sous problèmes : chaque mec check son bout de code, et il existe des types qui ont à vérifier que les bouts de codes s'assemblent bien entre eux. En un mot : modularisation.

  • # Mhmm, du po-gnon

    Posté par  (site web personnel) . Évalué à 8.

    Qu'est-ce qui fait que d'autres industries ne livrent peu ou pas d'erreur, alors que tous les grands produits et projets informatique (ou presque) s'abîment dans un océan de problèmes ? Le pognon.

    On le sait bien, tant qu'on peut rogner sur le budget, on rogne. Le problème, dans l'aviation, le génie civil, les médicaments, la mécanique, etc., c'est que quand on rogne, on tue, alors on dépense le pognon qu'il faut pour ne pas tuer. Et en général, ça signifie qu'on se débarasse au passage de tous les problèmes sérieux. (Et ces industries ne sont d'ailleurs pas parfaites, on a des exemples de rognages excessifs qui ont tué).

    En informatique, quand on rogne, on plante, et en général, y'a pas mort d'homme. (Et bizarrement dans les cas où il peut y avoir mort d'homme, on sort le pognon et on a beaucoup moins de bugs.) Bon, on perd plein d'argent, mais les grands chefs sont rarement a quelques millions près, c'est le client, le contribuable ou l'employé qui paye, donc on s'en fout un peu.

    Alors non la solution aux bugs de l'industrie n'est pas un nouveau langage ou un nouveau paradigme qui induisent moins de bugs. Un langage qui induit moins de bugs, ça ne sert qu'à se lancer dans des projets plus grands, plus gros, plus chers qu'avant. La proportion de bugs a baissé, mais le projet est plus gros : il y a donc autant de bugs.

    Non franchement, une seule solution pour faire baisser les bugs : cracher les thunes, prendre le temps qu'il faut. La NASA l'a fait pour ses navettes, par exemple, et leur programme de contrôle est bien la seule chose qui n'ait pas été critiquée au lendemain de l'explosion de Challenger ; les experts ont même souligné son exemplarité.

    Mais attention, si on allonge le blé et les délais, on ralentit aussi l'évolution de l'informatique. Est-ce que finalement les bugs n'ont pas été un prix à payer pour vivre avec joie un tel foisonnement technologique ?

    Le logiciel libre aurait-il pu naître sans les bugs    , dans un monde où tous les systèmes informatiques sont spécifiés dans le détail et sans erreur par les services recherche et développement marketing de grandes corporations ? La force du logiciel libre n'est-elle pas justement d'avoir une réactivité face aux bugs et aux demandes d'évolution nettement meilleure que celle des gros industriels ?

    • [^] # Re: Mhmm, du po-gnon

      Posté par  (site web personnel) . Évalué à 0.

      Mmmh tu te contredis, même si au final tu conclus comme il faut :

      Alors non la solution aux bugs de l'industrie n'est pas un nouveau langage ou un nouveau paradigme qui induisent moins de bugs.

      Ensuite :
      une seule solution pour faire baisser les bugs : cracher les thunes
      Crasher des thunes pour ? Ca sert à rien de mettre des millions dans un projet pour qu'il soit sans bug si tu as une équipe de merde qui code en VB.
      Alors oui il faut de la thune, mais il faut aussi des méthodes et outils (langages) adaptés, qui coûte cher surtout en ressources humaines.

      • [^] # Re: Mhmm, du po-gnon

        Posté par  (site web personnel) . Évalué à 4.

        Mmmh tu te contredis

        Il se contredit à quel moment ? J'ai rien vu.
        En fait si, il dit qu'en voulant faire des économies les industrielles font des pertes, mais c'est pas incohèrent même si ç a l'air paradoxal.

        Crasher des thunes pour ?
        Pour avoir "des méthodes et outils (langages) adaptés, qui coûte cher surtout en ressources humaines." (dixit toi -_^)

        Ca sert à rien de mettre des millions dans un projet pour qu'il soit sans bug si tu as une équipe de merde qui code en VB.
        À priori l'interêt de "mettre des millions" c'est d'embaucher des gens compétents. Tu le voyais destiné à quel usage cet argent ?

        • [^] # Re: Mhmm, du po-gnon

          Posté par  (site web personnel) . Évalué à 1.

          Il se contredit à quel moment ? J'ai rien vu.
          Il se contredit en ce sens qu'il dit qu'il faut dépenser de la thune, mais que d'un autre côté les outils adaptés ca sert à rien.

          Hors quand tu développes un soft pour une centrale nucléaire, il lsuffit pas de dire "je suis milliardaire, j'embauche des milliers de gens compétents" et pouf t'as un logiciel sans bug. Ca c'est du n'importe quoi.

          Il faut des gens compétents ET des outils adaptés (tu prends Schumacher tout seul, ca sert à rien sur le circuit s'il a une voiture de merde). Ce sont également ces derniers qui coûtent cher, car ils induisent du temps humain supplémentaire (Les langages formelles et le VB ne demande pas tout à fait le même effort), mais permettent d'obtenir des garanties.

          Alors oui à l'arrivée le coût va être sur les feuilles de paies des ingénieurs, mais les outils adaptés sont nécessaire, contrairement à ce qui laissait entendre.

          Je me suis mieux fait comprendre ?

          • [^] # Re: Mhmm, du po-gnon

            Posté par  (site web personnel) . Évalué à 2.

            [Il dit] que d'un autre côté les outils adaptés ca sert à rien.

            Non, je n'ai pas dit ça.

            • [^] # Re: Mhmm, du po-gnon

              Posté par  (site web personnel) . Évalué à 1.

              Alors non la solution aux bugs de l'industrie n'est pas un nouveau langage ou un nouveau paradigme qui induisent moins de bugs.
              C'est pas LA solution, mais c'est une partie de la solution.
              Si personne ne s'était penché là dessus on en serait encore à code en assembleur. J'espère que t'as pas peur pour les centrales nucléaires :)

    • [^] # du pognon pour les tests unitaires et les assertions. libre

      Posté par  . Évalué à 6.

      Je suis bien d'accord car écrire des tests unitaires et des assertions (pré/post conditions, invariants) pour chaque petite partie d'un programme, cela côute cher. Dans l'idéal il faudrait passer bien plus de temps à écrire des tests qu'à écrire le code qui est testé.

      Les outils de dev peuvent aussi progresser pour faciliter ce travail de test systématique. Mais ça coute cher aussi de faire des outils.

      Heureusement, les programmeurs de logiciels libres ne comptent pas tous leur temps :)

      • [^] # Re: du pognon pour les tests unitaires et les assertions. libre

        Posté par  (site web personnel) . Évalué à 3.

        Passer du temps à écrire des tests, ça coûte moins cher que passer du temps à fixer des bugs tordus ou à refactorer sans filet.

        Plus on détecte un bug tôt, plus il est facile à corriger (si ça se trouve, le code est même pas encore committé). Par contre si on détecte un bug alors que le logiciel est bien avancé, ça peut coûter très cher (si ça se trouve, la conception était foireuse dès le départ, faut tout refaire).

        Ensuite, quand on a une batterie de tests sérieuse, on peut attaquer des modifs sans prendre trop de risques, car on peut vérifier régulièrement qu'on a rien cassé.

        Bref, évidemment qu'écrire des tests ça coûte plus cher que faire l'autruche en se disant que "ça compile donc ça marche". À court terme. Mais allez dire à un manager à cheveux en pointes de dépenser des un peu de sous maintenant pour pas prendre le risque de devoir en dépenser plein plus tard...

    • [^] # Re: Mhmm, du po-gnon

      Posté par  . Évalué à 3.

      Qu'est-ce qui fait que d'autres industries ne livrent peu ou pas d'erreur, alors que tous les grands produits et projets informatique (ou presque) s'abîment dans un océan de problèmes ? Le pognon.


      Si ton raisonnement par la suite se tient, je trouve ce point très discutable. Opposer d'un coté l'informatique et de l'autre tout le reste, c'est pas terrible.

      Dans le monde du bâtiment, ca rogne un max, et ca pognonne encore plus (hum hum Aéroport écroulé etc...).
      Dans l'éducation, ca rogne énormément (par contre le pognon...) et c'est plein de 'bugs' : qui n'a jamais eu un prof pas remplacé pendant deux semaines ?
      En gestion des ressources humaines dans les entreprises, ca rogne à fond, et ya encore des bugs : personnes payées sans postes, licenciements non justifiés, tout le service qui prend sa RTT en même temps....
      Dans le journalisme, ca rogne et il y a des tas de bugs : infos non vérifiées, interprétations hubuesques des journalistes...
      Dans l'aviation, les bugs font la une des journaux
      La SNCF elle buggue bien (TGV en retard...)

      Bref, faut pas être catégorique comme ca je pense.

  • # naïfs

    Posté par  . Évalué à 4.

    Je vous trouve bien naïfs à toujours prendre l'exemple de l'industrie, des centrales nucléaires ou des télécoms comme domaines où la programmation serait exemplaire. Ouvrez un peu les yeux, c'est vraiment très loin d'être le cas.

    Et le danger est justement de croire naïvement que tout va fonctionner comme prévu, qu'il y a des outils, des langages et des personnes parfaites. Justement, s'il y a peut-être une différence dans l'industrie par rapport à d'autres domaines c'est qu'on sait dés le départ que ça ne marchera probablement pas et on prend les devants.

    ps: je ne parle pas de l'article mais des nombreux commentaires

  • # mock objects/mock units

    Posté par  . Évalué à 3.

    Pour ceux qui aiment les tests vraiment unitaires, il est utile d'utiliser des "mock units", qui simulent les autres unités normalement utilisées par l'unité en cours de test, afin de ne tester que cette unité (et pas en même temps toutes les unités que cette unité utilise).
    Voici un site pour Java (mais le concept est possible dans tous les langages, notamment via l'édition de lien pour remplacer les libs normalement utilisées par des libs de test qui enregistrent tous les appels)
    http://www.mockobjects.com/Faq.html(...)

  • # De quoi parle t-on ???

    Posté par  . Évalué à 4.

    Durant toute ma fastidieuse lecture, je n'ai fait que me demander ce qu'était réellement la problématique ...
    J'aurais pu être séduit par toute cette prose, ces allusions à des concepts lointains, toutes ces belles petites théories dont l'apport n'est jamais approfondi. Mais non, j'accroche pas.

    Au lieu de définir clairement un problème puis d'en rechercher une solution (ce qui n'est fait qu'en apparence ici): On cherche un problème à une solution, ce qui est absurde.

    Et puis pour commenter la question finale :
    "Comment rendre l'écriture de logiciel moins complexe ?"

    Vulgairement : L'informatique est un outil permettant de simplifier ce qui est complexe pour le rendre accessible à l'esprit humain.

    On part de ça :

    Problème complexe
    <Incompatible avec>
    Cerveau Humain

    On passe par ça :

    Problème complexe
    <naturellement incompatible avec>
    Informatique
    <naturellement incompatible avec>
    Cerveau Humain

    On arrive à ça :

    Problème complexe
    =rendu compatible=
    Informatique
    =rendu compatible=
    Cerveau Humain

    Ce qui a "rendu compatible" c'est l'écriture de logiciel. C'est le développement qui a permis de résoudre le problème de départ d'une part, et de mettre à porter de l'utilisateur sa solution d'autre part.
    Le développement ne fait qu'hériter de la complexité de départ. Ce n'est pas en changeant le développement que l'on simplifiera cette complexité : pour ça il faudrait soit simplifier le problème de départ (ce qui était justement le rôle du logiciel), soit simplifier la différence entre informatique et cerveau (alors que c'est cette différence qui permet à l'un de résoudre ce que l'autre ne sait pas faire, et qui justifie l'intérêt de faire appel à l'informatique).

    C'est un métier d'être développeur, et ce n'est pas pour rien : "notre" role c'est d'avoir le cul entre deux chaises, de penser à la fois avec nos neuronnes et avec nos transistors.
    A l'entrée : un probléme d'humain.
    A la sortie : une solution d'humain.
    Entre les deux : une soupe binaire qui est la seule capable de passer du problème à la solution.
    Entre l'entrée et le milieur, et entre le milieu et la sortie : le développeur qui joue au traducteur homme/machine, qui passe d'un monde à l'autre.

    On peut améliorer les languages de programmation pour parfaire l'abstraction qu'ils font de la soupe binaire, pour les rendres plus lisibles, propre, clair, toussa, oui. Mais ça s'arrête la.

  • # Une réponse à cette probématique

    Posté par  . Évalué à 3.

    Why Software Is Bad and What We Can Do to Fix It :

    http://www.rebelscience.org/Cosas/Reliability.htm(...)


    Project COSA, To Drastically Improve Software Reliability and Productivity :

    http://www.rebelscience.org/Cosas/COSA.htm(...)

    En gros, l'auteur propose une nouvelle façon de programmer, plus basée sur de la conception à partir de blocs graphiques comme lorsque l'on fait du design hardware... personnellement je me suis tapé toute sa doc et je n'ai pas été vraiment convaincu... Enfin ce point de vue a au moins le mérite d'être original et assez détaillé.

Suivre le flux des commentaires

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