Ababacar Octopuce a écrit 8 commentaires

  • [^] # Re: Mouais

    Posté par  . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". É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: langages fonctionnels

    Posté par  . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". É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.)
  • [^] # Re: langages fonctionnels

    Posté par  . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". É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: Mouais

    Posté par  . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". É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  . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". É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.
  • # C--

    Posté par  . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". É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(...)
  • [^] # Re: TeXmacs

    Posté par  . En réponse à la dépêche (Re)découvrons Lyx. Évalué à 1.

    C'est clair ca consomme. Je conseille fortement de suivre les indications pour compiler avec les optimisations, car ca ameliore grandement la vitesse.

    Cela dit, y a un des auteurs qui ecrit un livre de maths avec, ce qui est bien aussi gourmand qu'une these. Je pense qu'il utilisa la fonctionnalite qui permet de decouper un document en plusieurs fichiers.

    Ce qui est bluffant aussi, j'avais oublie de le dire, c'est le mode mathematique qui est mille fois mieux que celui de LyX. Le systeme de raccourcis est tres intuitif et c'est un bonheur de voir sa formule telle qu'elle sera effectivement rendu a l'impression.
  • # TeXmacs

    Posté par  . En réponse à la dépêche (Re)découvrons Lyx. Évalué à 1.

    J'ai recemment decouvert ce qui pourrait bien devenir un concurrent tres serieux de LyX: il s'agit de TeXmacs (http://www.texmacs.org(...)). Il fonctionne sur le meme principe que LyX (cad qu'il s'agit d'un traitement de texte structure) mais en WYSIWYG complet et réel: TeXmacs affiche en temps réel le rendu DVI anti-aliasé! C'est d'une qualite graphique tout simplement jamais vue! Et ca, tout en etant structure comme LaTeX ou LyX!

    Bien sur, c'est un peu moins avance que LyX mais c'est deja tres developpe. Personnellement, je m'en sers maintenant quotidiennement alors que j'utilisais plutot LaTeX ou LyX auparavant.

    A essayer absolument!

    En esperant aussi que des volontaires se joindront aux developpeurs actuels pour que ca evolue encore plus vite.