Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage"

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
27
mar.
2001
Technologie
On peut souvent lire dans les commentaires sur linuxfr que les langages objets ne servent à rien puisque la POO est un concept qui peut s'appliquer avec n'importe quel langage, et donc qu'on peut faire aussi bien sans un langage OO. J'ai essayé d'approfondir un peu le sujet, et de montrer que les choses ne sont pas aussi simples.

Cet article a récemment été publié sur K5. Je l'ai remanié un peu suites aux remarques reçues.

Aller plus loin

  • # En effet, les choses ne sont pas si simples.

    Posté par  . Évalué à 1.

    Les langages objets sont conçus dans une optique objet et intègrent dès le départ les notions de classes, d'héritages, de constructeurs et de destructeurs.
    Il est donc normal que ces langages soient plus efficaces que les langages classiques comme le C. Néanmoins, le mode de pensée objet (variables de classes et d'objets par ex) est tout à fait implémentable (et implémenté en c, cf GTK+) mais au prix d'une certaine rigidité de style et d'une certaine complexité (allez jetez un coup d'oeil sur le noyau objet de GTK+, il est bien fait mais faut suivre). Cela dit, on peut très bien coder OO de manière simple sans aller jusqu'à faire des monstres. D'ailleurs, les structures qui se baladent un peu partout ds les softs ne sont-elles pas des débuts d'objets ?

    • [^] # Re: En effet, les choses ne sont pas si simples.

      Posté par  . Évalué à -1.

      Ouaip... Mais tu t'es jamais dit merde, j'aimerais pouvoir faire un
      window->set_title("truc"); au lieu de
      gtk_window_set_title(GTK_WINDOW(window), "truc");
      C'est un exemple a deux francs et ya des fois ou c'est bien pire... Par exemple pourquoi tu peux pas iterer de la meme facon dans un G[Ptr]Array ou une Glist ?
      C'est quand meme un tiers de 'boilerplate' code qui rends les choses difficiles (la rigidité dont tu parlais)...
      Ce qui serait genial c'est un language qui puisse accepter de nouvelles constructions dynamiquement... Ca parrait peut etre debile, mais si il y avait simplement un moyen pour faire des alias, une sorte de #define plus intelligent et plus facile a ecrire... Ca serait mechament bien.

  • # oui mais

    Posté par  . Évalué à 0.

    ok avec l'article.
    oop en C = casting etc.
    cela dit un wrapper en C++ d'une API C c'est jamais cool car il faut une bonne connaissance de l'api C sous jacente et une API C quasi objet. gtkmm est un wrapper de qualité mais trés peu utilisé par rapport à gtk.

    • [^] # Re: oui mais

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

      Tout à fait d'accord sur les pb d'encapsulation du C. Il suffit de voir les MFC (Microsoft Foundation Classes). Même dans l'aide, ils précisent que ce que tu fais avec la classe, tu peux le faire au travers de la fonction C truc et que d'ailleurs on te file au travers de telle méthode le pointeur que tu pourras passer en paramètre de la fonction. En clair, du très joli C++ qui encapsule de manière tout à fait transparente (voire inexistante) le C de l'api Win32. Si on les écoute bien, faut faire du C.

  • # A enfin un coder

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

    Salut,
    j'ai eu la chance de discuter un jour par mail avec un extrémiste qui pensait aussi que l'on pouvait faire de l'objet avec le C. Dans le concept, il avait raison, dans la pratique, c'est genre de mec qui te colle allègrement des structures d'union contenant des pointeurs. Enfin, il a raison pourquoi se faire chier à utiliser le C++ alors que l'on peut essayer de tout redévelopper en C. Ceci dit et ça n'engage que moi, le C++ n'est pas exempt de trucs bizarres non objets mais c'est en grande partie dûe au C et à la compatibilité qu'il entretient avec ce dernier. Personnellement, je préfère le Java même si c'est lent (quoique ça s'améliore) et c'est surtout dû à son ensemble de classes toutes prêtes qui évitent pas mal de ré-inventer la roue.
    Enfin, un jour j'ai entendu (dans un film mais j'étais jeune !!! ;-)) : "Tu codes de la merde, tu récupères de la merde." Ce qui est très vrai, on peut faire du C lisible et qui fonctionne très bien comme on peut faire du C++ ou Java absolument illisible, impossible à maintenir et dont les perfs sont pourries.
    C'est comme les distribs, le langage informatique faut choisir celui qui plaît, c'est le plus important.

  • # Mouais

    Posté par  . Évalué à 1.

    Bon on sait tout ça. Ce que je reproche à C++, en particulier, c'est sa complexité: dans sa syntaxe, dans les différents mode de passage de paramètres (bien que ce ne soit pas pour faire joli, hein!), dans le fait que tout n'est pas objet (les types de base). Java non plus ne manipule pas que des objets... J'aime bien ce qui va jusqu'au bout du concept.
    J'ai jeté un oeil sur Ruby et celui-là m'incite vraiment à reconsidérer la POO. Tout y est objet et la syntaxe est claire.
    Evidemment c'est un langage relativement neuf qui a pu faire le bilan de tout ce qui existait jusque là.

    • [^] # Re: Mouais

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

      > J'aime bien ce qui va jusqu'au bout du concept.

      C'est bien joli mais ce genre d'attitude ne tient pas une fois confronte a la realite. Tout n'est pas objet, il y a plein de cas ou la representation objet ne sert a rien.

      La POO est un outil, pas une fin en soi. Si tu l'utilises lorsqu'elle est utile, tu fera du bon boulot. Si tu l'utilises parce que "c'est bien" ou parce qu' "elle doit etre utilisee", plaf.

      • [^] # Re: Mouais

        Posté par  . Évalué à 1.

        Je suis entièrement d'accord !
        Et d'ailleurs, le C n'est pas complètement structuré : il y a encore un 'goto' qui traine par là !

        Et même les langages très conceptuels de l'IA (comme lisp ou prolog, mais y en a d'autres) ne sont pas 'purs' ... Alors pourquoi vouloir un langage pur mais inutilisable ?

        Pour l'objet enfin, il me semble qu'Eiffel est 'pur' (c'est ce qu'on m'a dit, j'en ai jamais fait), mais vu les temps de compilations et l'efficacité du code généré, on peut douter de son utilité, à part apprendre à coder en objet ... un peu comme le Pascal pour les langages structurés (qui avait été développé à des fins éducatifs !).

        • [^] # Re: Mouais

          Posté par  . Évalué à 1.

          Ouarf, ca fait quand meme longtemps qu'on est passe (au niveau de la recherche sur les langages, s'entend) a autre chose que les langages comme Lisp ou Prolog. On travaille maintenant sur des langages qui en reprennent des concepts mais de maniere plus structuree (et ce parce qu'on commence a avoir des semantiques plus claires).

          Citons en vrac: Ocaml, SML, MosML, Concurrent Clean, Curry, Mercury, Oz, Lambda-Prolog, Haskell, etc.

          Pour ce qui est de Eiffel, la lenteur du compilo et du code genere a effectivement ete un probleme, beaucoup moins depuis GNU SmallEiffel cela dit. Neanmoins, quand on fait un programme comme Word, qu'on va distribuer a des millions d'exemplaires, on peut peut-etre tolerer que sa compilation dure quelques heures, c'est pas tres grave. Du moment que, pendant le developpement, il est possible de faire des compilations partielles (c'est la cas d'Eiffel), ca va.

        • [^] # Re: Mouais

          Posté par  . Évalué à 1.

          Oui, en effet, tu n'as jamais fait d'Eiffel, d'ailleurs ça se voit. D'abord le moins grave : les temps de compilation, ça fait rire, mais ça dépend du compilateur (ISE, SmallEiffel, Visual Eiffel, ...). D'une manière générale, il ne recompile que ce qui a été modifié. L'efficacité du code engendré : compile -boost -O2 et l'on a (presque) l'efficacité d'un code directement écrit en C. A propos : le C n'arrive qu'à environ 80% de l'efficacité d'un code écrit en assembleur (dans le cas d'un programme complexe, une fois et si il fonctionne), alors pourquoi le C ? Enfin pourquoi programmer en OO sinon pour pouvoir réutiliser les composants logiciels produits, bénéficier des facilités de l'héritage (simple, multiple, répété), de la généricité, de la liaison dynamique, de la jointure des primitives différées héritées, toutes ces choses que je me vois mal émuler en C. Je ne parle même pas du ramasse-miettes. Mais la totalité de ce que je viens de citer n'est réellement disponible qu'en Eiffel (pas d'héritage multiple vrai en Java). Et, en plus, Eiffel permet la programmation par contrat, qui permet de concevoir des logiciels de manière semi-formelle. Ca suffit comme avantages ?

          • [^] # Re: Mouais

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

            Je suis d'accord avec toi sur les avantages de la POO. Le seul truc que j'ai à dire est sur l'héritage multiple et les "contrats". Pour ce qui est de l'héritage multiple, je le trouve difficile à utiliser et pas toujours judicieux parce que l'on a tendance à associer un état (héritage "cet objet est du même type") à un comportement (interface ou contrat "cet objet fait la même chose que les objets de cette classe"). De plus, l'exemple habituel : une trouve une même méthode (M())dans deux classes A et B qui héritent d'une même classe abstraite A' (la méthode était virtuelle pure ce qui oblige à la définir dans les classes filles), pour l'instant, il s'agit d'héritage simple. On crée ensuite une classe AB qui hérite des deux premières classes dérivées. Quelle implémentation de la méthode sera utilisée dans AB ? Celle de A ou celle de B ? Il faut la redéfinir et dire dans le corps de la méthode A::M() (ou B::M() suivant le choix). Résultat, on casse l'héritage puisque l'on veut bien de toutes les méthodes des deux mais il y en a une qui notre préférence pour l'implémentation de M.
            Cela m'amène aux contrats (je ne connais pas Eiffel donc il faut me dire si je me trompe dans la définition d'un contrat). En Java, L'héritage multiple n'existe pas et on utilise à la place le mécanisme des interfaces. Une interface est un contrat dans le sens où l'on définit dans une interface les prototypes des méthodes que seront à implémenter par les classes respectant l'interface. L'interface sert donc à déclarer un comportement. Je vous aurais bien trouvé un exemple mais je n'ai pas le temps ni le souvenir d'un cas d'école si ça revient, je post.
            Tout ça pour dire que l'héritage multiple est quelque chose de dangereux car il est sujet aux dérives et c'est la principale raison qui l'a fait retirer de Java.

            • [^] # Re: Mouais

              Posté par  . Évalué à 1.

              Le probleme avec la POO, c'est que C++ et Java ont faconne les esprits des programmeurs qui sont maintenant persuades que l'heritage multiple pose des problemes et casse l'heritage.

              Eh bien non! Ca ne casse rien. De toute facon, s'il n'y avait pas d'heritage multiple, on serait quand meme oblige de definir une methode M. Alors devoir faire un choix ne change pas grand-chose. Par ailleurs, il est toujours possible de renommer des methodes heritees...

              Quant aux contrats, tu te trompes effectivement: la programmation par contrat d'Eiffel est un mecanisme a base d'assertions logiques. Pour une methode M, tu peux specifier quelles sont les conditions pour l'appeler, et ce qu'elle peut te garantir sur ce qu'elle retourne (c'est le contrat qu'elle te propose). Ca permet ensuite d'eviter de faire un certain nombre de tests qu'on doit d'habitude se taper. Ce qui est interessant, c'est que quand on reecrit une methode dans une classe fille, on herite aussi de ses assertions et on peut les enrichir.

              Les interfaces Java n'ont rien a voir avec un contrat. Litteralement, une interface est un type. Et les classes qui implementent une interface sont des classes de ce type. Ca permet de resoudre legerement le manque d'heritage multiple puisque si une classe ne peut avoir qu'une surclasse, elle peut en revanche avoir plusieurs types. L'idee, c'est que les concepteurs de Java considerent que quand on fait de l'heritage multiple, c'est generalement pour avoir plusieurs types, et non pas pour recuperer du code. Le probleme, c'est que quand c'est effectivement pour recuperer du code, on est dans la merde: on est oblige de reecrire des methodes qu'on aurait pu directement heriter (exemple: une applet multithreadee ne peut pas a la fois etendre Applet et Thread, ce qui correspond pourtant bien a la semantique de l'heritage multiple).

              Donc s'il n'y a pas d'heritage multiple en Java, c'est surtout parce que ca emmerdait les concepteurs. Ils voulaient un langage tres simple, au risque de perdre de l'expressivite. C'est un choix... qui n'est pas celui d'Eiffel, Sather, Beta, Mjölner, etc, qui fonctionnent tres bien comme ca, merci pour eux.

            • [^] # Re: Mouais

              Posté par  . Évalué à 0.

              L'héritage multiple n'est pas dangereux du tout en tant que tel. Il est dangereux en C++, parce que le C++ hérite du C et donc a certaines limitations...

              Fait un peu d'Eiffel et tu comprendras...

              Quand à Java, s'ils ne l'ont pas implémenté c'est simplement une question de pognon: ça leur aurait pas raporté grand chose et ça leur aurait couté plus cher en temps de développement.

            • [^] # Re: Mouais

              Posté par  . Évalué à 0.

              Je m'en veux un peu de prendre part dans une flamewar autour des langages de programmation... Je vais donc essayer d'apporter quelques precisions sans (trop) prendre parti. En ce qui concerne le probleme de l'heritage repete (ton losange de classes A', A, B, et AB), le probleme n'est pas tant de "casser l'heritage" que d'obtenir une semantique utilisable dans tous les cas. J'ose conseiller de jeter un oeil sur le chapitre 11 du bouquin "Eiffel, le langage" de Bertrand Meyer (un excellent bouquin tres general sur la programmation objet, si l'on arrive a faire abstraction de l'amour exclusif que porte l'auteur au langage Eiffel :). Le vrai probleme serait plutot qu'avec l'heritage simple on a une seule semantique d'heritage, alors qu'avec l'heritage multiple toutes les classes dont on herite n'ont pas forcement le meme statut (par exemple X herite de Y et de Z, parce que X est un Y mais agit comme Z). C'est ce qu'ont reconnu les concepteurs de Java, mais ils n'ont autorise que 2 types d'heritage: celui equivalent a l'heritage simple, et celui des interfaces. Eiffel reconnait aussi la necessite de differencier les differents types d'heritages, mais il opte pour une solution bien plus generale basee notamment sur le renommage (solution qui englobe celle de Java --- tu peux n'utiliser d'Eiffel que ces deux types la d'heritage si tu veux, et ce sont certainement les plus utiles). Je programme beaucoup en Java ces temps-ci, et j'ai souvent regrette de ne pouvoir mettre un peu de code dans mes interfaces (evidemment, c'est peut-etre une deformation Eiffelienne!). D'un autre cote, quand je code en C++ je me force a suivre les contraintes de java (heritage simple plus heritage multiple de classes abstraites (pure virtual)) parce que C++ n'offre aucun moyen _facile_ d'expliquer quel genre d'heritage je veux. Et a propos de la conception par contrats, c'est tres different de ce que tu ecris. Il faudrait se rappeler les cours sur les types abstraits de donnees (pour ceux qui ont une formation d'informaticien), mais je n'ai plus le temps. Sachez seulement qu'il existe des implementations partielles du DBC pour Java et C++, et que certains langages de scripts commencent a lorgner dans cette direction aussi. A suivre de pres, donc...

            • [^] # Re: Mouais

              Posté par  . Évalué à 1.

              Ababacar Octopuce a très bien répondu sur le fond. Pour ce qui est de l'héritage des routines, la question de savoir laquelle sera utilisée, en cas d'héritage répété de routines ayant le même germe est une question de choix du concepteur. S'il en est arrivé là, il faut espérer qu'il sache ce qu'il fait ! En Eiffel, on dispose dans ce cas de plusieurs techniques que l'on peut appliquer : la redéfinition (on garde le même nom, on change la sémantique, si la routine garde la même signature, quand même), l'a-définition (la routine devient différée, abstraite selon un autre vocabulaire) et le renommage, lequel peut être combiné avec une redéfinition ou, mais je n'en suis pas tout à fait sûr, l'a-définition. D'autre part, si l'on hérite de routines différées de plusieurs classes ancêtres, on peut procéder à leur jointure. Une telle routine jointurée peut alors être appelée dans des contextes différents selon que la classe qui a servi à instancier l'objet qui porte cette méthode est considérée comme héritière de telle ou telle autre classe comportant la primitive qui a été jointurée. Ouf ! Pour l'instant je n'ai jamais eu à m'en servir, mais si ça arrive, promis, je vous préviens...

        • [^] # Re: Mouais

          Posté par  . Évalué à 1.

          Hum, Eiffel est pur OK. Mais c'est faux de dire que les perfs ne sont pas au RDV. En fait, comparé à Java, il ne se débrouille pas trop mal. Perso, pour des domaines "critiques", Eiffel me semble très adapté (cf design by contract)

          PS: Zut, je ne trouve plus mon lien Eiffel !

      • [^] # Re: Mouais

        Posté par  . Évalué à 1.

        J'ajouterais que des langages comme Ruby ou Python sont loin d'aller <<au bout du concept>>. Pour ca, va plutot voir des trucs comme Beta ou Mjölner (Eiffel et Sather aussi, mais ils ont un peu vieilli). Voir aussi les bouquins de Cardelli & Abadi, et de Castagna, qui montrent vraiment ou en est la recherche dans ces domaines.

    • [^] # Re: Mouais

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

      T'as qu'à essayer Smalltalk, dans le style tout est objet, tu verras que même les fonctions sont des objets.

      • [^] # Re: Mouais

        Posté par  . Évalué à 0.

        Beurk :(

        J'ai codé du Lambda calcul en SmallTalk (ce qui m'a dégouté du st) et depuis je préfère la philosophie de tcl/tk :
        "All is a string" ;)

      • [^] # Re: Mouais

        Posté par  . Évalué à 0.

        Exactement, faire de l'objet a tout prix ne sert à rien, de plus, il est plus un obstacle qu'un frein lorsque tu as peu de temps....
        C'est bien beau tout ca mais c'est pas tjs qu'on peut dire : alors 5 mois de conceptions et 2 mois de codage, ca va chef???
        Tu as 4 mois....Tu fais comme tu veux...faut surtout que ca marche a cette date, alors en effet, c'est pas top reutilisable, mais ca fonctionne, et quand il faut faire une modif : Alors ya tel et tel project de sortit, tu les utilise et globalement si tu avais fait une super conception, elle n'aurait servie a rien puisque tu pars from scratch avec des nouveaux outils....
        Bref la POO....

        • [^] # Re: Mouais

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

          Je ne suis qu'en partie d'accord avec toi. J'ai vécu le projet où les délais étaient hyper justes et où la techno était objet (java). C'est sûr que c'était pas gagné mais ce que je peux te dire c'est qu'au niveau de la maintenance du code, c'était autre chose que du C. Le "ça marche" c'est bien mais faut plus y toucher (ce qui revient à l'expression tombé en marche). Au premier fait technique (bug) à corriger, t'es mal et tu passes trois fois plus de temps à retrouver où tu dois corriger. D'ailleurs, je défie celui qui dit qu'il n'a jamais eu de bug après acceptation de me montrer son programme.

          • [^] # Re: Mouais mais

            Posté par  . Évalué à -1.

            Oui c'est vrai, mais cela est du au langage : java est facile à lire à coté du C. D'un autre coté le style objet aide à la lisibilité, mais je ne pense pas que cela soit sa vocation premiere

  • # Les processeurs ?

    Posté par  . Évalué à 0.

    Je comprends qu'un langage OO ne soit pas équivalent à un langage non-OO, mais qu'en est-il une fois compilé, car les CPU ne travaillent pas en mode OO, ils utilisent un ProgCount, qui les fait incrémenter adresse par adresse, solution pas du tout objet mais complètement procédurale. Donc, tout langage objet est d'abord compilé en assembleur (in fine) et N'EST DONC PAS DU TOUT OBJET, la prog. objet n'est qu'un abstract syntaxique.
    Ex : Les chinois ne lisent pas dans le même sens que nous ni dans le même alphabet, pourtant la phrase : "bonjour, vous allez bien ?" pourra être traduite.

    Si vous voulez, c'est pour faire beau.
    La prog. objet existera quand les CPU seront objet.

    • [^] # Re: Les processeurs ?

      Posté par  . Évalué à -1.

      Mais si, les processeurs sont des objets, si si.

    • [^] # Re: Les processeurs ?

      Posté par  . Évalué à 0.

      Il va être assez dur de faire des procs objets (si t'en vois un, tu m'appelles).
      Là où je suis d'accord, c'est sur le fait que n'importe quel langage tournera sur un proc avec des MOVE, des CMP, des PUSH/POP et des JMP (en gros). C'est le compilo (ou la VM) qui est chargé de traduire cet ensemble conceptuel formalisé qu'est le code source (il est beau celui-là ;) en une suite d'instructions machines. Si on suit ton raisonnement, on devrait tout écrire en assembleur, ça serait plus rapide.
      Mais l'abstraction syntaxique est importante, c'est le seul moyen de pensée de l'être humain (on est pas des CPU).

    • [^] # Re: Les processeurs ?

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

      C'est marrant, y a eu un neuneu sur K5 qui a fait exactement la meme reflexion que toi :

      http://www.kuro5hin.org/?op=comments&sid=2001/3/22/17509/3442&cid=9(...)

      Et donc je te fais la meme reponse : t'as rien compris. :-)

      • [^] # Re: Les processeurs ?

        Posté par  . Évalué à 0.

        Ce qui ne m'empêche pas de te pisser au cul, sale con.

      • [^] # Re: Les processeurs ?

        Posté par  . Évalué à 0.

        D'autant que ta réponse est très motivée : tu n'explique rien, ni dans le sujet, ni dans ta réponse, tu reste insultant dans les deux cas, c'est ainsi que toi même tu te feras insulter, pôv câve.
        Lorsqu'on te demande pourquoi, ne fais pas que répondre "parce que", sinontu passe pour un con.
        Je me demande si tu en es un ?

        • [^] # Re: Les processeurs ?

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

          Dans la mesure ou le but de l'article est precisement d'expliquer en quoi ce raisonnement est absurde, je vois pas ce que je peux ajouter.

          Tout l'article tente d'expliquer pourquoi l'OO n'est pas que "pour faire beau", que repondre a quelqu'un qui arrive en disant "l'OO c'est que pour faire beau" ? A part en rire, je ne vois pas.

          OK, en plus de dire "t'as rien compris", j'aurais du rajouter "relis l'article", mais bon, si la premiere fois ca n'a pas marche, est-ce vraiment utile de retenter une seconde passe ?

          • [^] # Re: Les processeurs ?

            Posté par  . Évalué à 0.

            parce que tu n'as pas la science infuse et que des codeurs expérimentés n'en ont rien à foutre de ton diktat du tout OO

            • [^] # Re: Les processeurs ?

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

              Je ne pretend pas avoir la science infuse, je suis un codeur experimente, quant au diktat du tout OO, il n'existe plus que dans les cours de quelques profs d'infos integristes, le reste du monde en est revenu depuis longtemps.

              Par ailleurs je serais curieux de savoir en quoi mon article te semble vouloir imposer un tel diktat, d'autant que je critique les extremistes de l'OO au debut. Et j'ai deja repondu tout a l'heure a quelqu'un qui preferait Ruby pour son cote "tout OO" qu'il se trompait.

      • [^] # Re: Les processeurs ?

        Posté par  . Évalué à 0.

        un "neuneu"? mais quel abruti es-tu pour espérer imposer ta version aux autres?

        • [^] # Re: Les processeurs ?

          Posté par  . Évalué à 0.

          Bon, Ben, c'est intéressant de lire les commentaires des développeurs chevronnée ???
          Moi je suis qu'un développeurs débutant (quelques année d'exp. quand même), et vus la quantitée de chose à apprendre, je le resterais probablement toutes ma vie.

          Par contre, je pense qu'un des pas à franchir pour passer de la connerie à l'intelligence est de savoir écouter ce que les autres ont à dire et éventuellement de critiquer leurs opinions de manière constructive... Ce qui n'a pas l'air d'être le cas de tout le monde ...

          Enfin, bon courage à tous quand même ...

    • [^] # Re: Les processeurs ?

      Posté par  . Évalué à 1.

      Ah, mais ça existe. J'ai déjà vu un co-processeur objet pour ARM, conçu par une université anglaise si je me rappelle bien. J'ai eu le papier chez moi, mais il doit être perdu au fond de mes cartons. En gros, les appels objets se font en assembleur, mais vu que je suis pas trop amateur des machins objets, je ne sais plus bien.

    • [^] # Re: Les processeurs ?

      Posté par  . Évalué à 0.

      Pas d'accord: les CPU n'en sont meme pas au niveau d'etre procedurales. L'assembleur oui, mais l'assembleur n'est qu'un <<abstract syntaxique>> (pour te citer) pour le Langage Machine, qui est le seul langage compris par le proc. Et le Langage Machine n'est absolument pas procedural...

      Pour reprendre ton analogie, j'aurais tendance a dire que le Langage Machine c'est l'Anglais. C'est le plus utilise, on peut tout traduire vers l'Anglais, mais ca n'implique pas que l'Anglais est la langue de reference et que les autres ne sont que des "abstract syntaxiques". Non, toutes les langues sont equivalentes, meme s'il existe un standard de fait. Conclusion, ce n'est pas parce que la CPU est le systeme implante sur nos machines (parce que c'est ce qu'il y a de plus simple a faire pour les electroniciens) que c'est aussi le plus expressif, le plus puissant et le "plus ultime".

    • [^] # Re: Les processeurs ?

      Posté par  . Évalué à 1.

      Si je te suis, il n'y a que l'assembleur et le reste c'est que pour faire beau...
      Euh, temps de developpement, maintenance, reutilisabilite, portabilite,.... Tout ca , c'est aussi pour faire beau ?

      • [^] # Re: Les processeurs ?

        Posté par  . Évalué à 0.

        On peut faire de l'assembleur orienté objet, comme ça, tout le monde est content :) Ou comme je le dis juste au-dessus, utiliser un co-processeur objet sur le processeur.

        -------------------------------------
        Jak, qui a la flemme de s'identifier

  • # C--

    Posté par  . Évalué à 1.

    Juste un mot pour te dire que le C-- (exemple que tu prends dans ton article) existe deja, et est developpe avec comme but d'en faire un back-end portable pour les langages fonctionnels. C'est d'ailleurs un des 2 concepteurs principaux d'Haskell qui en est l'auteur. Cf. http://www.cminusminus.org(...)

  • # langages fonctionnels

    Posté par  . Évalué à 1.

    Je suppose que ce raisonnement s'applique plus à la comparaison langage impératif-objet. Je ne sais pas trop s'il est possible de concilier les notions de "tout est fontion" avec celles de "tout est objet".
    Cela dit, ça n'est pas un problème. Tous les langages fonctionnels (ceux que je connais) utilisent des notions impératives (plus ou moins. caml peut être utilisé purement en impératif-et ocaml est objet!)

    • [^] # Re: langages fonctionnels

      Posté par  . Évalué à 1.

      > Je suppose que ce raisonnement s'applique plus à la comparaison langage impératif-objet.

      Le concept objet est orthogonal par rapport aux concepts imperatif/fonctionnel. La preuve en est qu'il existe des langages fonctionnels a objets.

      > Tous les langages fonctionnels (ceux que je connais) utilisent des notions impératives

      Ceux que tu connais comme tu dis :-)
      En fait, il existe plein de langages fonctionnels purs, dont le plus important: Haskell (http://haskell.org(...) ).

      > (plus ou moins. caml peut être utilisé purement en impératif-et ocaml est objet!)

      Ocaml n'est pas un langage a objets.
      C'est un langage fonctionnel, qui permet d'utiliser des objets, nuance. Un peu comme C++ permet d'utiliser des objets, mais te permet aussi de programmer uniquement en C.

      • [^] # Re: langages fonctionnels

        Posté par  . Évalué à 0.

        et quelle est la fonctionalité la plus 'hot' de haskell? ce sont les Monades, qui permettent de le transformer aussi en langage imperatif. (jusqu'a ce qu'une personne dise que haskell est le meilleur langage impératif ;)

        • [^] # Re: langages fonctionnels

          Posté par  . Évalué à 1.

          Mouais. Pas exactement quand meme. Grosso modo, une monade ca sert a specifier un ordre d'execution, ce qui permet de simuler des traits imperatifs. Mais ca reste de la simulation, parce qu'il n'y a pas de modification de la memoire. A la place, on trimbale de fonction en fonction le "monde environnant" et on bosse uniquement sur des valeurs. En un sens, ca ressemble plus a des continuations qu'a des effets de bord. M'enfin, personne n'a jamais dit qu'on n'avait pas besoin d'interagir avec le monde exterieur, donc il faut bien trouver un moyen d'y arriver sans casser les bonnes proprietes d'un langage paresseux.


          (Et j'aurais tendance a dire que ce qui est cool dans Haskell c'est aussi les classes de types.)

  • # Autre chose que du blabla

    Posté par  . Évalué à 0.

    Voila de quoi vous occuper un moment.
    http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)

    • [^] # Re: Autre chose que du blabla

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

      Tres interessant, d'ailleurs dans l'intro on peut lire : "It is clear that the techniques presented here have not the pretension to replace C++ or Objective C". Et juste avant, que ces techniques s'adressent à ceux qui n'ont pas de compilo C++ pour leur plateforme, ou à ceux qui sont déçus des compilos C++ actuels (mais franchement, je préfère encore un mauvais compilo C++ qu'utiliser les techniques décrites).

      De nos jours pour du gros developpement, j'irais sous Java direct, sinon C++.

Suivre le flux des commentaires

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