Discussion :

[gasche]

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
module Main where
 
main = putStrLn "Hello world"

C'est difficile ça ?

Et maintenant, ma fonction retourne une liste de strings, et je veux toutes les afficher. Je fais comment, il est où le "iter putStrLn" ?
Paf.

Dans l'ensemble, je trouve les règles du Haskell plus complexes que celles du Caml. Il suffit de regarder par exemple les règles du filtrage de motif, il y a tout un tas de subtilités (la gestion de la paresse, de la divergence, etc...), de questions qui ne se posent pas en OCaml.

Bof...

Les règles de correspondance de motifs peuvent avoir de subtils effets sur la signification d’une fonction. Par exemple, considérons cette définition de take :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

et cette version légèrement différente (les deux premières équations ont été interverties) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
take1  _     []         =  []
take1  0     _          =  []
take1  n    (x:xs)      =  x : take1 (n-1) xs

Maintenant notez ce qui suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
take  0   bot  => []
take1 0   bot  => ⊥
take  bot []   => ⊥
take1 bot []   => []

nous voyons que take est « plus définie » concernant son deuxième argument, alors que take1 est plus définie concernant sont premier argument. Il est difficile de dire, dans ce cas, quelle définition est la meilleure. Rappelez-vous simplement que dans certaines applications, cela peut faire une différence. (Le Prélude Standard inclut une définition correspondante à take).

[gorgonite]

Et maintenant, ma fonction retourne une liste de strings, et je veux toutes les afficher. Je fais comment, il est où le "iter putStrLn" ?
Paf.

pas convaincant ton exemple... avec une petite monade tu peux t'amuser à appliquer la dite fonction a tous les éléments d'une liste

[Jedai]

Et maintenant, ma fonction retourne une liste de strings, et je veux toutes les afficher. Je fais comment, il est où le "iter putStrLn" ?
Paf.

Paf ? Peut-être devrais-tu retirer tes oeuillères :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
module Main where
import Control.Monad

listOfStr = [ "Hello world !", "Goodbye" ]

main = mapM_ putStrLn listOfStr

(mapM_ peut paraître ésotérique comme nom, mais c'est juste un map sur Monade, où on jette le résultat des applications (le _ est une convention pour dire ça) )

Quant à ton second exemple, il est où le problème ? Effectivement il y a une subtilité, c'est le prix à payer pour exploiter le pouvoir de l'évaluation paresseuse, mais dans un langage strict, ça n'aurait effectivement aucune importance dans quel ordre tu mets tes deux premiers motifs : ça divergerait dans les deux cas montrés en dessous !! Au moins dans Haskell tu pourras utiliser des listes infinies (avec take ou take1 d'ailleurs)... En bref la complexité rajouté est invisible si tu ne fais pas usage du pouvoir en plus d'Haskell, et ne pose pas problème habituellement (pour la plupart des usages les deux versions sont équivalentes, même avec des listes infinies).

J'ai l'impression que tu tapes sur Haskell sans l'avoir exploré plus que ça...

--
Jedaï

[gasche]

"Paf" dans le sens où tu ne pourras plus faire croire que l'entrée-sortie c'est tout con, il suffit d'utiliser putStrLn dans main et puis voilà.

C'est pour montrer que l'argument "on peut très bien montrer sans expliquer/ faire comprendre au début" n'est pas très convaincant, à mon avis. Tu voudrais balancer MapM_ au débutant en lui disant "mais t'inquiètes pas, tu comprendras plus tard" ? À mon avis, ce n'est pas jouable.
Autant pour PutStrLn, le débutant peut gober, autant dès qu'il essaiera d'expérimenter un peu autour par soi-même (par exemple en voulant afficher une liste de chaines de caractère), il se prendra forcément les monades dans la gueule.

Quant à ton second exemple, il est où le problème ? Effectivement il y a une subtilité, c'est le prix à payer pour exploiter le pouvoir de l'évaluation paresseuse

Ce que j'ai dit, c'est que les règles sont plus complexes. Effectivement, la complexité vient avec des avantages intéressants, mais ça reste plus complexe, il y a un "prix à payer" comme tu dis.

Dans l'ensemble, cela étaie donc mon propos initial, qui est qu'à mon avis il est plus long et difficile d'avoir un bon [aperçu/socle de base/point de vue d'ensemble] du Haskell que du Caml (sous-entendu, quand on vient d'un langage impératif, je ne traite pas le cas du débutant complet, parce que je n'y connais pas grand chose).

