Merci pour ces conseils. Pour le moment, j'attends le livre de Gaham Hutton "Programming in Haskell" que j'ai commandé à la bibliothèque. Je vais débuter avec ça. Je pense que j'ai pas mal de matière pour débuter mon apprentissage.
Thierry
Version imprimable
Merci pour ces conseils. Pour le moment, j'attends le livre de Gaham Hutton "Programming in Haskell" que j'ai commandé à la bibliothèque. Je vais débuter avec ça. Je pense que j'ai pas mal de matière pour débuter mon apprentissage.
Thierry
Non tu n'as pas besoin de connaître le lambda-calcul pour faire de la programmation fonctionnelle correctement. C'est une habitude très française de croire ça.
Attention cependant, si tu peux te lancer dedans, certains aspects du lambda-calcul permettent de mieux comprendre des notions de paradigmes fonctionnels. Mais c'est loin d'être nécessaire. Ça serait comme dire que tu as besoin de connaître les machines de Turing ou les automates à piles pour programmer en Fortran.
En pratique ce n'est pas exact. Comme il est dit dans l'article An Introduction to Category Theory, Category Theory Monads, and Their Relationship to Functional Programming :Citation:
C'est pour cela 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é.
Il me semble que les monades ont été introduites en programmation pour leurs vertus de généralisation / modélisation, et non pas en relation directe avec l'évaluation paresseuse. D'ailleurs, avant d'utiliser les monades, Haskell utilisait pour l'entrée/sortie une méthode reposant beaucoup plus sur la paresse (et qui était d'ailleurs, de l'aveu de la plupart, complètement imbuvable).Citation:
Monads are typically equated with single-threadedness, and are therefore used as a technique for incorporating imperative features into a purely functional language. Category theory monads have little to do with signle-threadedness; it is the sequencing imposed by composition that ensures single-threadedness. [...] There is nothing new in this connection. Peter Landin in his Algo60 paper used functional composition to model semi-colon. Semi-colon can be thought of as a state transforming operator that threads the state of the machine throughout a program.
Je vois ce que tu veux dire, mais je me demande très honnêtement ce qui est venu en premier dans le cas de Haskell : l'implantation des monades dans le langage ou sa justification ?
C'est des crétins, c'est tout.Citation:
Envoyé par Garulfo
Ca me fait penser à une présentation en cours, avant-hier, par un groupe d'étudiants.
La personne en question a présenté les caps et les floors, deux produits utilisés en finance pour se couvrir. Il a montré tout plein de formules mathématiques, et quand je lui ai posé la question dix minutes après "C'est quoi un cap ? C'est quoi un floor ?", il m'a tout de suite montré les formules qu'il avait écrites au tableau. J'ai tout de même réussi à lui arracher de la bouche "C'est une option avec un actif sans risque.". En fait, ça n'a rien à voir avec ça.
Et ce mec-là va se retrouver dans quatre mois dans une grosse salle de marchés à jouer avec de grosses sommes d'argent tous les jours.
Donc bon, les gens qui font de la théorie sans pratique, moi je pense que ça fait de belles pièces de musées.
Ce serait sympa que tu arrêtes avec tes provocation gratuites, ça éviterait à mes posts de se faire supprimer quand je te réponds... Et tu pourrais éventuellement penser à monsieur Church avant de te prononcer de façon si catégorique...
Et évidement, s'il n'y avait pas de théoricien pur, l'informatique serait bien loin de son point d'avancement actuel.
De plus, je ne pense pas que les théoriciens aient fait réellement avancer l'informatique. Certaines théories ont peut-être, au commencement, fait émerger certaines idées, mais ce n'est certainement pas la théorie qui a boosté l'informatique.
- le transistor : découverte théorique ?)
- la micro-puce : pas réellement une avancée théorique, même si ça fait certainement appel à des notions de physique pointues
- LISP : oui, à la rigueur, la première implantation du lambda-calcul
- FORTRAN : non, clairement
- MULTICS : 1000 fois non
- UNIX : là encore, non, même si c'est sorti de labos de recherche
- C : idem
- l'augmentation incessante de la puissance des processeurs : non, encore
- PROLOG : une belle histoire montrant qu'il faut savoir combiner théorie et pratique
Par contre, il est vrai que du côté de la preuve formelle et du cryptage les choses sont autres, mais je considère qu'ils pèsent à eux seuls bien peu vis-à-vis de ceux cités ci-dessus.
À ma connaissance, les monades telles qu'on les connait aujourd'hui ont fait leur apparition en info à la fin des années 80, dans les travaux de E. Moggi (entre autres http://citeseer.ist.psu.edu/417447.html, et surtout Notions of computations and monads).Citation:
Je vois ce que tu veux dire, mais je me demande très honnêtement ce qui est venu en premier dans le cas de Haskell : l'implantation des monades dans le langage ou sa justification ?
Il emploie les monades au niveau de la sémantique du langage de programmation, mais il y a déjà l'idée de la modularité (l'exemple 1, page 3 du deuxième article le montre bien).
Les articles de Wadler qui reprennent ce travail (et qui l'ont popularisé chez les Haskelliens) mettent l'accent sur les fonctionnalités "impératives" apportées, mais gardent l'idée de la modularité (par exemple il présente aussi les monades de Continuation Passing Style, qui sont tout à fait différentes).
Par ailleurs, pour ce qui est de ton "OCaml doit mourrir", je ne suis pas de ton avis. Je fais le même constat que toi : la communauté Haskell est très vivante, la communauté OCaml peine à se constituer.
Mais ça ne veut pas dire que les deux langages n'ont pas leur place : leurs différences les enrichissent, et OCaml a des possibiltés que Haskell n'a pas (contrairement à ce que disent certain qui voudraient nous faire croire que OCaml n'est qu'un brouillon de Haskell).
En particulier il me paraît dangereux de tout miser sur l'évaluation paresseuse, et tout à fait profitable de pouvoir utiliser deux langages, l'un principalement paresseux et l'autre principalement strict.
Je pense donc maintenant qu'il faut constituer une communauté OCaml, ou plutôt rendre celle qui existe actuellement plus visible. Ce n'est pas facile, mais ce n'est pas impossible non plus, on a déjà les ingrédients en place, et les autres y sont bien arrivés.
C'est essentiellement pour cette raison que j'en parle comme je le fais. Je suis absolument d'accord sur le fait qu'il s'agit d'une façon élégante de faire de la modularité et qu'il s'agit là de leur vraie nature, car, en fait, la seule monade en Haskell exploitant l'aspect séquencement/strictness est la monade IO, les autres étant là pour introduire de la modularité. Tout ça, je le sais, et je suis d'accord avec toi.Citation:
Envoyé par bluestorm
Je voulais seulement dire qu'OCaml était en phase de quasi-végétation. Il lui faudrait un peu de sang neuf et, on est d'accord, une communauté qui ne se limite pas à Ulm - X - MP*, mais qui soit un peu plus ouverte et modeste.Citation:
Envoyé par bluestorm
Dans le fond, je continue cependant de penser qu'OCaml, bien que très différent, est supérieur.
Donc tous les théoriciens qui ont fait les fondements de l'informatique sont des crétins ? Church, Curry, Turing ? Les modèles de calcul ne sont pas théoriques selon toi ? Tu penses vraiment que le transistor a apparu sans qu'il n'y ait de théorie avant ? Est-ce qu'on aurait remplacé IOCWT par un gamin qui ne connait pas ce qu'est la science ?
Tu déformes mes propos.
Je n'ai jamais dit que la théorie ne servait à rien.
J'ai, par contre, affirmé que la théorie sans pratique, elle, ne servait à rien. C'est pas la même chose.
connaissant IOWT IRL, je pense savoir ce qu'il souhaitait dire, à savoir :
- la théorie sans pratique n'est pas applicable à l'informatique ;
- trop de personnes font des maths ou de la logique et non de l'informatique, ont un niveau quasi-nul en programmation (quelque soit le langage), et prétendent être chercheurs en informatique ;
- en informatique, beaucoup d'avancées techniques ont été faites par ce que certains appeleraient de manière condescendante des bricoleurs ; mais cela souligne qu'une bonne intuition d'un problème et de l'huile de coude peut faire avancer bien plus qu'une centaine de papiers qui tournent autour d'un même problème sans réellement chercher à faire autre chose que d'en parler :roll:
Oui, c'est ça, mais je pensais aussi au domaine des mathématiques appliquées.
Je suis relativement en accord avec les autres points (en soulignant quand même que dans AUCUN domaine la théorie sans la pratique ne sert à quoi que ce soit y compris en math).
Par contre là... j'aimerais voir des réels exemples de ce qui a fait avancer vraiment l'informatique et qui vient d'un gars uniquement armé d'une bonne intuition sans aucun support théorique quelconque ? Des exemples ?
Je ne sais pas ce que tu appelles "théorie" et "pratique" en maths. Ça dépend sûrement du domaine (parce que "maths" est assez large) mais, en utilisant le sens courant de ces mots (pratique = concret, matériel, tangible; théorique = abstrait, virtuel, éloigné du monde réel), je ne suis pas d'accord, principalement parce qu'alors en maths, la plupart des choses sont théoriques (en tout cas du point de vue des matheux), et restent tout aussi amusantes et intéressantes.Citation:
en soulignant quand même que dans AUCUN domaine la théorie sans la pratique ne sert à quoi que ce soit y compris en math.
Si on répond (avec une once d'ironie) "C++", tu dis quoi ? Ou surtout "le C" ?Citation:
Par contre là... j'aimerais voir des réels exemples de ce qui a fait avancer vraiment l'informatique et qui vient d'un gars uniquement armé d'une bonne intuition sans aucun support théorique quelconque ? Des exemples ?
Tu pourrais répondre "oui mais ces langages ne sont pas innovants, ils n'ont pas apporté de concepts nouveaux" ou quelque chose du genre. Attention à ne pas avoir un point de vue biaisé : si tu évalues les "avancées" de l'informatique d'un point de vue de Computer Scientist, alors forcément seules les avancées "théoriques" vont avoir de la valeur à tes yeux. Je pense que ce serait un problème de non-relativisme. Si tu veux des avancées de l'informatique faites par des praticiens, alors il faut savoir évaluer ce qu'est une "avancéee" d'un point de vue pratique aussi.
Dans cette optique, pense que le C, qui a permis la construction de multiples couches logicielles, est un bon exemple d'"avancée" "pratique". Ceci dit, le statut "uniquement pratique" de C et de Unix est à la rigueur contestable, puisqu'ils ont tout de même été créés dans un environnement "de recherche" (les laboratoires Bells), mais je pense (je ne suis pas un connaisseur par contre) qu'ils sont tout de même suffisamment "pratiques" (et surtout suffisamment peu "théorique", en regard de ce qu'on savait faire en théorie des langages de programmation à l'époque) pour remplir les critères. Sinon, on peut toujours choisir un autre grand projet, comme C++ (?!), ou Linux.
Le C, c'était une avancée pour l'époque pour son côté complet, simple et démocratique : d'autres langages autrement plus sophistiqués, mais lents, existaient déjà à l'époque : Algol W, PROLOG, etc... N'oublions pas que la philosophie d'UNIX et du C était "Small is Beautiful".
Il y a Linux, mais pas seulement.
PROLOG est un bon exemple : un langage avec des fondements théoriques, la plupart d'entre eux étant apparus aux créateurs sous forme d'intuition, mais aussi avec de très gros compromis d'ordre pratique, comme la coupure. Si le projet en était resté au stade de théorie, c'est-à-dire sous sa forme PROLOG pur, il est possible que le langage n'ait jamais connu le succès que l'on sait. Tout ça est résumé dans un article des fondateurs, entre autres Colmerauer, si je crois bien.
Là où j'ai travaillé à l'INRIA cet été, dans le projet GAMMA spécialisé dans la génération automatique de maillages anisotropes, on mettait un bonne dose d'huile de coude pour rendre les algorithmes numériquement résistants, et c'est, à la fin, ce qui fait la différence entre un produit de mathématiques appliquées ordinaire et un bon logiciel de calcul.
Non la pratique c'est « Toute activité en général. Activité mettant en œuvre les principes d'un art ou d'une science. » (Dictionnaire Hachette)
Pratique ne veut pas dire matériel ou tangible.
Il y a un aspect théorique à la mécanique, ce qui est très abstrait.
Mettre en oeuvre en math, c'est appliquer les théorèmes, démontrer des théorèmes, faire des exercices quoi. On n'apprend pas en regardant un prof.
Un ancien proverbe chinois dû à Confucius dit
« Regardes et tu oublies, écoutes et tu te souviens, fais-le et tu l'acquiert »
Le « fais-le » c'est la pratique : la praxis des grecques.
Les choses en math sont abstraites, pas uniquement théorique.
Bien sûr on peut prendre les mots dans le sens que tu as donné. Dans ce cas je serais d'accord avec toi. Mais c'est un sens erroné d'après moi.
Je pense que tu te réponds tout seul. Le C n'a pas été construit sans base théorique. Déjà parce qu'il s'inspirait d'autres langages qui eux même avaient eu des bases théoriques. Je n'ai pas dit que la pratique est complètement inutile ou absente. En fait, j'amenais juste le point que nul avancée scientifique n'est d'ordre uniquement pratique ou uniquement théorique.
Par mes convictions religieuses je crois trop à la pratique pour la dénigrer. Ce n'était donc certainement pas mon objectif.
Pour Linux, c'est la même chose. Linus Torvald est parti en s'inspirant des connaissances acquises sur les OS (et qui forment donc une ou des théories).
Il y a toujours un mélange des deux. Je pense qu'on pourrait probablement dire que les meilleures réussites ont été celles qui ont su le mieux exploiter les théories par une mise en pratique. N'est ce pas finalement une simple évidence ?