Discussion :

[SpiceGuid]

L'ésotérisme en Smalltalk:

• soit tu envoies un message sans argument objet fais-moi-ça
• soit tu envoies un message avec arguments objet qui: moi vouloir: ça

Plus une bonne couche de méta-classes dont on dérive les méta-modèles, les méta-vues et les méta-controleurs.

L'ésotérisme en programmation fonctionnelle: le système de typage du langage Qi est plus puissant (la preuve: il est indécidable).

L'ésotérisme en C c'est encore le meilleur, il y a les fameux concours obfuscated.

Bref, à chacun son ésotérisme.

[Jedai]

Visuellement, le plus étrange pour moi sont les gardes (enfin les tests de booléens bizarres de déclaration de fonction). Évidemment, ce n'est pas un point majeur (mais on parle de syntaxe, alors rien n'est vraiment "majeur").

Les gardes existent en OCaml aussi :

Code ocaml :

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

1
2
3
let rec fact = function
  | n when n < 2 -> 1
  | n -> n * fact (n-1)

Le plus gênant pour écrire est que je ne comprend en gros rien aux règles de layout. Quand on lit du code, c'est évident, mais quand j'écris je me retrouve toujours à appuyer sur "tab" comme un con en attendant que mon mode emacs me trouve une position qui me semble crédible. Ça marche très bien, mais c'est assez mentalement déroutant
( je sais qu'il existe une syntaxe sans meaningful-indentation, mais on a envie de coder comme le reste des gens, en général )

Ok, l'emploi du système de layout peut faire bizarre au début. La règle est assez simple en fait : dans une construction sujette au layout, pour commencer une nouvelle commande/définition, il suffit de commencer au même niveau que la première expression de cette construction, c'est à dire la première expression qui suit le mot-clé (do/let/where peuvent introduire une telle construction, c'est tout).

Par exemple :

Code haskell :

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

1
2
3
4
5
6
main = do
   putStrLn hello -- première expression après le "do"
   putStrLn (bonj ++ -- commence une nouvelle commande
      "tout le monde") -- n'en commence pas une
 where hello = "Hello world" -- la première expr. après le "where" commence à 'h'
       bonj = "Bonjour, "

Voilà, tu remarqueras que je n'ai pas utilisé le même style pour le "do" et pour le "where", c'est toi qui choisis.

Par ailleurs, permet moi de te faire remarquer une petite larme de mauvaise foi : tu sautes sur l'excuse "c'est pas dans Haskell98", mais en cas de besoin tu sors la fonction "for", qui n'y est pas non plus, il me semble

for = flip map ? (présent dans Data.Traversable, donc définitivement pas dans H98, j'admets)
Ok, en fait la fonction la plus proche de for s'appelle forM_ et n'est pas non plus dans H98, par contre mapM_ est dans H98 et forM_ est un simple flip, exemple :

Code :

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

1
2
3
4
5
6
7
8
import Control.Monad
import System

main = do
  [n] <- getArgs
  forM_ [1..read n] $ \i -> do
    putStr ("fact " ++ show i ++ " : ")
    print (product [1..i])

--
Jedaï

[gasche]

Les gardes existent en OCaml aussi

Ce n'est pas une question de sémantique (par ailleurs ces deux fonctionnalités ne sont pas équivalentes, parce que les gardes caml s'emploient dans un matching, ce que ne permettent pas les gardes Haskell, qui elles sont plus souples au niveau des conditions testées), mais de syntaxe.

Ce qui est troublant c'est que les listes de "|" représentent habituellement une alternative, dont la nature est décrite par un symbole se trouvant avant cette liste : si on voit un "case ... of", on sait que c'est un pattern matching, si on voit un "=" on sait que c'est une définition de type somme (et il y a une symétrie forte entre les deux, même si on n'utilise pas le pattern matching que sur les types somme).
Les gardes Haskell sont syntaxiquement déroutantes parce qu'elles ne sont précédées par aucun keyword, et leur signification est grandement différent des deux exemples précédents. De plus, elles ne constituent pas une expression à part entière, car elles ne peuvent être utilisées que dans des déclarations de fonctions, en supprimant au passage le "=" qui caractérise toutes les autres déclarations de valeur/type/etc du langage.
Bref, c'est très déroutant.

(Ceci dit, ce n'est pas le seul point noir de la syntaxe Haskell, et à l'inverse la syntaxe OCaml a aussi un certain nombre de défauts (mais nous on a un préprocesseur qui tue))

[Jedai]

L'ésotérisme en Smalltalk:
...

Esotérique est défini comme "Accessible à un cercle restreint d'auditeurs, d'accès difficile.", je pense qu'on peut s'accorder sur le fait que la syntaxe de Smalltalk n'est pas ésotérique (tant qu'on restreint notre public aux seuls informaticiens), par contre les codes C obfusqués relèvent définitivement de l'ésotérique (et on peut arguer que le modèle objet de Smalltalk aussi...).

