Reprise du message précédent :

Pour les ceusses qui comme moi ont un peu de mal avec Haskell et sont habitués aux debuggers, GHC 6.8.1 est fourni avec un debugger (je ne l'ai pas encore testé).
Pour un exemple d'utilisation, cf ce blog

Okay !

test

pas de posts pendant 10 minutes pliz

stfu

suce ma bite

test

celui qui poste après ce poste est gay

pas gentiel

mais

choupie est gay

test :  celui qui postes après ce post à une mère qui est aussi sa soeur

stifflerg

cahors

Au moins ça fait une personne de moins à inviter au fête de famille

J'ai la modération en MP

Et j'ai pas de soeur, étron liquide

C'est le fait du prince, ça

lol, stiffler

bon, comme j'ai l'impression de pas apprendre grand chose en ce moment, j'aimerais bien me mettre a un langage fonctionnel, par curiosité.
 
J'aimerais quand même que ce soit assez complet pour faire de vrais trucs avec (réseau, http, xml, eventuellement interface graphique). Plutot haskell, ocaml, ou un autre ?

Scheme

disons qu'avec un résumé des points interessant + eventuellement un exemple de programme ecrit avec, ca serait mieux qu'une réponse en un mot

Haskell c'est pas mal, mais le fait qu'il soit "pur" avec des monades complexifie l'approche et surtout le modèle à comprendre.

Par contre, le compilo (même s'il reste très lent) s'améliore rapidement, et il y a énormément (et de plus en plus) de libs de qualité.

Erlang a de gros avantages pour tout ce qui est distribué ou qui impliqué des connections réseaux. Le langage est moins "beau" (aussi bien en théorie qu'en syntaxe) que Haskell, il ne considère pas non plus comme très importante la notion de pureté, et n'est globalement fonctionnel que parce que c'était le paradigme plus simple, le plus pratique et le plus logique  pour Sequential Erlang.

Par contre il fait très mal pour tout ce qui est exécution en parallèle: retourner à d'autres langages par la suite est difficile et donne vraiment l'impression de retourner des siècles en arrière (e.g. même avec java.util.concurrent, Java (1.5 en tout cas) n'arrive pas au début de la base de la cheville d'Erlang). C'est également un langage très stable et "battle tested" en prod un peu partout.

OCaml, je ne connais pas vraiment le langage, tout ce que j'en sais est qu'il est globalement orienté "pratique" (plutôt que théorique) et a un très bon compilo/runtime.

Scheme est intéressant pour faire de la découverte, mais le nombre d'implémentations et leurs capacités différentes (chacun a sa stdlib, ses packages, le coeur du langage est standard mais le reste ne l'est pas, sauf un début dans R6RS) font qu'il devient difficile de choisir son runtime, de changer de runtime si on en a besoin, ou de trouver des libs (un certain nombre de libs ne tournent que sur certaines implés). Il y a d'ailleurs le même problème avec Common Lisp.

J'ai également entendu parler de Clean, qui semble assez proche de Haskell (en terme de syntaxe) mais avec un runtime et un compilo plus efficaces, et une approche différente de la pureté (et de la manière dont les calculs sont effectués, mais c'est moins important pour l'utilisateur)

PS: Erlang et Scheme sont typés dynamiquement, Common Lisp est typé dynamiquement avec typehints optionels pour le compilo, Haskell, OCaml et Clean sont typés statiquement avec inférence et basés sur Hindley–Milner

merci pour l'info. La complexité ne me dérange pas trop, je ne recherche pas forcément la facilité (ni la complexité pour le plaisir de faire compliqué, d'ailleurs).

Je vire tout ce qui est scheme & lisp pour les raisons que tu cite, je vire erlang sans raison, et je reste au meme point qu'avant

Je crois que ca va etre haskell pour deux raisons très connes :
* manipuler des listes infinies, ca me fait délirer
* les +. d'ocaml... même si en pratique je n'utilise quasiment jamais de floats.

Haskell, c'est vraiment terrible pour découvrir. Je passe par des moments de grandes frustrations parfois... mais ça précéde un grand moment d'illumination toujours

Pour débuter, je te conseille Yet Another Haskell Tutorial. Il n'est pas encore fini me semble-t-il, mais c'est une excellente intro pour un programmeur habitué aux langages conventionnels, et tu verras vite s'il te plaît ou pas, sans dépenser un kopek, juste quelques heures

Edit: j'ai pas précisé... mais c'est le seul LF que j'ai pris le temps de vraiment découvrir. Donc ne prends pas forcément ça comme une confirmation sur quel langage choisir.

Write Yourself a Scheme in 48 Hours aussi.

Il est dans ma catégorie de bookmarks "tutos-à-faire-quand-j'aurais-le-temps"

Bouof, je trouvais ça un peu relou au début aussi, mais au final, t'as quand même le compilo OCaml qui te fait tout l'inférence des types de ton code, et que du coup, tu peux être sympa et lui filer un coup de main de temps en temps sur les opérations sur les flottants

Sauf qu'en haskell il n'y a pas besoin d'un truc aussi sale

Je dis pas le contraire, je connais pas vraiment Haskell.
Comment ça se passe alors ?

Il y a un système de typeclasses pour les types abstraits, les entiers comme les flottants (et d'autres) font tous partie de la typeclasse Num, et les différents opérateurs arithmétiques sont définis pour tous les Num.
 
Donc l'addition de deux flottants se fait avec (+), celle de deux Int avec (+), etc...
 
Par contre, on ne peut pas ajouter un Float et un Int, il faut impérativement convertir

ouais, sauf que la constante 5 par exemple, est de type Num.

donc taper
x = 5+3.3

est valable (le resultat est 8.3, et x est de type Double)

Ben oui, le TI arrive à inférer que 5 doit être considéré comme de type Double et tout roule
 
Mais c'est pas nécessairement le cas
Genre

ben ça pète, parce que x est inféré au type concret "Integer" (dans le REPL, dans un programme complet le compilo devrait pouvoir inférer autre chose)

j'ai bien compris (et je me doutais que tu répondrais), c'était juste pour préciser la phrase "on ne peut pas ajouter un Float et un Int, il faut impérativement convertir".
 
Parce qu'apparement, en ocaml, 5+3.3, c'est pas possible, et 5 +. 3.3 non plus.

+1

Je me sens tout n00b :
 

 
Sauf que d'apres la doc, UTCTime est un FormatTime...
http://www.haskell.org/ghc/docs/la [...] FormatTime
 
j'ai loupé quoi ?

http://haskell.org/hoogle/?q=getCurrentTime
 
getCurrentTime a des effets de bord, et il n'y a pas de type () -> a dans Haskell: une fonction avec des effets de bord vit dans une monade, et ici getCurrentTime vit dans IO (d'où getCurrentTime :: IO UTCTime)
 
Donc il faut soit bricoler tes trucs dans IO, soit (plus simple) sortir ta valeur de IO.
 

main = do
    t <- getCurrentTime
    let time = formatTime defaultTimeLocale "%D %T" t

Si tu veux jouer dans IO, il faut utiliser les liftM* (ou, ici, `ap` qui suffit largement, voir hoogle pour les signatures)

> let s = return (formatTime defaultTimeLocale "%D %T" ) `ap` getCurrentTime
> s
"03/31/08 13:21:18"