[Garulfo]

"Paf" dans le sens où tu ne pourras plus faire croire que l'entrée-sortie c'est tout con, il suffit d'utiliser putStrLn dans main et puis voilà.
[...]

Je ne connais pas bien Haskell. Je n'en suis pas un défenseur ou un détracteur, mais ton exemple ne me convainc pas du tout. Ça me paraît très simple à faire. Faire un map sur une liste d'élément pour tous les afficher est le moyen le plus naturel en programmation fonctionnelle. Par contre, utiliser un moyen itératif n'est pas naturel et montre une méconnaissance des techniques fonctionnelles. Enseigner à un étudiant à afficher tout le contenu d'un tableau de chaînes de caractères n'est pas du tout simple non plus. Pour qqun qui ne connait rien à l'informatique apprendre à utiliser un application map est aussi simple/complexe qu'apprendre à utiliser une boucle itérative while ou for.

Mais je suis d'accord par contre que le filtrage peut être une réel épine dans le pied. C'est effectivement gênant de devoir réfléchir à la méthode d'évaluation pour qqch d'aussi simple.

[Jedai]

Mais je suis d'accord par contre que le filtrage peut être une réel épine dans le pied. C'est effectivement gênant de devoir réfléchir à la méthode d'évaluation pour qqch d'aussi simple.

Oh, mais tu n'y réfléchis pas, ou plutôt le débutant n'y réfléchit pas, ça viendra avec l'expérience, et les deux implémentations marchent aussi bien l'une que l'autre dans la très très grande majorité des cas.

--
Jedaï

[Garulfo]

Oh, mais tu n'y réfléchis pas, ou plutôt le débutant n'y réfléchit pas, ça viendra avec l'expérience, et les deux implémentations marchent aussi bien l'une que l'autre dans la très très grande majorité des cas.

--
Jedaï

Ce qui fait que le débutant pourrait avoir de mauvaise surprise.
Personnellement je pense que l'évaluation paresseuse est une bonne chose. Donc je ne critique pas trop -_-

[Jedai]

Ce qui fait que le débutant pourrait avoir de mauvaise surprise.

Je ne pense pas qu'il ait vraiment trop de mauvaises surprises, entendons-nous bien : L'une comme l'autre de ces versions marchent parfaitement avec des listes infinies en arguments, c'est uniquement dans les cas où l'un ou l'autre des argument diverge immédiatement que la question se pose. Je ne pense pas qu'un débutant en Haskell soit choqué si un programme dans lequel il y a une boucle infinie ne fonctionne pas, il sera plutôt surpris quand l'un d'entre eux marchera.

--
Jedaï

[Garulfo]

[...]Je ne pense pas qu'un débutant en Haskell soit choqué si un programme dans lequel il y a une boucle infinie ne fonctionne pas, il sera plutôt surpris quand l'un d'entre eux marchera.

--
Jedaï

C'est amusant. Car vu ce commentaire tu sous-entends que ton étudiant connaît l'informatique et la programmation ^_^
Je t'assure que beaucoup d'étudiants en math se laisse avoir et crois qu'une boucle infinie peut fonctionner. Quand je parle à des étudiants de math qui n'ont jamais programmé de faire des suites infinies (en scheme) cela leur semble d'une évidence incroyable. Menfinbon c'est un autre débat.

[Jedai]

Je t'assure que beaucoup d'étudiants en math se laisse avoir et crois qu'une boucle infinie peut fonctionner.

Je ne suis pas d'accord, lorsque je parle de boucle infinie ici, il s'agit bien d'un programme qui ne peut jamais finir, je ne parles pas de listes infinies. Effectivement programmer avec des structures de données infinies ne pose pas vraiment de problème à des matheux, mais ils sont plutôt d'accord avec toi lorsque tu leur expliques que le programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

until (< 3) (+ 1) 4

ne peut pas te donner de résultat... qu'il diverge.

--
Jedaï

[Garulfo]

Je ne suis pas d'accord, lorsque je parle de boucle infinie ici, il s'agit bien d'un programme qui ne peut jamais finir, je ne parles pas de listes infinies. Effectivement programmer avec des structures de données infinies ne pose pas vraiment de problème à des matheux, mais ils sont plutôt d'accord avec toi lorsque tu leur expliques que le programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

until (< 3) (+ 1) 4

ne peut pas te donner de résultat... qu'il diverge.

--
Jedaï

