Version imprimable
Tu as certainement la capacité de faire un effort pour suivre le paradigme.Citation:
Envoyé par Thierry Chappuis
Pour simplifier l'histoire : tu dois programmer comme si tu faisais des maths et oublier les habitudes du C (et dérivé). Je pense que tu gagnerais à te jeter dans un cours qui enseigne tout de suite, à la dur -_-
Merci beaucoup, je vais commencer par là.Citation:
Envoyé par Jedai
Thierry
OK, je vais me jeter à l'eau avec les ouvrages à ma disposition. En suivant le lien donné par Jedai, j'ai pu avoir la confirmation ici que "Haskel: The Craft of Functional Programming" semble adapté à mes besoins de débutant en programmation fonctionnelle. J'ai également trouvé l'ouvrge de Graham Hutton à la bibliothèque et je vais y jeter un oeil.Citation:
Envoyé par Garulfo
Merci pour vos conseils.
Thierry
@gorgonite : Je pense que le mieux serait de se débarrasser de OCaml une bonne fois pour toutes, étant donné que le projet est quasiment mort, ou en salle de réanimation.
@Thierry Chappuis : Les monades, c'est tout con, mais tout le monde pense le contraire. Pour les comprendre, il faut savoir que Haskell est un langage paresseux...
En fait, dans un langage paresseux, à l'inverse des langages stricts (C, OCaml...), les valeurs ne sont calculées qu'au moment de leur utilisation... c'est comme ça que l'on peut, par exemple, écrire la liste suivante [1 ..] contenant tous les nombres entiers plus grands que 1, et pour autant ne pas encombrer la mémoire, car ces nombres seront effectivement évalués lors de leur utilisation.
Une fois dit ça, on comprend mieux que dans un programme Haskell standard il est difficile, voire impossible, de prédire l'ordre d'évaluation des arguments. En ce sens, ne serait-ce qu'afficher à l'écran des messages dans un certain ordre ou devoir faire des opérations les unes après les autres de façon explicite, est impossible.
C'est pour celà que les monades ont été introduites. Les monades sont LA façon dans un langage paresseux comme Haskell d'effectuer des actions ou d'évaluer des valeurs dans un ordre prédéterminé.
Là où les choses deviennent un peu plus difficiles à saisir, c'est que les monades sont elles-mêmes des valeurs ! Pour ne pas casser l'aspect paresseux du langage, il est nécessaire d'enfermer cette succession d'évaluations dans une valeur particulière, elle-même paresseuse. C'est ce que l'on appelle en informatique une fermeture. La même notion existe pour OCaml, mais les valeurs paresseuses sont créées de façon explicite.
Il y a ensuite d'autres avantages aux monades, comme la modularité dans le code et une certaine élégance ("Elegance is an attitude"...) dans le code que les Haskellers aiment bien (et moi aussi d'ailleurs).
Ensuite, toutes les considérations théoriques ne sont que du sucre glace d'habillage.
Merci! Ca reste abstrait pour l'instant et je ne saisis encore réellement ce que représente une monade, mais je reviendrai sur ton commentaire à plusieurs reprises durant mon apprentissage. Nul doute que ça va m'aider.
Meilleures salutations
Thierry
P.S. OCaml est-il réellement moribond?
Non, mais bon, étant donné que le langage en lui-même n'évolue plus depuis OCaml 3.07 (2002 plus ou moins... donc bientôt 6 ans), que les gens s'en occupant n'en font pas leur priorité (ils sont sur des projets de preuves formelles, entre autres) et que le remplaçant de OCaml ne présente pas un engouement de la part du staff significative... ben Haskell, avec sa communauté en majorité jeune, dynamique et sympatique, même si moins bonne techniquement (quoique ça s'est nettement amélioré), est aujourd'hui LE langage fonctionnel, sans aucun doute.
Le problème de OCaml, c'est que le staff de l'INRIA a voulu faire d'une chose accessible à tous (nuls, moins bons, bons et chevronnés) un langage d'élite intellectuel normalien polytechnicien mineur centralien et ayant résidé à Fresnes ! Forcément, le produit s'est vu trop tôt enfermé en classe prépa et en fac, alors même qu'il avait un très gros potentiel : omni-paradigme, très performant, bien documenté, etc...
Haskell, c'est l'inverse : un truc de théoricien quantique autiste dont la communauté a fait un langage accessible à tous par un gros effort de promotion.
Voilà, la différence est là et pas ailleurs.
La supériorité technique (car OCaml est meilleur que Haskell sur le plan technique, même si l'écart se creuse à vitesse V) ne suffit pas à imposer un produit, payant ou non (les deux sont gratuits, en partie).
Ce qui est bien avec toi, c'est que tu n'es pas dutout un extrémiste... Il faudrait peut être commencer par se débarasser des langages qui n'ont connu aucune évolution depuis 30 à ce compte là non ? :-\ Pourquoi est ce qu'il faudrait 15 nouvelles fonctionnalités par jours pour qu'un langage soit fonctionnel (pas dans le sens != impératif hein ;-)) et intéressant ? Et puis bon, les variants polymorphe par exemple sont un exemple de fonctionnalité ajouté il y a peu, et à ma connaissance, Xavier Leroy envisage encore un certain nombre d'apport au langage et on peut espérer que les travaux de Dider Rémy sur le système de module apporteront du neuf dans cette direction. Bref... ce n'est pas le thème du fil :-)Citation:
Envoyé par InOCamlWeTrust
Tu mélanges un peu tout là... Les fermetures n'ont rien à voir avec les monades, pas plus qu'avec l'évaluation paresseuse.Citation:
Envoyé par InOCamlWeTrust
Par ailleurs s'il est vrai que certaines monades permettent de forcer l'ordre d'évaluation, ce n'est pas le cas de toutes, loin de là.
--
Jedaï
Je ne suis pas convaincu vois-tu.Citation:
Envoyé par InOCamlWeTrust
À mon avis, Lisp (CommonLisp/Scheme etc.) forme LE langage fonctionnel. C'est du moins l'impression que je vois dans les parutions. Beaucoup d'exemples et de prototype en Scheme, rarement en Haskell.
La fermeture n'a rien à voir avec l'évaluation paresseuse. Une fermeture est une fonction évaluée dans un environnement qui est capturé par la fonction lors de sa définition. C'est le principe du let en général dans ces dérivés des langages fonctionnels. Ça permet de capturer des définitions de fonctions pour s'assurer qu'elle ne seront pas redéfinies. Car sinon l'évaluation des variables se déroule dans l'environnement top-level. Bon quoiqu'il en soit, les fermetures sont un « classique » de la programmation fonctionnelle. Ruby dispose de réel fermeture. Ce qui n'est pas le cas de Python. La notion de « paresseux » est autre chose. C'est une amélioration de l'évaluation en ordre normale.Citation:
Envoyé par InOCamlWeTrust
On s'éloigne du sujet du fil, mais bon je suis curieux. Pourquoi dis-tu que Python ne dispose pas d'une réelle fermeture? Il me semble que c'est le cas depuis Python 2.2, non? Quelles propriété doit avoir une réelle fermerture?Citation:
Envoyé par Garulfo
Sinon, avec tout ça, les monades sont pour moi un sujet de plus en plus confus. Je vais m'assoir à une table avec une bonne tasse de thé et lire attentivement les ressources à ma disposition. J'y verrai sans doute plus clair après.
Merci pour tout
Thierry
Citation:
Envoyé par Garulfo
qui te dis que je considère que les mutables font partie du paradigme fonctionnel... :roll:
donc je persiste et signe... tant qu'on reste en paradigme fonctionnel PUR et qu'on ne joue pas avec des foncteurs, ça reste quand même du lambda calcul typé :D
Aurez-vous quelques références abordables au sujet des aspects théoriques du lambda calcul, typé ou non?
Le lambda calcul et la théorie de catégories sont-il les deux points à étudier si je désire étoffer un peu mes connaissances théorique par rapport à la programmation fonctionnelle ou y a-t'il d'autres aspects à creuser?
Thierry
le lambda-calcul :
http://citeseer.ist.psu.edu/252095.html (ce n'est pas celui que je voulais, mais c'est la même auteur ;))
la théorie des types :
http://www.lix.polytechnique.fr/~dow...es_types.ps.gz
sur la théorie des catégories, DrTopos a certainement mis plein de liens dans ses posts ;)
Merci pour les liens, gorgonite!
Je vais également essayer de voir dans les posts de DrTopos. Généralement, ses posts sont d'un niveau technique trop élevé pour moi. Je vais jeter un coup d'oeil aux liens qu'il donne.
Thierry
Le lambda calcul peut être un plus, mais c'est loin d'être vital (j'ai fait 6 ans de prog fonctionnel sans la moindre notion de lambda calcul)Citation:
Envoyé par Thierry Chappuis
La théorie des catégories, si tu ne veux pas *créer* ton propre langage, je pense sincérement que ça ne te servira à rien.
je ne pense pas non plus que ce soit indispensable, mais ça introduit bien à la "logique à utiliser" en programmation fonctionnelleCitation:
Envoyé par alex_pi
Citation:
Envoyé par alex_pi
pas tout à fait d'accord surtout s'il s'attaque au Mont Haskell... ;)
mais il est clair que les Monades sont bien moins complexes que l'ensemble de la théorie des catégories
en ce qui concerne la théorie des types, ça me semble indispensable aussi bien avec OCaml qu'Haskell... même si l'on peut quand même s'en passer et se forger une intuition de la chose ;)
Je vais déjà survoler les liens que m'a donné gorgonite pour me faire une idée... et si ça peut aider.
Thierry
Personnellement encore, on m'a présenté les monades en programmation fonctionnelle ou en Coq sans avoir à utiliser la théorie des catégories...Citation:
Envoyé par gorgonite
Ca dépend ce que tu appeles théorie des types. Pour moi c'est "théorie intuitionniste des types de Martin-Löf, System F, CCI". Je ne suis pas sûr que ce soit vraiment utile :-) En OCaml, une fois que tu as compris ce qu'est le type fleche et a peu pret les types algébriques, tu t'en sors assez bien. Et par contre, je pense que sans avoir un peu pratiqué la prog fonctionnelle, la théorie des types, ça pique vraiment !Citation:
en ce qui concerne la théorie des types, ça me semble indispensable aussi bien avec OCaml qu'Haskell... même si l'on peut quand même s'en passer et se forger une intuition de la chose ;)
Disons que ce n'est pas parce que OCaml et Haskel ont des fondement théorique de qualité qu'il est vraiment indispensable ni même utile d'en saisir tous les tenant et aboutissant avant de se lancer.
Pour moi le schéma serait plutôt : commencer la prog fonctionnelle, se forger une intuition, et seulement ensuite étudier les fondements théoriques de cette intuition.
Surtout ne place pas la théorie avant le langage, la théorie vient après le langage. Aucune de ces trois théories n'est accessible si tu n'es pas déjà un expert en programmation fonctionnelle:
- au lieu détudier le lambda-calcul mieux vaut savoir que la flèche est associative à droite (c'est dit dans le Gentle introduction to Haskell)
- au lieu d'étudier la théorie des catégories mieux vaut savoir ce qu'est un type inductif (désolé je n'ai pas de référence en tête donc je te renvoie à la Partie VIII de mon tutoriel)
- au lieu d'étudier la théorie des types mieux vaut connaître les règles d'inférence (là encore je n'ai pas de référence en tête donc je te renvoie à la Partie II de mon tutoriel qui détaille ces règles pour OCaml, expression par expression)
Du point de vue du programmeur fonctionnel (surtout débutant) chacune de ces 3 théories se résume à l'unique notion en gras.
Un dernier conseil (j'essaye de donner un minimum de conseils qui soient un maximum utiles): pour commencer considère que ton langage fonctionnel (par exemple Haskell) n'est qu'une calculatrice, de cette façon tu te concentre vraiment sur le paradigme fonctionnel et tu n'es pas entravé par les monades et plus généralement la difficulté à interagir/interfacer (ce qui, il faut le reconnaître, n'est pas le point fort du paradigme fonctionnel).