Discussion :

[michon]

moi ce serait un reproche tout bête : l'indentation.
Combien de fois je me suis fais avoir par des erreurs venant du fait qu'il y avait un "tab" en début de ligne au lieu de 3 ou 4 espaces...

Après je pense qu'un IDE le rendrait plus populaire... A moins qu'il en éxiste déja un et que je ne l'ai jamais trouvé ?

Sinon le langage est bien pratique, j'ai fais un projet de manipulation algébrique de graphe avec...

[viro]

moi ce serait un reproche tout bête : l'indentation.
Combien de fois je me suis fais avoir par des erreurs venant du fait qu'il y avait un "tab" en début de ligne au lieu de 3 ou 4 espaces...

Pourtant le système dans lequel l'indentation a de l'importance est optionnel (même si en pratique c'est le plus employé); on peut écrire en effet

Code :

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

1
2
3
4
main = do { action1; action2
 ; action3;
       action4
     ; }

(exemple volontairement massacré)

là ou on écrit en général

Code :

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

1
2
3
4
5
main = do
             action1
             action2
             action3
             action4

[viro]

Parce que la première ligne est une égalité (f, appliqué à x, égale 3 x), alors que dans la deuxième il n'y a rien d'égal : "\x = 3*x" suggèrerait au mieux que x = 3*x, donc une forme de récursion. Il s'agit ici d'une fonction : à x on associe 3x. Le "->" est d'ailleurs bien le même "->" que dans un motif ("case .. of") par exemple : si on reconnaît le motif "x", on renvoie "3*x".

Ton explication n'est pas très claire, en cela que je ne vois pas en quoi
\x = 3*x suggère que x = 3*x. On peut également avoir la suggestion que \x = 3*x "lambda x égale 3 fois x", ce qui suggère fonction anonyme qui à un paramètre x associe le résultat 3*x.

Ton explication sur la cohérence avec les motifs case ... of me plait mieux.

[NokyDaOne]

- rentre GHCi agréable à utiliser pour coder de petits exemples (quand on est habitué au toplevel OCaml, il y a un monde)

Ouais on peut pas coder avec vu qu'on n'est dans un autre mode de fonctionnement que dans un fichier source, très mauvais pour le débutant.

- si on pouvait reconcevoir haskell aujourd'hui, j'essaierais d'enlever la paresse par défaut (par exemple, en ajoutant des spécifications d'appel sur les types des fonctions, où on choisit entre un traitement lazy ou strict de chaque paramètre, le défaut étant le strict)

Hérésie .

- essayer de concevoir un meilleur support pour les ambiguités de type classes : je veux pouvoir donner plusieurs structures de monoïde à l'ensemble des entiers naturels, sans devoir changer de type; cela passe sans doute par une réification de certains dictionnaires

Ça c'est un vrai problème (mais je n'ose regarder ce que font les autres).

- ajouter un mot-clé "rec" ou un équivalent pour préciser les valeurs récursives; dans le cas par défaut, les noms déclarés ne seraient pas dans la portée de leur déclaration

Totally useless. En ocaml il me soule. Et sa seule et unique utilité serait si j'ai deux fonctions avec le même nom. Donc non c'est un truc de dégueulasse.

- arrêter de traiter la monade IO comme un gros blurb où on peut tout mettre (entrée-sortie, concurrence..)

Tout ce qui fait un effet de bord doit être la dedans. On n'y peut rien. Après pas mal de développeuirs ne comprennent pas que IO n'est pas une poubelle.

[NokyDaOne]

Il y a un point qu'on peut reprocher à Haskell : il ne fait pas de POO. Il y a de rares cas (contrôles d'une interface graphique) où c'est extrêmement utile.

[viro]

Il y a un point qu'on peut reprocher à Haskell : il ne fait pas de POO. Il y a de rares cas (contrôles d'une interface graphique) où c'est extrêmement utile.

En même temps gtk2hs s'en sort pas mal, non ?

[NokyDaOne]

Ouais le jour où ça buildera sur les trois OS sans pb. Aujourd'hui je n'ai pas encore réussi à builder ce genre de choses.

[james-mi]

Un truc tout bête : la fonction split n'existe pas dans Data.List !!!

Evidemment, Google is my friend trouve plein de solutions, mais si c'était codé dans le module ce serait quand même mieux.

A noter sa présence dans Data.Text

[james-mi]

Eh puis un truc tout de même inconcevable.

Haskell défini des monoïdes, ce qui plait vraiment bien au mathématicien qui sommeille (parfois) en nous.

Pour mémoire, en maths, un monoïde est une structure algébrique consistant en un ensemble muni d'une loi de composition interne associative et d'un élément neutre.

Bien, et là, comment s'appelle en Haskell l'élément neutre et la loi de composition interne ?
respectivement mempty et mappend !!!
quand même, quel dommage ...

[limestrael]

Il y a un point qu'on peut reprocher à Haskell : il ne fait pas de POO. Il y a de rares cas (contrôles d'une interface graphique) où c'est extrêmement utile.

Mmmh... Pas sûr. Je viens de passer 5 mois à coder en Python en paradigme fonctionnel, et je peux t'assurer que les concepts objets se mélangent très mal avec les principes fonctionnels. Types immutables et héritage, par exemple, sont une combinaison assez bancale, notamment en ce qui concerne les classes abstraites.
En fait, au final, je n'utilise quasiment que des types immutables (et rien ne m'assure que je suis à l'abri d'une erreur, puisque les listes par ex en Python n'ont pas de version immutable) et très peu d'héritage.

Scala mélange excellemment objet et fonctionnel, car il encourage l'utilisation de structures de données immutables (les types de base existent en 2 versions: mutable et immutable) et dispose de primitives en ce sens (case classes et pattern matching notamment) qui s'inspirent d'ailleurs grandement de ce qu'on trouve en ML/Haskell. Le fait qu'une variable puisse être déclarée soit mutable ('var') soit immutable ('val') apporte beaucoup.

Remarque, il exite O'Haskell (je ne l'ai jamais testé) qui ajoute une couche objet sur Haskell.

Pour réaliser des GUI, je te suggère de jeter un coup d'oeil du côté de la FRP (programmation fonctionnelle réactive, avec des librairies comme elerea, reactive ou yampa).
Alors, c'est pas simple (yampa utilise les arrows en plus, et est bien compliqué de base), mais les principes utilisés sont assez puissants et élégants.

[Alp]

Les types algébriques et les records comme on a en Haskell sont une approche alternative à la POO pour modéliser des données. De la même façon, plutôt qu'une classe implémente une interface / dérive d'une classe abstraite, hé bien ton type de données va être instance d'une typeclass.

Les deux approches sont différentes, mais il n'y en a pas vraiment une qui est plus puissante que l'autre. Chacune a des avantages.

(plus le temps passe, plus j'en trouve à l'approche Haskell, malgré mes 6 ans de C++...)