Tu n'es peut être pas d'accord mais pourtant c'est bien ce qu'il y a dans leur tête.
Bien sûr quand tu leur expliques ils s'en rendent compte. Mais je t'assure que pour beaucoup de matheux faire une boucle qui ne finit pas n'a rien de stressant en soi la première fois. Ceci est général pour beaucoup de débutant, mais je posais une anedocte par rapport à ton commentaire. Le commentaire que tu as fait sur la boucle infinie est donc faux d'après mon expérience : de nombreux étudiants sont « choqués » qu'une boucle infinie ne fonctionne pas. La notion d'algorithme n'est pas innée. Tu es dans un contexte où les étudiants sont de très bons étudiants. Ce n'est pas le cas de la majorité des étudiants qui rentre en info, et qui font de l'info. L'exemple que tu donnes est numérique. C'est autre chose quand c'est des prédicats plus « abstraits », comme un filtrage récursif sur une liste.

[Jedai]

Oui, tu as peut-être bien raison, il est vrai que je n'ai pas eu énormément de contact avec des étudiants "moyens" en informatique.
Quel est leur attente habituellement ? Ils pensent que ma fonction va renvoyer +\infty ?

--
Jedaï

[Garulfo]

Oui, tu as peut-être bien raison, il est vrai que je n'ai pas eu énormément de contact avec des étudiants "moyens" en informatique.
Quel est leur attente habituellement ? Ils pensent que ma fonction va renvoyer +\infty ?

--
Jedaï