En programmation fonctionnelle on a effectivement également une bonne dose d'ésotérisme du côté des systèmes de types les plus évolués (Coq ? Cayenne ? Epigram ? ...), mais la syntaxe de base de OCaml ou Haskell ne relève définitivement pas de ce degré d'obscurité !!

--
Jedaï

[Garulfo]

Bon je me dois d'intervenir ici c'est clair -_-

Mais pour l'instant je n'ai pas complètement le temps.

Alors je vais juste m'en tenir à deux éléments et je reviendrais.

D'abord

1. la réussite d'un langage ne dépend pas de ces qualités : c'est triste à dire, mais on sait que pour qu'un langage fonctionne, il faut a) une entreprise/industrie qui le supporte, b) des certifications, c) des livres qui entourent le sujet produit par des gens qui sont en industrie de préférence, d) des colloques et des cours reliés sur tel ou tels points du langage. Notez bien que ces points ne sont pas indépendant les uns des autres. Pour faire de la pub pour un langage, il faut le support d'une industrie ou d'une entreprise. La qualité est rarement un gage de réussite en informatique, tant au niveau matériel, que logiciel. Souviron, je ne vais pas t'apprendre ça quand même -_- Les impératifs commerciaux et économiques sont plus important que le reste. Ce n'est pas le cas partout, et peut être que l'industrie dans laquelle tu travailles y échappe si je ne me trompe pas. Mais en général ça reste pathétiquement vrai.
2. la notation du C est ésotérique pour un étudiant sorti de science pur qui n'a jamais fait de programmation : et dans ce cadre, par expérience, avec des cours intensifs, je vous assure que le Scheme est mieux compris que le C au niveau syntaxe. Je pense que c'est celle de Ocaml qui s'en sort le mieux en général. Je parle par expérience. En 1 semaine, je rends des étudiants tout fraichement sorti du collège (au sens américain) capable d'utiliser Scheme – ils leur suffit de comprendre qu'on préfixe les opérations, ce qui pour un étudiant avec un bon bagage scientifique n'est pas difficile. Par contre, il faut au moins trois semaines pour être foutu de leurs faire comprendre la syntaxe C... l'affectation n'est pas un concept évident quand tu n'as jamais vu ça de ta vie. Je rappelle qu'en math (ce qu'ils ont étudiés pendant de longues années) ça n'existe pas. Vous seriez surpris de voir combien d'étudiants et d'étudiantes m'écrivent « a + b = c ; » après trois semaines. L'habitude d'avoir un « = » réflexif, qui pose une vérité (comme en math) est très tenace. L'utilisation du « = » leur pose plein de problème... Ahhhh si C avait eu l'intelligence d'écrire « := » ça serait tellement mieux -_-

Bon je reviendrais comme dirait le terminateur ^_^

[SpiceGuid]

Pour moi le mot ésotérique signifie "je repars de zéro".
Pour moi ça s'applique à COQ.
Et à la POO en OCaml.
Mais également à des choses beaucoup plus simples, comme passer de MS-Works à LaTeX (ce que je fais en ce moment).
À mon avis, pour une secrétaire, LaTeX est ésotérique, et de son point de vue les remarques de Souviron s'appliquent en tous points:

• cela a un intérêt théorique, mais bien peu d'intérêt pratique
• ce que j'en vois me semble complètement obscur comme notation
• dans le cadre de mon travail j'ai besoin d'interopérabilité
• prendre un langage d'initiés serait du suicide
• avec MS-Word quasi aucun mot ou concept nouveau
• avec MS-Word la fonctionnalité est parfaitement visible
• LaTeX est sans doute nécessaire dans le cadre de recherches universitaires

L'intitulé Langage Fonctionnel vs. Langage impératif est trop conflictuel dans sa formulation, moi aussi j'utilise l'impératif:

• soit parce que je n'ai pas le choix (par exemple programmer un gadget pour Oberon System 3)
• soit parce que le calcul est très simple mais très intensif et que la conversion en Delphi 5 m'apporte un gain de performance (jamais supérieur à 30%)

Les deux ont leur domaine, le fonctionnel est imbattable dans le traitement symbolique, les spécifications, les interpréteurs, et plus généralement les programmes complexes peu interactifs.

Pour ce qui est des performances voici les 3 triangles absolus à 11 étages (la source en OCaml) :



Si Souviron me donne les triangles absolus à 12 étages (avec la source en Fortran/C) alors je voudrai bien reconsidérer la question des performances en OCaml.

[Jean-Marc.Bourguet]

Même si les langages fonctionnels et impératifs sont équivalents dans leurs possibilités à résoudre des problèmes. De nombreuses personnes se demandent quel paradigme de langage de programmation ils peuvent utiliser.

Pour quel type de problèmes avez vous préférer privilégier un paradigme plutôt qu'un autre ?
Pensez-vous que pour certains problèmes, l'un des paradigmes n'est pas envisageable ?

Les deux aspects principaux d'une approche fonctionnelle sont, à mon avis, l'absence d'état implicite et la possibilité de manipuler les fonctions comme des valeurs.

En ce qui concerne l'absence d'état implicite, c'est quelque chose qui facilite le raisonnement et donc une technique que j'utilise quand elle me semble applicable, mais j'aurais beaucoup de mal à ne jamais avoir d'état implicite. D'une part parce que les problèmes que je traite sont spécifié comme cela, d'autre part parce qu'expliciter l'état me semble avoir nécessairement un cout important en mémoire et en performance dans certains cas (on se retrouve à avoir l'état initial et l'état final accessible en même temps, et donc duplication de tout ce qui est commun).

Quant à la possibilité de manipuler les fonctions comme des valeurs, en pratique la plupart des usages que j'en fait quand j'utilise des langages fonctionnels sont accessibles au prix de quelques lourdeurs dans les autres langages que j'utilise. Ces lourdeurs sont suffisantes pour diminuer le nombre de leurs utilisations, mais pas pour rendre impraticable la technique quand elle offre un avantage.

[Jean-Marc.Bourguet]

Et je maintiens, Jedai, que la notation est ésotérique.

Tout autant que celle du C.

Et je remercie SpiceGuid de m'avoir éclairé sur la définition.

Le fait que tu aies eu besoin de cet eclaircissement me fait douter de ta capacité à commenter sur le sujet.

[Garulfo]

Pour moi le mot ésotérique signifie "je repars de zéro".[...]

Dans ce sens, tout n'est-il pas ésotérique à un moment ou à un autre ? ^_^

[Jean-Marc.Bourguet]

Pour ce qui est des performances voici les 3 triangles absolus à 11 étages (la source en OCaml)
[...]
Si Souviron me donne les triangles absolus à 12 étages (avec la source en Fortran/C) alors je voudrai bien reconsidérer la question des performances en OCaml.

Qu'est-ce que ça apporterait pour cette discussion? Ou je connais encore moins OCaml que je ne m'imaginais, ou ce code n'est pas un exemple de programmation fonctionnelle (utilisation d'état, pas d'utilisation de fonctions comme valeur).

[Garulfo]

l'absence d'état implicite

Ne voulais-tu pas dire explicite ? Parce qu'il y a toujours un état implicite.

[Jean-Marc.Bourguet]

Ne voulais-tu pas dire explicite ? Parce qu'il y a toujours un état implicite.

Problème de perspective. Une technique en programmation fonctionnelle est de passer explicitement l'état qu'on aurait passé implicitement dans un programme impératif et de retourner le nouvel état de manière explicite également (Et si j'ai bien compris -- je n'en suis pas certains --, les monades d'Haskell ne sont que du sucre syntaxique autour de cette technique). D'où mon utilisation d'"état implicite", mais j'admets sans peine qu'on doit pouvoir trouver une perspective dans lequel on inverse les mots.

[Jedai]

Problème de perspective. Une technique en programmation fonctionnelle est de passer explicitement l'état qu'on aurait passé implicitement dans un programme impératif et de retourner le nouvel état de manière explicite également (Et si j'ai bien compris -- je n'en suis pas certains --, les monades d'Haskell ne sont que du sucre syntaxique autour de cette technique).

Seule la monade State d'Haskell correspond à cette définition, ainsi que ST et IO d'une façon moins directe. Maybe ou List par contre ne correspondent pas du tout à cette description. Les monades sont une notion beaucoup plus générale qu'une simple simulation du paradigme impératif.

En ce qui concerne l'absence d'état implicite, c'est quelque chose qui facilite le raisonnement et donc une technique que j'utilise quand elle me semble applicable, mais j'aurais beaucoup de mal à ne jamais avoir d'état implicite. D'une part parce que les problèmes que je traite sont spécifié comme cela, d'autre part parce qu'expliciter l'état me semble avoir nécessairement un cout important en mémoire et en performance dans certains cas (on se retrouve à avoir l'état initial et l'état final accessible en même temps, et donc duplication de tout ce qui est commun).

Ce n'est pas si lourd que ça dans la plupart des cas, d'une part le Garbage Collector supprime les états anciens devenus inutiles, d'autre part le paradigme fonctionnel favorise les structures de données "partageables" dont une grande partie reste valable d'une mise à jour à l'autre et est donc partagée entre les différentes versions d'une donnée.
Dernièrement, tous les langages fonctionnels décents offrent la possibilité d'avoir un état implicite, par exemple en Haskell dans les monades IO ou ST (la monade ST permettant même de s'assurer que de l'extérieur la fonction est bien transparente référentiellement), toute l'astuce étant de restreindre au maximum mécaniquement la portée de cet état, et de garder les manipulations de données les plus pures possibles pour conserver au mieux les avantages du fonctionnel.

Quant à la possibilité de manipuler les fonctions comme des valeurs, en pratique la plupart des usages que j'en fait quand j'utilise des langages fonctionnels sont accessibles au prix de quelques lourdeurs dans les autres langages que j'utilise. Ces lourdeurs sont suffisantes pour diminuer le nombre de leurs utilisations, mais pas pour rendre impraticable la technique quand elle offre un avantage.

La question devient donc : Vaut-il mieux utiliser un langage fondamentalement sûr dans lequel on peut introduire de façon contrôlée des éléments non sécurisé (excepté par les preuves qu'on peut faire nous-même), ou un langage fondamentalement non-sûr où on peut programmer de façon sûre avec une attention de tous les instants...
C'est un peu caricatural bien sûr, mais bien que le paradigme impératif ait tout à fait sa place, pour ma part j'ai fait le choix de la première option.

--
Jedaï

[gorgonite]

Ce n'est pas si lourd que ça dans la plupart des cas, d'une part le Garbage Collector supprime les états anciens devenus inutiles, d'autre part le paradigme fonctionnel favorise les structures de données "partageables" dont une grande partie reste valable d'une mise à jour à l'autre et est donc partagée entre les différentes versions d'une donnée.

tu oublies de signaler que les implémentations efficaces des langages fonctionnelles (ocaml et ghc) ont un garbage collector digne de ce nom... pour éviter qu'on ne les compare aux piètres performances de leurs cousins de chez Java & cie

[Jean-Marc.Bourguet]

Seule la monade State d'Haskell correspond à cette définition, ainsi que ST et IO d'une façon moins directe. Maybe ou List par contre ne correspondent pas du tout à cette description. Les monades sont une notion beaucoup plus générale qu'une simple simulation du paradigme impératif.

Donc il va falloir que je replonge la dedans pour voir exactement ce que ça offre d'autre. Mais dans cet usage, on est d'accord que ce n'est que du sucre syntaxique ou bien même cela je ne l'ai pas compris?

Ce n'est pas si lourd que ça dans la plupart des cas, d'une part le Garbage Collector supprime les états anciens devenus inutiles,

Si le GC entre en jeu, il y a eu duplication... et c'est trop tard pour nous.

d'autre part le paradigme fonctionnel favorise les structures de données "partageables" dont une grande partie reste valable d'une mise à jour à l'autre et est donc partagée entre les différentes versions d'une donnée.

Les structures sur lesquelles je travaille sont des graphes (peu dense) qu'on modifie et qu'on parcour avec une vision très locale. De plus les noeuds sont placés dans un espace à 3 dimensions et il faut aussi faire des recherches spaciales. Tu connais une structure partageable et efficace qui le permette? J'ai des collègues que ça intéresseraient vraissemblablement.

La question devient donc : Vaut-il mieux utiliser un langage fondamentalement sûr dans lequel on peut introduire de façon contrôlée des éléments non sécurisé (excepté par les preuves qu'on peut faire nous-même), ou un langage fondamentalement non-sûr où on peut programmer de façon sûre avec une attention de tous les instants...
C'est un peu caricatural bien sûr, mais bien que le paradigme impératif ait tout à fait sa place, pour ma part j'ai fait le choix de la première option.

Non, ce n'est pas la question. C'est une des questions. Si c'était le seul facteur, j'utiliserais aussi un autre langage que le C++.

[LLB]

Pour ce qui est des performances voici les 3 triangles absolus à 11 étages (la source en OCaml) :

On dirait que le code source est une traduction directe d'un code C. Je trouve l'exemple extrêmement mal choisi si le but est de défendre le fonctionnel. C'est du code purement impératif, et je ne vois aucune difficulté à donner l'équivalent C (ou y aurait-il une subtilité qui m'a échappé ?).

Quant à la possibilité de manipuler les fonctions comme des valeurs, en pratique la plupart des usages que j'en fait quand j'utilise des langages fonctionnels sont accessibles au prix de quelques lourdeurs dans les autres langages que j'utilise. Ces lourdeurs sont suffisantes pour diminuer le nombre de leurs utilisations

C'est ce qui arrive souvent. La plupart des langages permettent différents paradigmes, mais cela ne se fait pas toujours sans douleur.

Les efforts nécessaires pour faire du fonctionnel en C++ sont tels que ça déconseille fortement son utilisation, que les autres développeurs C++ auront du mal à comprendre à le code, et que le code perdra beaucoup en clarté. Au final ce que l'on cherche, c'est souvent la productivité ; d'autres aspects en découlent directement : rapidité d'implémentation, facilité de maintenance, et donc concision du code. Utiliser du C++ pour faire du fonctionnel, c'est relativement dangereux (sauf à le limiter à des portions précises).

De la même façon, et pour les mêmes raisons, faire du code purement impératif en Caml me semble une mauvaise idée. Tout le langage a été conçu pour privilégier le fonctionnel, abuser de l'impératif me semble donc néfaste.

La question n'est donc pas de savoir ce que peuvent faire les langages, mais plutôt avec quel paradigme et quel langage on peut être le plus productif.

Bien sûr, on peut quasiment tout faire en C++, parce que son système de templates est extrêmement souple ; mais, il faut se demander jusqu'où on est prêt à aller. Par exemple, quand j'écris une structure de données de ce type :

Code :

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

1
2
3
type ('a,'b) tree =
 | Node of 'a * ('b,'a) tree
 | Empty

Ou :

Code :

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

1
2
3
type 'a tree =
  | Op of ('a -> 'a -> 'a) * 'a tree * 'a tree
  | Val of 'a

En général, lorsque je demande à un développeur C/C++/Java/C#, de m'écrire l'équivalent dans son langage, les résultats sont catastrophiques. La clarté en prend un coup, c'est inévitable. Mais très souvent, la sûreté est réduite de façon dramatique. Je ne parle même pas des limitations du langage (qui font que NULL est une valeur acceptée par le compilateur), mais de l'implémentation : beaucoup de développeurs utilisent des bidouilles (genre, on ajoute un booléen dans la structure pour savoir si c'est un noeud ou une feuille), parce que c'est plus simple à implémenter que de le faire "proprement" avec une hiérarchie de classes.

Le problème n'est pas de savoir si c'est possible de faire quelque chose de bien en C++, mais si les développeurs auront le courage de le faire. C'est un peu comme certains développeurs C qui utilisent presque uniquement des tableaux, juste parce que c'est plus simple à utiliser qu'un arbre.

J'ai rencontré beaucoup d'autres exemples comme ça. Entre autres, faire une fonction qui renvoie un couple de valeurs n'est pas toujours simple à faire, et beaucoup de développeurs C++/Java/etc. utilisent des bidouilles pour pallier ce manque (genre, on ajoute un argument en écriture seule), au lieu d'utiliser la solution propre (oui, je connais Boost).

La question devient donc : Vaut-il mieux utiliser un langage fondamentalement sûr dans lequel on peut introduire de façon contrôlée des éléments non sécurisé, ou un langage fondamentalement non-sûr où on peut programmer de façon sûre avec une attention de tous les instants ?

J'aime beaucoup ce résumé.

Si c'était le seul facteur, j'utiliserais aussi un autre langage que le C++.

Utilises-tu le C++ par choix ou par contrainte ?

Je comprends que l'on soit obligé C++ dans certains cas : performances, manipulations bas-niveau, compatibilité, bibliothèques, ou collègues ne connaissant rien d'autre. Si c'est par choix, j'aimerais que tu l'expliques. Quelle fonctionnalité de C++ te semble importante, au point que tu préfères ce langage, malgré tous ses défauts ?

[gasche]

Donc il va falloir que je replonge la dedans pour voir exactement ce que ça offre d'autre. Mais dans cet usage, on est d'accord que ce n'est que du sucre syntaxique ou bien même cela je ne l'ai pas compris?

De manière générale, on peut voir les monades comme permettant de "cacher" une partie des manipulations sur une structure de donnée (dans l'opérateur bind, >>= ). Dans le cas de State ou IO par exemple, ce sera effectivement un état implicite (bien que pour IO, il y aie de la triche au niveau de l'implémentation), et c'est d'ailleurs aussi le cas pour la monade Writer il me semble. Mais certaines monades permettent de cacher d'autres manipulations, d'autres comportements : la monade List, par exemple, permet de représenter de manière "implicite" des fonctions qui "peuvent renvoyer plusieurs résultats possibles" (et donc, mais il faut changer de point de vue, des opérations 'non déterministes').
Mais globalement, l'idée de "on rajoute un comportement implicite" me semble assez bonne (c'est franchement pas facile de comprendre les monades, si t'en es arrivé là t'es presque sauvé), et assez proche de l'idée de base qui a conduit l'utilisation des monades (et donc de la théorie des catégories) dans les langages de programmation.

Dans tous les cas, on ne peut pas vraiment parler de "sucre syntaxique" (parce que les modifications du code sont bien là, que ce soit avec des >>= ou des do), mais plutôt de "sucre comportemental", déterminé par le créateur de la monade.

Ce n'est pas si lourd que ça dans la plupart des cas, d'une part le Garbage Collector supprime les états anciens devenus inutiles

En même temps, il a relativement raison sur ce point : il me semble que les monades sont une méthode de programmation qui cohabite "relativement mal" (pour une valeur pas si terrible que ça de "mal") avec les ramasses miettes.
J'ai entendu parler quelque fois de problèmes de performances dans les codes monadiques lié à cela; on en trouve une description relativement précise dans le papier de Hughes, qui introduit les Arrows pour résoudre justement ce problème : http://www.cs.chalmers.se/~rjmh/Papers/arrows.ps

La question devient donc : Vaut-il mieux utiliser un langage fondamentalement sûr dans lequel on peut introduire de façon contrôlée des éléments non sécurisé, ou un langage fondamentalement non-sûr où on peut programmer de façon sûre avec une attention de tous les instants ?

J'aime beaucoup ce résumé.

Fais gaffe, c'est une pratique courante de Haskellien, qui va te dire après que ton langage impur est mauvais, et qu'il faut passerM au codeM dans un langageM adaptéM.
(Ceci dit, j'aime beaucoup les langages purs, c'est tout joli.)

Remarque, en cas de problème, on pourra toujours lui expliquer qu'il ferait mieux d'utiliser un langage strict dans lequel on peut introduire de façon contrôlée des éléments paresseux, plutôt qu'un langage fondamentalement leakant de partout, qui permet de programmer de façon efficace avec un profiling de tous les instants, et en se faisant fondre le cerveau tous les trois jours.
(Ceci dit, j'aime beaucoup les langages paresseux, c'est tout joli.)

[Jedai]

Fais gaffe, c'est une pratique courante de Haskellien, qui va te dire après que ton langage impur est mauvais, et qu'il faut passerM au codeM dans un langageM adaptéM.
(Ceci dit, j'aime beaucoup les langages purs, c'est tout joli.)

Remarque, en cas de problème, on pourra toujours lui expliquer qu'il ferait mieux d'utiliser un langage strict dans lequel on peut introduire de façon contrôlée des éléments paresseux, plutôt qu'un langage fondamentalement leakant de partout, qui permet de programmer de façon efficace avec un profiling de tous les instants, et en se faisant fondre le cerveau tous les trois jours.
(Ceci dit, j'aime beaucoup les langages paresseux, c'est tout joli.)

Sans dire que Haskell est parfaitM, il offre pas mal d'avantages intéressantsM qui peuvent contrebalancer ses défauts par ailleurs (personnellement, je ne trouve pas que l'usage de monades soit un défaut au contraire, et si l'évaluation paresseuse peut avoir des conséquences inattendues pour le débutant, c'est un problème en cours de résolution, espérons-le, les choses se sont déjà beaucoup améliorés ces dernières années).

Mais au-delà des questions de langages (et l'évaluation paresseuse est un tout autre sujet encore), tu es d'accord que mon petit laïus s'applique par trop mal au dilemme fonctionnel/impératif ? Bien sûr il est légèrement caricatural , mais tu ne nieras pas qu'utiliser des éléments impératifs en OCaml est déjà mieux "isolé" de la partie fonctionnelle qu'avec du C, non ?

--
Jedaï

NB : Pour ceux qui n'auraient pas suivi l'histoire des (M), c'est simplement que les fonctions agissant sur des monades en Haskell ont conventionnellement un nom finissant en M, comme le forM évoqué plus tôt.

[Jedai]

En même temps, il a relativement raison sur ce point : il me semble que les monades sont une méthode de programmation qui cohabite "relativement mal" (pour une valeur pas si terrible que ça de "mal") avec les ramasses miettes.
J'ai entendu parler quelque fois de problèmes de performances dans les codes monadiques lié à cela; on en trouve une description relativement précise dans le papier de Hughes, qui introduit les Arrows pour résoudre justement ce problème : http://www.cs.chalmers.se/~rjmh/Papers/arrows.ps

Ce n'est pas tant une question de GC que d'"excès" de monades : le concept de monade, une fois compris, est très attirant, on se met à tout faire sous forme de monade parce que ça présente pas mal d'avantage en terme d'intéropérabilité, de modularité, etc... Mais en réalité dans certains types de problèmes les monades ne sont pas vraiment adaptées, en particulier dans tous les problèmes où l'on aimerait pouvoir faire de l'introspection sur le déroulement de l'exécution lui-même. C'est pour pallier à ce défaut que Hugues introduit les Arrows, qui sont plus générales que les monades, mais donc plus difficiles à utiliser.
Ce problème n'est pas lié au paradigme fonctionnel, ni même aux monades en elle-même (qui sont extraordinairement utiles pour toute une gamme de choses), par contre on pourrait arguer qu'il est lié au traitement préférentiel des monades par Haskell (sucre syntaxique, bibliothèque standard, ...) qui a pu encourager à les utiliser même lorsqu'elles n'étaient pas vraiment faites pour la tache.

--
Jedaï

[Jean-Marc.Bourguet]

Utilises-tu le C++ par choix ou par contrainte ?
...
Si c'est par choix, j'aimerais que tu l'expliques. Quelle fonctionnalité de C++ te semble importante, au point que tu préfères ce langage, malgré tous ses défauts ?[

On fait toujours des choix en fonction des contraintes et des connaissances qu'on a. J'ai l'impression que dans ton etat d'esprit j'utilise le C++ par contrainte. Dans le mien c'est le meilleur choix. Meme pour les projets perso j'utilise souvent le C++.

Tu peux isoler certaines contraintes et dire qu'on utilise les langages qui les remplissent bien a cause de leurs qualites et en isoler d'autres et dire qu'on utilise les langages qui les remplissement bien par contrainte. Mais ca me semble etre un exercice essentiellement biaise dont le seul effet est d'en resortir frustre.