Les spécifications du langage D sont arrivées

Posté par  . Modéré par Mouns.
Étiquettes :
0
27
avr.
2004
Communauté
Je vous conseille d'aller voir cette merveille. Ce langage a l'air très prometteur et est à la fois proche du C, C++, Java, mais avec des innovations très intelligentes.

Voici quelques caractéristiques, dans le désordre... : Orienté objet : classes, interfaces, délégation, RTTI, RAII (Resource Acquisition Is Initialization), Templates, vrais typedefs, définition de fonctions imbriquées, tableaux dynamiques, vrais types string, bit, complex, ... ramasse miette, gestion d'exceptions, assertions dynamiques et statiques (à la compilation), tests unitaires d'objets.

Il existe une bibliothèque pour GTK. Le frontend pour compilateur est en licence GPL+Artistic. Le projet de compilateur Gnu D, semble être abandonné... dommage.
Espérons que ce langage va percer...

Aller plus loin

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 10.

    C'est pas sorti que c'est déjà mort...

    Je vous présente le Langage E

    Site officiel la bas --> http://www.erights.org/index.html(...)
    Didacticiel ici --> http://www.erights.org/elang/intro/index.html(...)

    Bon allez j'arrête mes conneries moi

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 3.

    mais plus concrétement, il y en a qui ont une véritable expérience de ce langage ?

    quelqu'un peut il dire s'il a un REEL avenir ? (c'est à dire servir a programmer de véritable applications natives pour linux, genre pour gnome un editeur de comptes bancaires par exemple) ?

    ou s'il n'est qu'un projet de quelques personnes sans véritables soutiens de grands projets opensource ?

    accessoirement, il n'existe donc pas de compilateur complet en opensource ? (et encore moins en gpl, véritable obligation pour le populariser rapidement).

    DUI semble utilisable, et pourrait servir de base pour un "meilleur framework" gnome , plutôt que de se poser d'innombrables questions sur "java ou python ou c/bidouillé ou c#/cli " ?

    mais bon, à part de l'humour (fort amusant au demeurant) quelqu'un à t'il une expérience de D à raconter ?

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 1.

    c'est pas le langage qui compte, c'est le programmeur (ou le developpeur si on est pretentieux).

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 2.

      N'empêche que si le langage est bien foutu, on gagne un temps fou, une efficacité folle, une sécurité folle et une qualité folle!

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 0.

        Moi qui n'y connait rien ou quasiment rien au developpement, je mettrai as plus de temps à devel un truc en python, ou en tcl. Seul le script m'importe, en voilà un : (pour mettre à jour sa distrib):

        #!/bin/bash
        MAJ=`Xdialog --backtitle "Mise à jour du système" --title "Mise à jour de l
        e urpmi" --yesno "Voulez vous mettre à jour la base rpm?" 0 0 2>&1`
        if [ $? = 0 ]
        then
        xterm -bg red -fg black -e urpmi.update -a # ou apt-get update

        UPD=`Xdialog --backtitle "Mise à jour du système" --title "
        à jour du système" --yesno "Voulez vous mettre à jour le système?" 0 0 2>&1

        if [ $? = 0 ]
        then
        echo o|urpmi --auto-select #ou apt-get dist-upgrade
        else
        exit
        fi
        else
        UPD=`Xdialog --backtitle "Mise à jour du système" --title "
        à jour du système" --yesno "Voulez vous mettre à jour le système?" 0 0 2>&1
        if [ $? = 0 ]
        then
        echo o|urpmi --auto-select
        else
        exit
        fi

        fi

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 1.

      le langage, comme le choix d'outils quelque soit le domaine technique, compte

    • [^] # Re: Les spécifications du langage D sont arrivées

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

      oui... dans la mesure où c'est le programmeur qui choisit le langage. Perso je fais des choix technique surprenant (jeu 3D en Python) et ça fait une différence crois-moi (notamment sur le temps de développement du jeu).

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 6.

      On croirait entendre Stroustrup : Si ça segfault c'est de ta faute. Si le language est tellement mal foutu qu'on se prend les pieds dans le tapis facilement sans s'en rendre compte c'est qu'on est un Pierre Tramo.

      Ce raisonnement (le programmeur est un dieu, il saura se démerder) était valable à l'époque ou le C++ a été designé. Ce n'est plus le cas aujourd'hui. C'est fini l'époque des demi dieux qui optimisaient leur bousin en assembleur. On n'a plus le temps de jouer. Un code doit être clair, documenté, compréhensible pour ceux qui bossent avec toi et ne pas cacher d'astuce à la con qui segfault. Si le langage pose une première série protections anti-codage-avec-la-bite, c'est déjà ça de gagné.

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 1.

        Mince, moi qui pensait que http://excalibur.cnam.fr/pages_personnelles/EC_bertrand/surrealites(...) etait parole d'evangile...

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 1.

        >C'est fini l'époque des demi dieux qui optimisaient leur bousin en
        > assembleur. On n'a plus le temps de jouer. Un code doit être clair,
        > documenté, compréhensible pour ceux qui bossent avec toi et ne
        > pas cacher d'astuce à la con qui segfault. Si le langage pose une
        > première série protections anti-codage-avec-la-bite, c'est déjà ça de
        > gagné.

        Autant je suis d'accord avec le fait que le code doit etre clair, ..etc.. autant je suis pas d'accord avec le fait qu'on n'optimise plus en ASM .. Ca arrive encore, dans des parties critiques .... Il faut encore que le langage en soit capable ...
        Sinon pour la clarte/qualite du code, je pense que si le codeur veut ecrire du code comme un porc il y arrivera tj, qq soit le langage utilise .. et vice/versa ...
        Si les codeurs etaient un peu plus fiers et respectueux de leur code, voire lui attribuait une dimension artistique (si, si, un beau code clair et concis, c'est IMHO presqu'une oeuvre d'art), et faisait la difference entre un code qui marche et un code juste ou elegant, ca serait deja un grand pas ...
        Ensuite savoir si le langage machin et plus mieux que le langage truc, ce sont des guerres de religions .. et dieux sait que je n'aime po le C++ ;)

        • [^] # Re: Les spécifications du langage D sont arrivées

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

          Ce ne sont pas des guerres de religions.
          Les chiffres sont tétus (et inatendus dans leur ampleur), il faut se référer aux études sérieuses sur la chose.
          Le choix du langage peux diviser le cout de developpement par 2, le cout de maintenance par 4, le nombre de défauts "livrés" par 8, le temps pour identifier et corriger un défaut par 2, etc. etc.

          Même pour des gents qui ont de l'expérience et qui connaissent les différents langages concernés, c'est dur de se rendre compte de l'importance du choix du langage.

          En fait, et contrairement à ce que l'on entend tout le temps, le langage est un des choix les plus important d'un développement (sauf si ca fait seulement 100 lignes de code, bien sur).

          • [^] # Re: Les spécifications du langage D sont arrivées

            Posté par  . Évalué à 1.

            Je n'ai pas dit que le choix d'un langage n'etait pas important.. J'ai juste dit que de savoir si le langage untel est meilleur que truc c'est une guerre de religions ....

            Pour ce qui est du choix d'un langage, et de son adequation avec la tache a effectuer, je comprends ce que tu veux dire, ayant eu a developper un traducteur pour un langage proche du PL/I (mais en bcp plus bugge) vers du C : plus personne ne maintenait ce langage et les outils associes, pas de gens deja formes ..etc ..

            Neammoins quand on voit ce que ca a donne... les gens ont continue a ecrire du C dans la meme optique que celle avec laquelle ils ecrivaient avant : choix des noms, structures .. et y etait d'ailleurs encourage .. avant que leur management se demande s'il ne serait pas bon de passer au C++ .. parce que c'est le futur ....

          • [^] # Re: Les spécifications du langage D sont arrivées

            Posté par  . Évalué à 1.

            Tu as des URLs d'etudes serieuses ?

            • [^] # Re: Les spécifications du langage D sont arrivées

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

              Pour ne pas perdre de temps a lire des études détaillées, tu peux lire "Programming Languages and Software Construction" de Franco Gasperoni, http://libre.act-europe.fr/Software_Matters/02-languages.pdf(...) . C'est orienté Ada, mais ca fait un tour de la question en moins de 40 slides.

              L'étude Ziegler, par exemple, montre que le simple choix du langage permet de diminuer le nombre de bugs livré par 9 par rapport au C, sur un logiciel simultanément 60% moins cher à produire.

              Projettons cela sur Linux, Apache, etc. : ca laisse rêveur, on en serai déja à Linux 4.x si ce n'était pas écrit en C :-)

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 1.

        C'est fini l'époque des demi dieux qui optimisaient leur bousin en assembleur. On n'a plus le temps de jouer.

        Tout a fait. Aujourd'hui on vit à l'époque des start ups qui progressent de +578% et régressent de 99,964% en 3 semaines, et des demi dieux qui engagent 500 programmeurs en CDD pour développer leur progiciels en 3 jours afin que ça sorte le jour de l'introduction en bourse. Pas grave si ça bouffe 25Mo et 100% du CPU pendant 30 s pour afficher "hello world", après tout, ceux qui n'upgrade pas leur materiel tous les 3 mois ne sont pas des gens serieux.

      • [^] # Re: Les spécifications du langage D sont arrivées

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


        Ce raisonnement (le programmeur est un dieu, il saura se démerder) était valable à l'époque ou le C++ a été designé.


        A vrai dire, ce n'était déja plus le cas depuis au moins 10 ans : voir par exemple le rapport Steelman, en quelque sorte cahier des charges du langage Ada. Ca date du début des années 70, et ce principe de base y est déja : la programmation est une activité humaine, il faut que le langage soit un allié puissant, pas seulement un moyen d'expression.

        Ca me fait penser au "peer programming" de XP : celui qui a le clavier s'occupe de tactique, il code les algos. Celui qui est derrière peut avoir une autre vision, plus stratégique. Il pense testabilité, adéquation au besoin, etc. L'esprit human ne sait pas faire bien tout en même temps.

        Dans mon cas, mon compilateur Ada est aussi un pair programmeur : il s'occupe de tout un tas de vérification de cohérence, et pendant ce temps, je me concentre la conception. Je ne me pose presque jamais de question d'allocation mémoire, de cohérence des types, de déréférencement de pointeur, etc.

        Si mon esprit reste concentré sur les pièges que le langage me tends, je suis moins disponible pour concevoir : mes algos sont moins bons, mon soft est mal organisé, et en plus je laisse quand même passer des erreurs à la con, car je ne suis pas dieu.

        Donc oui, le langage est important.

        • [^] # Re: Les spécifications du langage D sont arrivées

          Posté par  . Évalué à 1.

          Je ne suis (encore ;) pas tout a fait d'accord .. Certes Ada a, pour une fois, etait un langage pense .. Neammoins au final, on peut regretter sa lourdeur ...

          Deja a l'ecole Ada ne me plaisait pas .. Le concept oui, le resultat non ...

          Manque de bol (?), dans mon boulot aussi j'ai eu a tater de l'Ada ... les pbs (notamment d'interfacage) etaient nombreux, et les portage hasardeux (le softs tournant sur OpenVMS, Windows, Digital Unix, Unixware et Linux), certes plus par manque ou faible qualite des outils (sauf sous Linux et Unixware, puisqu'on a demande le port sous ce dernier de GNAT) ;) .. Au final, pour avoir revu il n'y a pas longtemps d'anciens collegues, tiut a ete re-ecrit, de zero, en C/C++... et vu la taille de l'engin ca a pas du etre simple .. :(


          Pour ce qui est des algos / organisation .. etc .. c'est plus du a ce moment la a un manque de planification/reflection qu'au langage en lui-meme ... mais on retombe presque sur la notion d'art et d'autosatisfaction dans ce cas la ... ;)

          • [^] # Re: Les spécifications du langage D sont arrivées

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

            Deja a l'ecole Ada ne me plaisait pas .. Le concept oui, le resultat non ...


            On a tous des affinités et des préférences, mais Il faut garder une certaine objectivité dans les jugements.
            Pour reprendre ton exemple, j'ai entendu deux témoignages de logiciel en Ada réécrits complètement en C[++]. Je n'ai pas entendu un seul argument valable pour une telle manip. A chaque fois ca a couté catastrophiquement plus que prévu, et le résultat est moins bon que l'original.

            Si on considère que cela repose juste sur des peurs (peur de voir le langage disparaitre, peur de ne pas trouver de programmeurs, peur de ne plus trouver d'outils, etc.), c'est dommage pour celui qui paye.

            By the way, pour ceux qui ont une image poussiéreuse d'Ada sous emacs (dont je ne dis pas de mal, c'est très efficace), je recommande un petit apt-get install gnat-gps.

          • [^] # Re: Les spécifications du langage D sont arrivées

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

            Manque de bol (?), dans mon boulot aussi j'ai eu a tater de l'Ada ... les pbs (notamment d'interfacage) etaient nombreux, et les portage hasardeux

            C'est off-topic, mais je suis prêt à discuter ce point, car portabilité et interfacage sont deux points fort d'Ada.

            Pour ce qui est des algos / organisation .. etc .. c'est plus du a ce moment la a un manque de planification/reflection qu'au langage en lui-meme

            C'était pour illustrer que le compilo fait bien un boulot qui m'aurai pris du temps et que j'aurai fait moins bien en utilisant un autre langage.
            Toutes choses étant équivalentes par ailleurs (ce qui est loin d'être toujours le cas, on est d'accord), tu seras toujours beaucoup plus efficace en Ada qu'en C[++]. Tu peux essayer avec n'importe quelle planification/reflection/organisation.

            Une façon drastique de changer la donne, c'est retirer l'élément humain du processus de codage. Ce n'est pas impossible, avec des méthodes de modélisation et génération complète du code, mais c'est loin de concerner une grande population dans le logiciel.

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 1.

        On croirait entendre Stroustrup : Si ça segfault c'est de ta faute. Si le language est tellement mal foutu qu'on se prend les pieds dans le tapis facilement sans s'en rendre compte c'est qu'on est un Pierre Tramo.

        En tant que programmeur C++ je ne peux être que d'accord avec Stroustrup ! Le C++ t'offre les outils nécessaires pour te passer de toutes les ruses que l'on fait en permanence en C (utilisation de STL, de toutes les notions du language objet, etc). Le truc c'est que si tu veux coder en C++ comme tu le faisais en C, alors libre à toi, mais ce n'est pas la VRAI façon d'utiliser ce language. D'ailleur beacoup de monde crache sur le C++ alors qu'ils ne savent PAS coder en C++.

        C'est fini l'époque des demi dieux qui optimisaient leur bousin en assembleur. On n'a plus le temps de jouer.
        Mais bien sûr ! Il y a quelqu'un en ce moment même à côté de moi qui est en train de faire du code tout en assembleur (pour l'avionics). Parce que pour utiliser ne serait-ce que le C il faudrait que le compilo soit vraiment sûr, alors il n'est pas utilisé. De cette façon chaque instruction que le proc va utilisé sera réfléchie. Ca c'est la norme DO178. Et quand on fait ça on ne joue pas, comme tu dis. Et je crois que celui qui s'amuse c'est le gars qui fait son kéké avec son garbage collector. Les prog "sérieux" n'utilisent pas ça !

        Perso j'espère que ce n'est pas encore fini cette époque où les gens avaient une parfaite maitrise de ce qu'ils faisaient, parce que comme ça, la prochaine fois que je prendrais l'avion, je serais plus rassuré.

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 1.

      c'est pas le langage qui compte, c'est le programmeur (ou le developpeur si on est pretentieux).

      oui, ou si on veux pas confuser les neuneux qui vont dire à leur entourage "oh, le jeune homme il est programmateur !"...

      ok, ok, je retourne à ma machine à laver ->[]

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 1.

    Oui mais sera il porté sous MultiDeskOs ? car sinon, il n'a aucun avenir !
    :-)

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à -1.

    "covariant return type"

    Ca part mal. Ce n'est pas type-safe. Lorsqu'Eiffel a été conçu le problème de ce genre de construction n'était peut être pas super connu (en dehors des universitaires) mais concevoir aujourd'hui un nouveau langage et refaire les même erreurs qu'il y a 30 ans (C++) c'est un peu balot.

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 3.

      C'est toi le gros balot !

      Un type retour covariant est toujours type safe.
      C'est un type covariant sur les arguments qui n'est pas type safe.
      D'ailleurs c'est aussi dans la norme c++, donc ca ne date pas de Eiffel !

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 1.

        Excusez moi de vous demander pardon, mais c'est quoi un "type covariant" ? Et etre "type safe" ?

        • [^] # Re: Les spécifications du langage D sont arrivées

          Posté par  . Évalué à 1.

          Un type covariant c'est ca :

          Notation pseudo java

          class Nourriture {}
          class Herbe extends Nourriture {}

          class Animal {
          Nourriture mangeQuoi();
          void mange(Nourriture n);
          }

          class Vache extends Animal {
          Herbe mangeQuoi();
          void mange(Herbe n);
          }

          Ta vache implemente animal, mais tu fais varier le type des arguments et des types retour dans le meme sens : Animal -> Vache, Nourriture -> Herbe. La variance des types se fait dans le meme sens du pere vers le fils a la fois pour le type implemente et pour les arguments : ça co-varie.

          Dans le cas du type retour, le programme est type safe, car tu peux ecrire :
          Animal a = new Vache();
          Nourriture n = a.mangeQuoi();
          ==> les types sont respectes

          Dans le cas des arguments, si tu ecris :
          class Viande extends Nourriture {}
          Animal a = new Vache();
          a.mange(new Viande());

          Tu as un probleme : tu es cense appeler une methode qui prend bien un type Nourriture en entree, oui mais Vache n'implemente pas cette methode, Vache implemente une methode "covariante" et ne specifie son comportement que sur un type Herbe => Erreur au runtime => ton code n'est plus type safe.

          Plus d'infos dans ce thread, où, jeune paddawan, je me suis fait explique la vie par des vieux loups : http://linuxfr.org/~Epsos/1819.html(...)

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 0.

      Arrete de boire

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 2.

    Je vois pas l'interet d'un language si proche des autres existants. En plus coté librairie, c'est la misere.

    Mon triptyque a moi, c'est C,Java,Python .

    Y'a deja d'autres langages sur la liste d'attente et autrement plus soutenu par la communauté, ruby, ada, objective C, eiffel, smalltalk, prolog etc ...

    Quand on invente un langage, la moindre des choses, c'est d'apporter suffisament d'idées nouvelles pour convaincre les gens que ca vaut le coup.

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 1.

      ha oui, objective C, quelle tristesse que je ne voie son utilité que sous OSX. (ne me parlait pas de gnustep, je pleure encore le fait qu'il soit sous exploité par la communauté)

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 1.

      Alors si on découvre la langage D avec cette dépèche, c'est vrai, c'est pas si révolutionnaire.

      Pour ma part, j'ai entendu parler du D il y a 2 ans, et à l'époque, j'ai été séduit, mais le port gcc manquait, donc j'ai attendu. Puis se sont démocratisé d'autres langages, comme Ruby par exemple, que je n'utilise pas (parce que je n'ai pas le temps de m'y mettre) mais qui est vraiment bien foutu, ou encore le Caml qui allie force avec souplesse (interptété et peut être compilé, avec des performances proches C sous gcc).

      Enfin D reste néanmoins un bon langage (d'après que ce que j'avais vu à l'époque, car je ne suis pas allé voir les spec récemment), qui interessera sûrement beaucoup de développeurs, car il apporte plein de bonnes choses, tout en gardant une syntaxe assez proche du C et du C++ (ce que le C++ avait fait timidement avec le C).

      Enfin moi mon avis hein ...

    • [^] # Re: Les spécifications du langage D sont arrivées

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

      Le langage presentes des aspects interessants mais l'histoire nous montre que les foncitonnalites d'un langage ne definissent pas son succes.

      Moi ce qui m'epate ici, c'est la tenacite de l'auteur. Mine de rien, il s'est developpe a lui tout seul un compilateur C, un compilateur C++ et maintenant, un compilateur D et le langage complet avec des constructions qui sont loin d'etre triviales. Il en faut de l'investissement pour arriver a un tel resultat.

      Son compilateur C++ etait tres bien classe dans une comparaison des compilateurs les plus conformants au standard C++ (d'apres une etude du DDJ) et pas mal au niveau perf.

      Moi je dis: Messieurs, chapeau bas! [comme dans "La Peste"]

  • # D vs Eiffel

    Posté par  . Évalué à 1.

    Moi le probleme majeur que j'ai avec D, c'est que je ne vois pas pourquoi D réussirait la ou Eiffel a échoué: D comme Eiffel sont tous les deux des langages compilés, avec GC.

    Donc je les voit remplir plus ou moins la même niche, mis à part que D est plus "systeme", exemple: D définit comment le code assembleur embarqué est définit, ce qui permet d'avoir du code assembleur "portable" de compilateur à compilateur.
    Et Eiffel est plus haut niveau: Eiffel a l'héritage multiple tandis que D simplifie l'implémentation du compilateur en utilisant juste l'héritage simple et les interfaces (à la Java).

    Eiffel est quasiment inconnu: Pourquoi D aurait plus de succes?

    Mis a part l'attrait de la nouveauté, je ne vois pas ce qu'apporte vraiment D de si interressant par rapport a Eiffel..

    [ Pour info, si Eiffel est mort, c'est probablement qu'au départ les environements de développement d'Eiffel étaient tres cher, maintenant il y a SmartEiffel qui est sous licence GPL. ]

    • [^] # Re: D vs Eiffel

      Posté par  . Évalué à 0.

      Et Eiffel est plus haut niveau: Eiffel a l'héritage multiple tandis que D simplifie l'implémentation du compilateur en utilisant juste l'héritage simple et les interfaces (à la Java).

      Warning, troll in progress : l'héritage multiple, c'est MAL (tm).

      C'est peut être une des raisons qui handicape Eiffel. Moi, je pense que D peut connaître un certain succès... En raison de sa très grande proximité du C (il semblera familier à beaucoup de développeurs), en raison de son nom très recherché qu'on retient tout de suite (seulement deux octets de mémoire avec le \0 !) et des ajouts intéressants par rapport au C/C++, qui en font à mon avis un bon successeur en puissance (Garbage Collector, foreach, tableaux à taille variable, Syntaxe sympa pour les propriétés d'objets ( http://www.digitalmars.com/d/cpptod.html#properties(...) ) etc...).

      • [^] # Re: D vs Eiffel

        Posté par  . Évalué à 2.

        >Warning, troll in progress : l'héritage multiple, c'est MAL (tm).

        Bah, ça dépend comment tu l'utilise: au boulot on a utilisé l'héritage multiple en C++ pour hériter de classe permettant de stocker/lire les objets dans une base de donnée (ObjectStore), c'est un peu complexe certes, mais utile.

        Je n'ai pas entendu de critique de la part des utilisateurs d'Eiffel sur l'héritage multiple, qui a l'air "plus simple" a utiliser sous Eiffel qu'en C++, maintenant je n'ai peut-etre pas assez tendu l'oreille (non la covariance ça ne compte pas, c'est un autre probleme).

        D supporte les interfaces ok mais une interface étant juste une classe abstraite virtuelle, tu peux faire de la "programmation par interface" si tu veux avec l'héritage multiple, c'est juste un cas particulier, comme j'ai dit plus haut tout dépend comment tu utilise l'héritage multiple, c'est puissant il faut juste ne pas en abuser, mais bon c'est comme tout!

        Mis a part la syntaxe assez proche du C, franchement Eiffel apporte deja ces atouts depuis des années: le GC, les tableaux a taille variable, les propriétés d'objets (enfin si je me souviens bien), rien d'original! Et la définition d'Eiffel n'est pas en béta version..

        Mais bon si D peut réussir, la ou Eiffel a échoué, j'applaudirais!
        Tu me permets juste d'être plutot sceptique..

      • [^] # Re: D vs Eiffel

        Posté par  . Évalué à 1.

        Warning, troll in progress : l'héritage multiple, c'est MAL (tm).

        J'utilise tous les jours l'héritage multiple, à un tel point que je serais très handicapé si je devais m'en passer.

        L'héritage multiple pose des problèmes, certes, mais (si le langage et le compilateur sont valables) pas aux programmeurs. Cela pose un problème de définition du langage (pour, par exemple, pouvoir sélectionner une primitive parmi plusieurs héritées portant le même nom) et un problème de compilateur pour engendrer des exécutables ou un environnement d'interprétation efficaces, malgré les nombreux problèmes que posent l'héritage multiple et l'héritage répété (conséquence du premier) aux concepteurs de langages et à ceux qui implémentent leurs compilateurs respectifs. Je ne fais partie d'aucun de ces deux groupes. Et toi ?

        Pour moi, le Saint Graal en matière de langage, c'est : héritage multiple, généricité, concurrence. Le langage que j'utilise implémente très bien les deux premiers concepts. Pour le troisième, j'attends toujours qu'un compilateur implémente ce qui est prévu à ce sujet dans la définition du langage.

    • [^] # Re: D vs Eiffel

      Posté par  . Évalué à 3.

      Et Eiffel est plus haut niveau

      Forcement avec 324 m

      ;-)

    • [^] # Re: D vs Eiffel

      Posté par  . Évalué à 2.

      Je pense à d'autres raisons pour la non-utilisation de Eiffel à l'heure actuelle.

      1) Le langage a était standardisé trés tard
      2) Pas de bibliothèque standard, (bon ca change mais c'est pas encore ca ...)
      3) Les compilos ne sont pas 100% compatibles entres eux
      4) Pas de bibliothèque graphique _native_ (en Eiffel). Seuls des binding existe (j'ai entendu dire que quelqu'un s'y etait mis mais sa avance doucement ...) Et elle ne sont que peu suivie ...
      5) Peu de bibliothèques et pas pour tout les usages ...
      6) Gestion de la concurences délicate ...
      7) Chargement dynamique de code délicat aussi ...
      8) Enfin je suis d'accord aussi pour dire qu'il y a peu d'environement de développement totalement intégré
      (C'est raison sont parfois un peu anciennent et commencent à toutes etres résoluent mais c'est un peu tard! ... 20 ans aprés ...)

      Bref plein de facteur externes au langage lui même (qui est le langage objet industriel le mieux fait ...) qui ont plombé Eiffel pendant des années ...

      • [^] # Re: D vs Eiffel

        Posté par  . Évalué à 2.

        8) Enfin je suis d'accord aussi pour dire qu'il y a peu d'environement de développement totalement intégré : Il y a peu de compilateurs aussi, trois ou quatre.

        Il y en a au moins un, très bon sous Windows, bon sous GNU/Linux : EiffelStudio de Eiffel Software, et c'est un environnement propriétaire. Peut-être VisualEiffel est-il bon aussi, je ne l'ai jamais essayé. L'IDE, c'est ce qui manque à SmartEiffel, avec l'implémentation de SCOOP (pour le coup, c'en serait un de scoop, vu qu'aucun compilateur ne l'implémente pour le moment).

      • [^] # Re: D vs Eiffel

        Posté par  . Évalué à 1.

        > a était

        Whoua, une petite sieste après le repas serait la bienvenue?

        Je suis globalement d'accord avec les raisons que tu avances mis à part avec le point 5 (peu de bibliothèques) et bien, c'est le même problème pour tous les langages au début, non?

        Pour le point 6, je ne sais pas: en C et en C++ aussi il n'y a pas de gestion dans le language des processus/thread, mais je ne suis pas sur que ça soit un gros handicap.

        Cependant je me souviens encore que la prochaine version d'Eiffel allait avoir un support de la concurrence super, j'ai du entendre ça en 93 ;-)

    • [^] # Re: D vs Eiffel

      Posté par  . Évalué à 1.

      Pour paraphraser Frank Zappa : Eiffel is not dead. It just smells funny.

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 1.

    Ne serait il pas plus simple de faire comme Effeil : utiliser le langage C comme format intermédiaire puis laisser un compilateur C produire le code natif ?

  • # Re: Les spécifications du langage D sont arrivées

    Posté par  . Évalué à 2.

    Personnellement, je trouve ca tres bien D : c'est de plus haut niveau que le C, il y a moins d'erreurs de design que le c++ ou le java.
    C'est compile, donc ca promet de bonnes performances.
    Le langage est plus sur et autorise plus de choses que ses concurrents.
    Il y a deja une grosse communaute autour de D.
    Certes, au niveau librairie c'est encore un peu pauvre, mais des langages comme Python, Ruby, et meme Perl ne se sont pas fait en deux jours non plus : ca va venir.

    Je n'arrive pas a comprendre pourquoi tant de gens crachent sur un nouveau langage ? Pourtant dans la communaute du libre, on a tendance a dire que la diversite c'est bien : ca permet a chacun de trouver son bonheur, qu'il vaut mieux plus de choix que pas de choix du tout ...

    • [^] # Re: Les spécifications du langage D sont arrivées

      Posté par  . Évalué à 1.

      Très d'accord avec toi :-)

      S'il existe des familles de langages qui ont des perspectives différentes, l'utilisateur peut aussi faire le choix dans une famille, pour prendre celui qui lui convient le mieux (C++, - pas java :) -, D, ou je ne sais quoi, C ne rentrant pas dans la même catégorie car il n'est pas objet :-)) ).

      Tout ce qui compte pour un langage est que le développeur et/ou l'entreprise y trouve son compte (temps de développement, portabilité, extensibilité, suivant ce qu'il/elle désire).

      Et c'est vrai que les assertions (c'est ADA qui fait ça aussi , ou Eiffel je ne sais plus), c'est un plus pour un langage qui reste proche de ses copains C++ et - pas java j'ai dit ! :-)

      • [^] # Re: Les spécifications du langage D sont arrivées

        Posté par  . Évalué à 2.

        Vi, les assertions, ca s'appelle "design by contract" et c'est Eiffel qui l'a invente. Ca existe peut etre en Ada sous forme de librairie, je ne sais pas.

        Il y a une grosse theorie qui tourne autour de ca en Eiffel et qui permettrait de "prouver" qu'un programme fait ce pour quoi il a ete specifie en analysant toutes les dataflow a partir de tous les contrats, ou eventuellement de montrer du doigt les parties de code qui ne rentrent pas dans le contrat.
        Parait que certains ateliers logiciels font ca tres bien, le probleme etant que le programmeur doit parfois tenir la main a l'analyseur pour qu'il ne se fourvoie pas trop.
        Enfin en tout cas, le principe est tres seduisant.

Suivre le flux des commentaires

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