Effectivement. Il y en a qui (avec un an d'informatique) ne savent toujours pas qu'un algorithme doit être fini. Menfinbon, une collègue en école d'ingénieur en France me disait qu'ils ont constaté que des étudiants ingénieurs réussissaient à avoir leurs diplômes sans avoir jamais codé une seule fois. En tout cas, on sort du cadre du sujet ...

Dans le sujet, je reconnais les vertus de l'évaluation paresseuse. C'est un concept que j'apprécie énormément car, comme je l'avais mentionné sur un autre fil, il permet dans certains cas d'allier plus facilement la partie analyse et la partie conception. Bien sûr ça a d'autre avantage.

Les types me laissent plus perplexes par contre. Si d'un côté, il y a un apport « sécurité » bien réel, d'un autre, enseigner sans type c'est imposer de bien réfléchir avant coup à sa conception. Sinon, on risque de ne jamais réussir à débugger son programme. Par la suite, le sans type offre une souplesse d'emploi bien agréable.

C'est pourquoi dans les langages, je ne suis pas convaincu que ocaml ou haskell ait un réel avantage sur scheme. Les bibliothèques et le support est très présent en Scheme et les compilateurs sont extrêmement efficaces maintenant. Il est aisé de faire de l'évaluation paresseuse, bien que, comme pour ocaml, elle doit être explicite. Le plus de Scheme, à mes yeux, c'est la puissance de son langage de macro qui permet de tout refaire. En fait, il est possible de tout refaire (curryfication automatique, évaluation paresseuse par défaut etc.) à l'aide du langage de macro très simple et puissant.

Haskell a-t'il un bon langage de macro ?

[gorgonite]

Effectivement. Il y en a qui (avec un an d'informatique) ne savent toujours pas qu'un algorithme doit être fini. Menfinbon, une collègue en école d'ingénieur en France me disait qu'ils ont constaté que des étudiants ingénieurs réussissaient à avoir leurs diplômes sans avoir jamais codé une seule fois. En tout cas, on sort du cadre du sujet ...

etant étudiant en école d'ingénieurs en France, je peux confirmer cela... il y a d'ailleurs plusieurs techniques :
+ se mettre en binome avec quelqu'un de bon, et se taper tout le sale boulot
+ pour les projets en groupe plus importants, passer son temps à communiquer entre ceux qui bossent vraiment pour maintenir l'illusion, tout en ne faisant rien d'utile
+ s'il n'y a que des gens comme soi, s'arranger pour que personne ne rende rien, et aller se plaindre au prof pour que l'épreuve soit changée


j'ai personnellement été écouré par mon cursus en école, car selon moi, près de 80% de la "promo informatique" utilisait ces techniques ; au final ils auront le même diplôme que moi, et étant surtout des "tchacheurs" ils auront plus facilement au poste intéressant que moi


mais ce n'est qu'un petit aparté...

[Garulfo]

etant étudiant en école d'ingénieurs en France, je peux confirmer cela... [...]

Ils ont instauré un examen final de programmation. Si tu n'as jamais codé, tu ne le réussira jamais.

[gorgonite]

Ils ont instauré un examen final de programmation. Si tu n'as jamais codé, tu ne le réussira jamais.

ou cela ? y a pas de cela dans mon école (et je suis en 3ème année)

[HanLee]

etant étudiant en école d'ingénieurs en France, je peux confirmer cela... il y a d'ailleurs plusieurs techniques :
+ se mettre en binome avec quelqu'un de bon, et se taper tout le sale boulot
+ pour les projets en groupe plus importants, passer son temps à communiquer entre ceux qui bossent vraiment pour maintenir l'illusion, tout en ne faisant rien d'utile
+ s'il n'y a que des gens comme soi, s'arranger pour que personne ne rende rien, et aller se plaindre au prof pour que l'épreuve soit changée


j'ai personnellement été écouré par mon cursus en école, car selon moi, près de 80% de la "promo informatique" utilisait ces techniques ; au final ils auront le même diplôme que moi, et étant surtout des "tchacheurs" ils auront plus facilement au poste intéressant que moi


mais ce n'est qu'un petit aparté...

C'est l'art du pipotage, qui est aussi très cher à de nombreux Centraliens

[InOCamlWeTrust]

Je ne pense vraiment pas que l'évaluation paresseuse soit un plus pour apprendre l'informatique : ce n'est tout simplement pas naturel. L'homme raisonne naturellement de façon stricte, avec effets de bords, du moment que l'on convient que la machine possède une mémoire dont on peut en modifier l'état, et il est ainsi naturel d'écrire des boucles, des affectations et autres.

Pour ce qui est de ça...

Tu es dans un contexte où les étudiants sont de très bons étudiants. Ce n'est pas le cas de la majorité des étudiants qui rentre en info, et qui font de l'info.

Tout le monde le sait bien : écrire des programmes, c'est facile, c'est le sale boulot, ça n'a aucun intérêt intellectuel, et donc les étudiants en info sont naturellement mauvais !

Ils ont instauré un examen final de programmation. Si tu n'as jamais codé, tu ne le réussira jamais.

Qui ça ils ? Je ne vois vraiment pas d'où tu peux tenir celà ! De plus, chaque école d'ingénieurs est indépendante, donc chacun fait ce qu'il veut chez soi !

Pour ce qui est des mecs qui ont un diplôme sans n'avoir jamais codé, je dirais même plus que l'on trouve des gens qui auront après trois ans un bout de papier où il y aura écrit "Diplôme d'ingénieur" et qui n'auront même jamais touché à une ligne de commande, ou encore des personnes ne faisant pas la différence entre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
{
    char *string;

    /* ... */
}

et :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
{
    char string[N];

    /* ... */
}

Le niveau baisse malheureusement de façon dramatique. Chez nous, où l'on trouve deux majeures, Maths et Info, on peut se rendre très clairement compte des méfaits de la programmation tout Java et du tout MATLAB. Les étudiants sont pour la plupart désorientés lorsqu'ils n'ont plus soit Eclipse soit MATLAB. Utiliser un vrai compilateur est devenu un exercice périlleux pour certains, et je ne parle même pas des Makefile, dont certains, les meilleurs, doivent peut-être se souvenir du seul principe...

Les écoles d'informatique et de mathématiques appliquées sont en train de devenir des Java Schools et des MATLAB Academies, et il y a fort à parier que l'on en subira les conséquences dans quelques années, voire même que l'on fera marche arrière et que l'on reviendra à des méthodes plus traditionnelles (C, FORTRAN, le Makefile et la ligne de commande), tout simplement car c'est ce qui se fait dans la vraie vie ! Le nombre d'applications nécessitant le C ou le FORTRAN est toujours aussi important, et il faut bien maintenir, voire ré-écrire ces programmes qui font marcher nos ordinateurs (les OS et autres outils), compilent et exécutent nos programmes (la JVM, faite en C ++, rien que ça), ou encore font du calcul scientifique haute performance (et ça, je suis bien placé en ce moment pour le confirmer !).

[Jedai]

Haskell a-t'il un bon langage de macro ?

Ce sujet a complètement dérivé... Néanmoins pour en revenir à la question, Haskell a un langage de macro, est-il "bon" ? Il est en tout cas assez puissant (puisqu'il s'agit d'Haskell...). Il s'agit de Template Haskell (qui aurait peut-être été mieux nommé Meta Haskell).

--
Jedaï