J'ai vraiment adoré l'article sur Haskell dans le dernier numéro, essayez d'en écrire une suite svp !
Merci.
Bravo pour l'article sur Haskell
mar, 08/01/2008 - 22:52
#1
Bravo pour l'article sur Haskell
C'est moi qui vous remercie.
Cet article semble susciter beaucoup d'intérêt et j'en suis vraiment très heureux.
Il y a une suite qui paraîtra dans le 105.
Et puis aussi bientôt d'autres choses dans le même domaine bientôt ;)
Chouette, je suis comblé :)
>>Et puis aussi bientôt d'autres choses dans le même domaine bientôt
On peut en savoir un peu plus là-dessus ?
D'autre part, j'aurai une petite question à te soumettre.
Je n'ai pas le mag sous les yeux au moment où j'écris ces lignes, mais en lisant ton article je me suis posé une question: on donne un code source pour calculer une factorielle, dans un style impératif et donc pas trop dans la philosophie d'Haskell. On rectifie par la suite...
Très bien, mais comment sait-on qu'on est justement dans la bonne direction ? Existe-t-il des outils pour ça, ou du moins certaines recommandations (comme par exemple certaines PEP pour Python) ?
Merci encore.
Oui bien sûr. Il suffit d'acheter Programmez! régulièrement. ;)
Ou même mieux, de s'abonner ;)
Des outils, je ne dirai pas ça. Mais des didactitiels, des livres. (des cours à l'école aussi, mais moi j'y suis pas allé alors... :lol: ) Et puis aussi l'expérience. Coder correctement en C++ ça s'apprend, coder correctement en Python ça s'apprend, coder correctement avec un langage fonctionnel comme Lisp, Erlang ou Haskell, ça s'apprend aussi.
En Haskell comme avec tous les langages, dès qu'on est familiarisé avec sa philosophie, des choses deviennent évidentes :)
Merci Frederic,
A vrai dire, je me doutais un peu de la réponse à vrai dire...:)
Sinon, pour ceux que ça intéresse, j'ai créé un pdf à partir des sources de 'Haskell for C programmers', par ici : http://kib2.free.fr/Haskell/
Il n'est pas encore parfait, merci de me signaler les bourdes.
Bel effort :)
Je pense que ton document évitera à bien des programmeurs impératifs de buter dans l'apprentissage d'Haskell. Je n'ai pas tout lu très attentivement, faute de temps, mais je ne pense pas avoir vu de "bourdes" :)
Une remarque si tu me le permets. Tu t'es lancé dans le difficile exercice d'expliquer la monade à partir de la monade IO qui est très particulière (avec état et opaque). Ca sera peut être bien d'expliquer déjà la monade en tant que telle, vu que IO est un cas très particulier. Sur le fond tout ce que tu dis dans ce chapitre est ok pour moi, mais il y a une imprécision je pense. C'est page 19 "The ’<-’ arrow is used to bind the result of an IO operation to a variable. ’getLine’ has a type of ’IO String’. The
’do’ notation says that a monad function like ’getLine’ can be prefaced by a variable name and the left arrow. That variable name comes into scope at that point in the function and when the monad function is evaluated, and its return value will be assigned to the variable."
Normalement tu ne peux pas dire que <- crée un binding. C'est une illusion d'optique induite pas les sucres syntaxiques do et <-
Comme tu le sais, ce qui se passe, c'est :
Donc name est "foncteurisé" (je ne sais pas comment faudrait expliquer ça en anglais) par la fonction/foncteur >>= de la monade qui s'appelle malencontreusement bind. Mais il n'y a pas de binding sur name. Pour preuve le code suivant est légal:
Alors que s'il y avait un binding, il ne le serait pas.
C'est même un des gros intérêts de la monade, car cela permet à un compilateur malin de faire des update destructifs dans un contexte purement fonctionnel. Chose qui ne peut exister dans des langages "ML" dépourvus de monades
De même à propos de getLine, dans la phrase citée ci-dessus, tu dis "its return value will be assigned to the variable"
En fait non. La valeur de retour de getLigne c'est IO String, pas String et IO String ne peut pas être assignée. Ce qui se passe, c'est que le String de IO String est foncteurisé dans le contexte de la monade IO. Ce n'est pas vraiment la même chose.
Bon maintenant avec ce que je viens de dire, personne débutant en Haskell ne va avoir une idée claire de ce qu'est la monade, alors qu'avec ce que tu as dit on en a une bonne idée malgré tout. Pour sûr qu'expliquer ça n'est pas facile. Mais je crois vraiment d'expliquer monade et monade à état avant IO serait mieux. Le bât blessant par le fait que c'est à IO qu'on est confronté dès qu'on écrit le moindre Hello World. :(
Ah... vulgariser est un exercice difficile, je suis bien placé pour le savoir. On est bien d'accord que mes remarques n'enlèvent rien au formidable travail que tu as fait n'est-ce pas ?
Bonjour Frederic,
Tout d'abord merci pour le retour sur ta lecture.
Je tiens quand même à rectifier une chose importante : je ne suis pas l'auteur de l'ouvrage ! :oops:
C'est à Eric Etheridge qu'il faut donner les fleurs, et le livre se trouve en ligne par ici http://www.haskell.org/~pairwise/intro/intro.html.
Mais comme il le dit sur son site, aucune version papier n'était encore disponible. Je me suis simplement contenté de transcrire son contenu en langage de markup perso. Un script python se charge alors de la conversion en d'autres formats, LaTeX en l'occurence pour mon cas avec un petit plus : la coloration syntaxique. Si j'ai demandé une relecture, c'est que certains caractères peuvent parfois poser problème à LaTeX ($,&,%,etc.).
J'ai contacté Eric et il m'a permis de le diffuser. Il le placera sur son site lorsque le document final sera sans fautes.
Maintenant il faudrait faire part de tes judicieuses remarques à Eric (en Anglais je suppose) :) Je débute personnelement Haskell, et j'ai encore beaucoup de mal à comprendre réelement ce que sont les Monads.
Apparement tu as l'air de bien connaître Lisp, aussi quels sont les différences que tu ferais entre ces deux langages ?
A bientôt.
D'abord faut bien comprendre ce qu'est un foncteur. Après c'est plus facile de saisir ce qu'est la fameurse monade :)
Houlà le sujet est très (trop) vaste. Ils sont à la fois très semblables et très différents.
Lisp est ultra vieux, est fonctionnel impur, est typé dynamiquement, avec une vitesse d'exécution proche de C, les programmes ne peuvent pas être prouvés. On peut charger du code à chaud, mais il est n'est pas paresseux.
Haskell est utra moderne, est fonctionnel pur, typé statiquement. Haskell implémente complètement le système de type Hindley Milner (ça fait toujours bien de sorti ça dans la conversation ;) ) , plus lent que C, les programmes peuvent être prouvés. On ne peut pas charger du code à chaud, mais il est totalement paresseux.
Le vieux (mais toujours en avance sur son temps à bien des égards) et le moderne sont deux langages formidables, avec des domaines d'utilisation privilégiés.
Tiens par exemple on implémentera volontiers en autre langage en Lisp alors qu'on écrira volontiers un compilateur pour un autre langage en haskell :)
Vraiment le sujet est trop vaste. Mais j'insiste sur un point. Ceux qui pense que Lisp est obsolète ont tort ;) Lisp après 50 ans reste génial.
Merci pour toutes ces précisions.
Lisp me semble un peu plus "abordable", le fait qu'il soit "vieux" est plutôt pour moi un signe de qualité (comme LaTeX par ex.) et pouvoir générer du code à chaud est un plus non négligeable. Il lui manque certes l'évaluation paresseuse, mais on commence à voir cela implémenté dans les autres langages (Python par exemple à quelque chose de similaire avec les generators et le 'yield'). Peut-être que Lisp proposera la sienne un jour...
J'ai essayé Haskell, mais j'avoue que mes débuts sont difficiles (surtout par manque de doc d'ailleurs). Par exemple pour afficher les éléments d'une liste un à un sur chaque ligne, j'ai mis une journée à trouver mapM_ (ou mapM selon les cas), ça n'encourgae pas l'apprentissage. Pourtant, j' acrroche vraiment : clair, concis, efficace.
Maintenant j'hésite beaucoup : par lequel commencer (et pourquoi ne pas commencer les deux en parallèle ) ?
Oui l'apprentissage est difficile avec Haskell. Surtout que le peu de doc qu'on trouve est en général destiné à un public qui connait bien la programmation fonctionnelle.
Pour mapM_ et les autres. Faut bien prendre le temps d'étudier les fonctions qui sont dans le prélude.
En dehors de ça, lire
Haskell, The Craft of Functionnal Programming, Simon Thompson – Addison Wesley
ou
The haskell School of Expression, Paul Hudak – Cambridge University Press
est vraiment d'une grand aide pour démarrer. Le second proposant des exemples plus intéressants (multimédia) que le premier, mais en étant d'une lecture plus difficile.
En effet. Haskell c'est vraiment génial.
Pourquoi pas en effet. L'univers de Lisp est réellement passionnant, pour sûr
En plus tu as des IDEs évolués (Lispwork ou Allegro) pour Lisp
Ah ! Puisqu'on on est dans les langages géniaux, il y a Erlang aussi. ;)
Merci pour tout ça, je ne connaissais pas Lispwork ou Allegro.
A propos de Lisp d'ailleurs, pourquoi a-t-on dériver autant ce langage ?
Difficile de choisir : common-Lisp, Scheme ? emacs-Lisp ? ...
Deux nouveaux livres sur Haskell :
- Un qui vient de sortir, j'ai acheté et commencé à lire : http://www.cs.nott.ac.uk/~gmh/book.html . Très bon et bien expliqué. [Je vous préviens de suite, n'essayez pas la version ebook, je me suis fait avoir : le soit disant 'viewer' n'est pas compatible Gnu-Linux].
- Un autre en préparation par OReilly Media http://book.realworldhaskell.org/. Attention, le site sature ce soir, c'est la première fois qu'ils publient. Concept original (comme le Djangh book de Python), on publie en ligne en laissant les lecteurs commenter . Pas de date de publication pour le moment.
Sinon, il y a bel article de Free Software Magazine (quoique un peu obsolète certainement) par ici : http://www.freesoftwaremagazine.com/articles/haskell/
Erlang m'a aussi beaucoup plû, mais je ne peux pas tout attaquer à la fois :)
A bientôt, j'attends le prochain n° de Programmez!
Il y a des raisons historiques
Common Lisp bien sur. C'est actuellement LE Lisp. Je dis LE Lisp parce qu'il est standard. Comme peu de langages d'ailleurs. C, C++, Ada.
D'ailleurs il est le seul langage standard à disposer une interface graphique standard (CLIM)
Allegro et Lispworks sont tous deux des implémentations de Common-Lisp.
Sinon en Open Source tu as le remarquable SBCL, qui implémente le standard parfaitement rigoureusement et qui est vif comme l'éclair à l'exécution. Un bijou :)
Attention Scheme n'est pas un Lisp. Il y ressemble c'est vrai, mais avec des différences. Scheme apporte d'ailleurs une chose qui n'existe pas en Lisp, la continuité. (Je te laisse te renseigner :) )
Emacs-Lisp est un Lisp à l'ancienne, pour des raisons historiques évidentes. Il sert de moteur à Emacs et il sert aussi à le programmer, ce qui fait qu'Emacs reste l'éditeur le plus génial de tout l'univers connu et inconnu :)
Emacs-Lisp est en portée dynamique, alors que Common Lisp est en portée lexicale. Grosse différence (Je te laisse te renseigner :) )
Je pense bien. Vraiment génial. C'est actuellement la meilleure solution pour les applications concurrentes et/ou distribuées.
Remarque il existe aussi ABCL/1, qui reste confidentiel et universitaire (au Japon) et qui un langage concurrent "à la Erlang". Ce qui est amusant c'est que son créateur l'a écrit... en Lisp :)
Merci pour les références sur les bouquins :)
Ok, merci ça me permet d'y voir un peu plus clair, la notion de portée ne m'étais pas étrangère du reste.
Maintenant, j'avoue que trouver des tutos sur Common Lisp, c'est pas gagné. ..ceux que j'ai commencé à lire utilisent certains modes pour Emacs.
N'aurais-tu pas dans tes trouvailles quelques chose de simple qui utilise SBCL avec n'importe quel éditeur et la ligne de commande (je trouve que c'est une meilleure approche pour commencer)?
Je ne connaissais pas ABCL/1, les Japonnais sont forts en ce moment : Ruby, ABCL/1, ...vont-ils s'arrêter ?!
Avec Google tu vas en trouver. Et il y en a dans Lispworks et allegro aussi :)
Lol :lol:
Emacs bien sûr ;)
J'espère ;) :lol:
Au risque de faire bondir certains, je n'apprécie pas beaucoup Ruby, qui certes est à la mode en ce moment.