Discussion :

[GnuVince]

Je ne sais pas de quels langages fonctionnels tu parles, mais pour le lisp, sa syntaxe est contre intuitive :
5 + 3 en C s'écrirait (+ 5 3) en lisp...

Ton exemple est trivial. Oui, l'aritmétique, comme n'importe quoi d'autre en Lisp, est en notation préfixe. Dans des langages plus mainstream, on entre-mêle le tout. Les opérateurs mathématiques sont infix, les fonctions sont préfixes et on a des opérateurs postfix (++ et -- entre autre). On a donc besoin d'apprendre un tas de règle de précédence. C'est pas intuitif que le > va se faire avant ton & (ou vice versa, je m'en souviens jamais.)

Bah, si les langages fonctionnelles sont si bien que ça, pourquoi les développeurs s'embettent à faire du C++ pas sur qui leur coutera a coup sur des SIGSEGV (si ils n'utilisent pas de ramasse miettes) ?

Je t'invite à relire le thread: l'absence de modules qui est expliquée par l'absence d'une tonne de programmeurs qui est expliquée par le fait que les êtres humains ont peur du changement.

C'est pas parce que C++ est nécessairement meilleur ou pire que Haskell qu'il est plus utilisé, c'est qu'il y a pas eu une masse critique du côté des langages fonctionnels encore.

Regarde Ruby comme exemple, il y a trois ans, personne en parlait, juste quelques geeks qui aiment explorer de nouveaux langages. Puis, Rails apparaît, les programmeurs y voient une meilleure façon de créer des applications et des services web, et commence à l'utiliser et Ruby par la même occasion. Et aujourd'hui, on trouve des gens qui utilisent Ruby partout.

Si Haskell ou O'Caml avaient leur "killer app", quelque chose que les programmeurs veulent absolument avoir, mais qui n'est pas tout à fait possible dans leur langage actuel, ils vont essayer et il va y en avoir qui vont coller.

La question "Si X est si bon, pourquoi personne s'en sert" est pas une bonne question, c'est un argument par popularité.

[millie]

Le thème de la sécurité est souvent revenu dans ce débat.

Ils arrivent que pour certaines applications critiques, on prouve certaine partie de programme, et donc justement, parmi les personnes qui ont déjà prouvés certains de leurs programmes (où au moins prouver la terminaison d'un algorithme) avec un assistant de preuve. Ne pensez-vous pas qu'il est plus facile de prouver au moins la terminaison d'un algorithme avec un style récursif plutôt qu'avec un style impératif ?

(à noter que j'ai parlé de style et non de langages).

[Jedai]

La programmation fonctionnelle n'est pas vraiment intuitive (lorsqu'elle est pur) puisqu'elle interdit toute boucle, elle interdit les tableaux, les effets de bords, les variables globales.

Les boucles sont effectivement interdites, et sont en général remplacés par de la récursivité, mais le plus fréquemment par des combinateurs classiques facile à utiliser et à comprendre (comme map ou les fold, et qu'on ne me dise pas qu'ils sont plus compliqués que la boucle for() du C...), en attendant je ne vois pas ce que les boucles ont de plus "intuitif" qu'un map.
Je ne connais aucun langage fonctionnel qui interdise les tableaux, même les plus purs, et sans doute pas Lisp ou OCaml, sur quelle expérience te fondes-tu exactement pour affirmer cela ? Il est vrai qu'on a plus tendance à utiliser des listes chainées qu'en C, mais n'est-ce pas principalement parce que les listes chainées sont beaucoup plus difficile à utiliser proprement en C (ou dans la plupart des langages impératifs, bien que je ne pense pas que ce soit inhérent au paradigme) ?
Les effets de bords et les variables globales sont certes interdits, mais dire qu'ils sont intuitifs me semble assez étrange, ils ne l'étaient pas pour moi, et même le plus chevronné des programmeur impératif comme Souviron34 te confirmera que les variables globales sont peu recommandable en général même dans un contexte impératif... Il vaut mieux les localiser le plus possible, tout comme les effets de bord, ce qui est justement ce qui dans un langage pur comme Haskell est offert par l'intermédiaire des monades (en particulier IO, ou ST qui présente l'avantage de la transparence référentielle extérieure bien qu'ayant un intérieur véritablement impératif (où les mises à jour se font en place, et sont donc performantes, je réponds ainsi à une question posée précédemment dans la discussion)).

--
Jedaï

[souviron34]

mais le plus fréquemment par des combinateurs classiques facile à utiliser et à comprendre (comme map ou les fold, et qu'on ne me dise pas qu'ils sont plus compliqués que la boucle for() du C...), en attendant je ne vois pas ce que les boucles ont de plus "intuitif" qu'un map.

juste un point de détail là-dessus.. C'est EXACTEMENT ce que je voulais dire par "langage ésotérique"...

En mathématique, tu écris par exemple le développement d'une suite comme :

Code :

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

1
2
3
   N
Somme expression(i)
   0

Quand tu fais un pseudo-code, que tu décris un algorithme (et je reviens donc sur les mathématiques) tu écris (en français) :

Code :

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

pour tout x variant de 0 à N

l'écriture

Code :

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

1
2
for ( i = 0 ; i < N ; i = i + 1 )
...

ou

Code :

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

1
2
3
DO  I = 0, N
...
END DO

me semble simplement le reflet direct de la pensée..

Alors que les notations que tu montres (et les mots que tu cites : map et fold) ne me sautent pas aux yeux comme étant liés conceptuellement à mon problème...


D'ailleurs, ce n'est pas pour rien que Fortran s'appelle "FORmula TRANslator"...


Juste pour te dire que ce n'est pas aussi évident et transparent que tu le dis...

[LLB]

Code :

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

for ( i = 0 ; i < N ; i = i + 1 )

Cette notation m'a beaucoup gêné quand j'ai appris le C. Je venais du Pascal, et j'ai mis du temps à comprendre comment ça marche vraiment. Plus d'une fois, j'ai hésité sur le < ou <=. Quand j'ai voulu faire la boucle dans l'ordre décroissant, j'ai eu du mal à la faire comme je voulais (notamment aux bornes). Et il m'est arrivé plusieurs fois de faire une boucle infinie par erreur.

Cette notation n'est absolument pas naturelle.

Je préfère bien plus la notation de Pascal ou de Caml :

Code :

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

for i := 1 to N do

Mais dans une boucle for, tu es contraint de faire un effet de bord. Ca me semble loin de l'esprit des mathématiques. Tu es obligé, en C, d'ajouter une variable supplémentaire pour mettre à jour le résultat : je n'ai jamais fait ça en maths.


Par ailleurs, puisque tu parles de boucle et de somme, je trouve la notation avec les compréhensions (Haskell, Python, F#...) infiniment plus proche des mathématiques que celle du C.

Par exemple, si je veux la somme des n², pour n entre 1 et 10, j'écrirais :

Code Haskell :

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

sum [n * n | n<-[1..10]]

Note : je n'ai jamais écrit plus de 3 lignes d'Haskell et je n'ai même pas de compilateur pour tester. Même si je manque d'expérience, le code Haskell m'a souvent semblé très clair (une fois que l'on connait les quelques opérateurs de base).

D'ailleurs, ce n'est pas pour rien que Fortran s'appelle "FORmula TRANslator"...

Et ce n'est pas pour rien que Haskell vient du prénom d'un mathématicien/logicien (Curry).
Comme les maths sont évoquées ici, je rappellerai juste que les langages fonctionnels reposent sur des bases mathématiques (cf lambda calcul et isomorphisme de Curry-Howard).

[Jean-Marc.Bourguet]

Non : il y a des critères qui imposent l'utilisation d'un langage précis (par exemple, on ne veut pas en apprendre un autre;

C'est un argument que je n'ai jamais donné (j'ai écrit que mon temps limité me semblait mieux employé à explorer différents langages qu'à en pousser un au point où j'y sois plus performant qu'en C++ -- considérant le temps dont je dispose et le fait que le C++ est le langage que j'utilise professionnellement, on peut même se demander si c'est un objectif atteignable).

ou on veut garder une compatibilité forte avec un ancien code),

Il y a une chose à ne pas oublier: il n'y a guère de critères absolus (heureusement, ils sont souvent contradictoires!). Si tu as des arguments assez forts, il n'y en a pas que tu ne puisses ignorer. Pour une entreprise, la compatibilité avec un ancien code, c'est généralement le moyen de limiter les coûts et les risques, c'est tout.

Il est parfois possible d'ajouter des abstractions, mais il y en a beaucoup que l'on ne fera pas, au final. Par exemple, je me vois mal remplacer tous les "int" de mon code C++ par une classe "Integer" qui ferait toutes les vérifications. Ca peut se faire à des endroits précis, quand il y a un besoin particulier, mais ce n'est pas une habitude que l'on prend (en tout cas, je ne l'ai jamais rencontré).

Parce que les avantages perçus ne sont pas assez grand par rapport aux incovénients perçus. L'usage systématique de std::string est dans le cas inverse.

Si utiliser une telle classe était beaucoup plus contraignat qu'utiliser des int, tu aurais un point. Mais de mon point de vue, ce n'est pas le cas.

C'est peut-être de la chance, mais je n'ai jamais rencontré le moindre problème avec un GC,

Ou le type de projets. Je travaille sur des gros projets -- ceux ou tu peux découvrir après quelques années de participation qu'il y a une équipe dont tu n'avais jamais entendu parler -- et ai donc tendance à considérer tout à travers ce prisme.

alors que j'ai eu nombre de segfault en C/C++. Je sais tout à fait que c'est possible, mais il me semble que c'est plus facile à éviter qu'en C/C++ (bien sûr, il ne faut pas accorder une confiance aveugle dans le GC).

J'ai un peu précisé mon point de vue dans http://www.developpez.net/forums/sho...4&postcount=69.

[DarkVenoM]

Regarde Ruby comme exemple, il y a trois ans, personne en parlait, juste quelques geeks qui aiment explorer de nouveaux langages. Puis, Rails apparaît, les programmeurs y voient une meilleure façon de créer des applications et des services web, et commence à l'utiliser et Ruby par la même occasion. Et aujourd'hui, on trouve des gens qui utilisent Ruby partout.

Si Haskell ou O'Caml avaient leur "killer app", quelque chose que les programmeurs veulent absolument avoir, mais qui n'est pas tout à fait possible dans leur langage actuel, ils vont essayer et il va y en avoir qui vont coller.

La question "Si X est si bon, pourquoi personne s'en sert" est pas une bonne question, c'est un argument par popularité.

Certes, mais pourquoi les langages fonctionnelles n'ont pas de "killer app" ?

[Garulfo]

[...]
Quand tu fais un pseudo-code, que tu décris un algorithme (et je reviens donc sur les mathématiques) tu écris (en français) :

Code :

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

pour tout x variant de 0 à N

l'écriture

Code :

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

1
2
for ( i = 0 ; i < N ; i = i + 1 )
...

Ça ne marche pas ton argument Souviron. En effet, la plupart des gens écrivent leur pseudo-code en pensant impératif. Il est donc logique que leur pseudo-codes soient plus proches des langages impératifs.

En math, si tu as un proche qui connait sa matière, on ne te présentera jamais le factoriel sous la forme « on prend un nombre x qui varie de 1 à n et à chaque pas on le multiplie avec la valeur .... » en fait je ne saurais même pas le terminer. On dirait, et on dit je pense, « tu multiplies TOUS les nombres entre 1 et n » et ici il n'y a pas de notion impérative ! Aucune variable n'est modifiée. Aucune variable n'est même apparente dans l'énoncé.
Attention je parle de variable au sens informatique. Une variable en math, c'est un argument de fonction ou une constante au sens informatique.

Apprends leurs d'abord à faire des sommes par récursivité, et tu verras qu'ils écriront des algorithmes sous forme mathématique. C'est même vérifié par les matheux qui n'ont jamais vu de programmation. Ils n'écrivent pas du tout comme tu l'écris.

[DarkVenoM]

Tu rencontres ce problème quand tu as été exposé à de l'impératif auparavant. La plupart des écoles qui enseignent le fonctionnel le font comme premier langage. Et c'est mieux ainsi.

Apres c'est subjectif (enfin peut etre pas...) mais certains algorithmes me sembles plus intuitifs en itératifs, en utilisant au besoin des variables globales et en faisant des effets de bord (même si ça rend le programme plus difficile a prouver et que ça le rend moin sur). Apres il y a d'autres algorithmes qui sont plus faciles à implémenter en récursifs. Se forcer a tout implémenter en récursif (ou en impératif), nous obligent a fonctionner parfois a l'envers (selon moi), c'est pour cela que je préfere la programmation fonctionnelle par intérim qu'a plein temps

Je ne connais aucun langage fonctionnel qui interdise les tableaux, même les plus purs, et sans doute pas Lisp ou OCaml, sur quelle expérience te fondes-tu exactement pour affirmer cela ? Il est vrai qu'on a plus tendance à utiliser des listes chainées qu'en C, mais n'est-ce pas principalement parce que les listes chainées sont beaucoup plus difficile à utiliser proprement en C (ou dans la plupart des langages impératifs, bien que je ne pense pas que ce soit inhérent au paradigme) ?

En cours on nous a dit que les tableaux était une structure impérative, et que si ils étaient disponibles en Ocaml, c'est parce que ce dernier était impur. Apres sur le net je trouve des site qui prétendent l'existence de tableaux en Haskell (réputé pur me semble t' il), et d'autres prétendant sa non existence au sein de ce langage, et son absence au sein de la programmation fonctionnelle
( http://www.cs.st-andrews.ac.uk/~ab/doc/ses02.pdf)

[Garulfo]

[...]
Je ne sais pas de quels langages fonctionnels tu parles, mais pour le lisp, sa syntaxe est contre intuitive :
5 + 3 en C s'écrirait (+ 5 3) en lisp...

Toutes les fonctions sont préfixés en LISP. C'est la seule difficulté au niveau syntaxe. Elle n'est pas valide en ocaml par exemple. Tu veux une liste de toutes les difficultés de syntaxe que rencontrent mes étudiants en C++ ??
Ils se font à la syntaxe du Lisp (du Scheme en fait) en 1 semaine ou 2 pour les plus mauvais.

Je veux pas dire de bétise, mais il me semble que le := est utilisé en C, il me semble même que les premieres versions du C utilisait cette notation pour la différencier de '= ' qui lui représentait l'opérateur booléen de l'égalité.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <stdlib.h>

int main ()
{
   int y;
   y := 0;
   if (y == 0)
   {
      printf("oui");
   }
   return 0;
}

ce qui donne

Code :

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

1
2
3
4
garulfo@Archimede $ gcc essai.c 
essai.c: In function ‘main’:
essai.c:8: error: parse error before ‘=’ token

Bah, si les langages fonctionnelles sont si bien que ça, pourquoi les développeurs s'embettent à faire du C++ pas sur qui leur coutera a coup sur des SIGSEGV (si ils n'utilisent pas de ramasse miettes) ?

Parce que, d'une part, les langages fonctionnels ne sont pas l'ultime panacée et les langages impératifs ont leurs places, d'autre part, beaucoup de gens comme toi ne connaissent que mal les langages fonctionnels et propagent des idées fausses. De plus, l'inertie de l'industrie fait que cela limite l'insertion d'un nouveau paradigme, qu'il n'y a pas ou peu d'entreprise pour supporter un langage fonctionnel (ce qui est aussi du à ce qui est dit avant) et que ceci est nécessaire pour l'arrimage en entreprise. Il faut aussi noter le problème des bibliothèques et le fait que les étudiants voyant les langages impératifs avant, ils sont convaincus que c'est mieux et que le reste est une perte de temps, sans chercher à comprendre souvent.

C'est un cercle vicieux car beaucoup de ces points engendrent les autres.

[LLB]

Certes, mais pourquoi les langages fonctionnelles n'ont pas de "killer app" ?

Ben, trouve-nous une idée révolutionnaire qui fasse que tout le monde ait besoin de ces langages.

Le C s'est imposé pour des raisons historiques. Le Java, pour sa bibliothèque/portabilité. Le Perl pour sa manipulation de fichiers. Le Ruby avec Rails comme ça a été dit. Le PHP pour son insertion dans du HTML et sa bibliothèque web. Trouve-nous quelque chose pour un langage fonctionnel.

Il y a déjà l'écriture de compilateurs (où le fonctionnel est assez présent), mais c'est trop limité comme domaine. Il y a aussi la programmation parrallèle. À voir.

Se forcer a tout implémenter en récursif (ou en impératif)

Le fonctionnel ne se résume pas à la notion de récursion !

Je suis d'accord avec le reste : comme je l'ai dit, je préfère aussi ne pas être enfermé dans un paradigme.

Parce que les avantages perçus ne sont pas assez grand par rapport aux incovénients perçus.

Pourtant certains langages le font ; d'autres permettent au moins de vérifier les dépassements (par exemple, lancer une exception en cas d'overflow).

Si utiliser une telle classe était beaucoup plus contraignat qu'utiliser des int, tu aurais un point.

Pour autant que je sache, il faudrait ajouter des conversions explicites depuis/vers les int (de la même façon que c_str des string).

Mais ce n'était qu'un exemple simple. De nombreuses fonctionnalités des autres langages ne sont pas dans C++, et ne peuvent être implémentées de façon élégante. Par exemple, les compréhensions ; par exemple, l'introspection ; par exemple, l'ajout a posteriori de méthodes à une classe ; etc. Beaucoup de fonctionnalités des langages dynamiques ne sont pas présentes dans C++. Mais tu l'as reconnu toi-même : "le C++ ne m'offre peut-être pas autant d'abstractions de base que d'autres langages". C'est pour cette raison que je ne le considère pas d'aussi "haut-niveau" que d'autres langages.

En cours on nous a dit que les tableaux était une structure impérative

Hé bien, c'est faux. Ils ne sont certes pas défini par récurrence (c'est pour cette raison que la manipulation de listes est parfois plus simple en fonctionnel), mais ça dépend si ton tableau est mutable ou non.

En Caml, le tableau est toujours modifiable, ce qui est une impureté. En Haskell, va voir ici :
http://www.cs.auckland.ac.nz/referen...ml/arrays.html

[DarkVenoM]

Parce que les avantages perçus ne sont pas assez grand par rapport aux incovénients perçus.

C'est un peu ce que je reproche a la programmation fonctionnelle pure, sa rigueur m'agace un peu. Alors oui c'est probablement plus facile de prouver un programme purement fonctionnelle (les fonctions récursives pourront par exemple êtres démontrées par récurences...), mais on a pas besoin tout les jours de prouver une application. Apres oui, en théorie ça permet de faire des programmes plus fiables et plus faciles a débugger, mais je doute qu'a court/moyen/long terme la programmation fonctionnelel pur apporte toujours des avantages par rapport à la programmation impérative.

[Jedai]

C'est un peu ce que je reproche a la programmation fonctionnelle pure, sa rigueur m'agace un peu. Alors oui c'est probablement plus facile de prouver un programme purement fonctionnelle (les fonctions récursives pourront par exemple êtres démontrées par récurences...), mais on a pas besoin tout les jours de prouver une application. Apres oui, en théorie ça permet de faire des programmes plus fiables et plus faciles a débugger, mais je doute qu'a court/moyen/long terme la programmation fonctionnelel pur apporte toujours des avantages par rapport à la programmation impérative.

Qui a dit qu'elle apportait "toujours" des avantages ? Les 3/4 des derniers messages ont souligné que l'impératif restait indispensable dans un certain nombre de domaine.

Tu as déjà programmé en OCaml et en C, dis-moi, combien de tes programmes OCaml ont fonctionné correctement dès qu'ils ont compilé, combien de tes programmes en C ? Sauf si tu as de réelles difficultés avec le fonctionnel (dû à des mauvais profs, ou à une grande habitude de l'impératif au préalable), je suis près à parier que la statistique est énormément en faveur d'OCaml. C'est ce que j'ai constaté auprès de tous ceux que je côtoie en tout cas. Sans même parler de la différence en quantité de code nécessaire pour atteindre le résultat, il est évident qu'un langage comme OCaml est plus productif. Ce qui ne signifie pas qu'il est toujours adapté, lorsqu'il y a d'autres contraintes sur le résultat (usage mémoire, performance pure, ...) ou qu'il y a déjà une bibliothèque en C qui n'a pas de bindings OCaml.

En Caml, le tableau est toujours modifiable, ce qui est une impureté. En Haskell, va voir ici :
http://www.cs.auckland.ac.nz/referen...ml/arrays.html

Je n'arrive pas à atteindre ce site, alors je vais donner la documentation de référence du Wiki Haskell. En gros un tableau fonctionnel doit aussi être immuable, mais ce n'est pas aussi restrictif qu'on pourrait le penser : d'une part grâce à l'évaluation paresseuse les tableaux Haskell sont très pratique pour faire de la programmation dynamique, d'autre part on n'est pas obligé de recopier la totalité du tableau pour le "modifier". Bien sûr Haskell a aussi des tableaux "classiques" (mutables) utilisables dans les monades IO ou ST (rappelons qu'une monade ST est pure vu de l'extérieur).

--
Jedaï

[GnuVince]

J'aimerais parler de la récursivité. Beaucoup de gens associent la récursivité à la programmation fonctionnelle. C'est vrai que c'est utilisé fréquemment, les listes se portent bien à ce type de manipulation, et ça permet d'éviter les side effects. Par contre, l'utilisation de combinateurs (map, fold_left, filter, etc.) est un aspect plus important (j'irais même jusqu'à dire, le plus important) de la programmation fonctionnelle.

Dans un langage impératif tel que le C, appliquer une fonction à une liste d'éléments a un idiome bien connu:

Code :

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

1
2
3
for (i = 0; i < LENGTH; ++i)
    a[i] = func(a[i]);

Dans les langages fonctionnels (et certains langages impératifs, on doit le mentionner), ce "pattern" est la fonction map:

Code :

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

1
2
(map func my-list)

La différence est que dans le premier cas, on parcourt explicitement le tableau, on a donc besoin d'informations supplémentaires: est-ce que les tableaux sont indexés à partir de 0 ou 1 et la longueur du tableau. On boucle également du début à la fin du tableau. Dans le cas de la fonction map, ces détails sont abstraits, on ne sait pas (et on s'en fout) si la liste est indexée à parti de 0 ou 1, on a pas besoin de connaître la longueur du la liste, on sait pas si l'application de func à chaque élément va se faire de gauche à droite, de droite à gauche, au hasard, etc. On cache donc des détails d'implémentation qui n'ont pas rapport à la tâche à exécuter.

[DarkVenoM]

La différence est que dans le premier cas, on parcourt explicitement le tableau, on a donc besoin d'informations supplémentaires: est-ce que les tableaux sont indexés à partir de 0 ou 1 et la longueur du tableau. On boucle également du début à la fin du tableau. Dans le cas de la fonction map, ces détails sont abstraits, on ne sait pas (et on s'en fout) si la liste est indexée à parti de 0 ou 1, on a pas besoin de connaître la longueur du la liste, on sait pas si l'application de func à chaque élément va se faire de gauche à droite, de droite à gauche, au hasard, etc. On cache donc des détails d'implémentation qui n'ont pas rapport à la tâche à exécuter.

Oui mais List.map n'est pas récursif terminal

En Caml, le tableau est toujours modifiable, ce qui est une impureté. En Haskell, va voir ici :
http://www.cs.auckland.ac.nz/referen...ml/arrays.html

C'est ce que j'ai dit on trouve tout et son contraire sur le net, dans le doute je fais confiance a mes prof ^^

[gorgonite]

C'est ce que j'ai dit on trouve tout et son contraire sur le net, dans le doute je fais confiance a mes prof ^^

c'est rarement une bonne idée...

[DarkVenoM]

Parce que, d'une part, les langages fonctionnels ne sont pas l'ultime panacée et les langages impératifs ont leurs places

C'est exactement ce que je voulais entendre .
D'ailleurs a lire les derniers message le F# aurait tout pour cartonner (il a la lib .NET avec lui) apres, ses utilisateurs ne vont pas forcément se mettre a programmer en fonctionnel pur, mais ils pourront peut etre mélanger les paradigmes selon leur besoin.

Ben, trouve-nous une idée révolutionnaire qui fasse que tout le monde ait besoin de ces langages.

Le probleme est justement là, aujourd'hui a par quelques domaines bien précis (preuve, compilation, et éventuellement parrallelisme etc..), le fonctionnel a du mal a montrer ses avantages par rapport a l'impératif. Il n'est pas impossible que l'avenir me fasse mentir, mais je vois mal la situation changer dans les prochains mois

[Jedai]

Oui mais List.map n'est pas récursif terminal

Et alors ?

C'est ce que j'ai dit on trouve tout et son contraire sur le net, dans le doute je fais confiance a mes prof ^^

c'est rarement une bonne idée...

Je plussoie, c'est très rarement une bonne idée même quand tu les aimes bien, une dose de scepticisme ne fait jamais de mal... Surtout que tes cours sur le fonctionnel n'ont pas l'air de t'avoir enthousiasmé plus que ça.

D'autant que la source que je t'ai donné est directement sur le Wiki officiel d'Haskell et est plutôt substantielle, il y a une différence entre une phrase entraperçue au détour d'un slide et une documentation complète et vérifiable sur l'usage des tableaux en Haskell.

--
Jedaï

[DarkVenoM]

À ce sujet, on aime bien faire référence au discours de Tim Sweeney, célèbre programmeur du jeu vidéo (Unreal Engine...), qui expose les avantages qu'auraient une intégration de langages fonctionnels dans son industrie : The Next Mainstream Programming Language : A Game's Developper Perspective.

Il y expose aussi certains défaut d'un langage fonctionnel dans son industrie... morceau choisi : "The syntax is ... scary" dans la partie finale "Why Haskell is not my favorite programming language", ça m'étonnerait qu'il préfere la syntaxe du lisp (je me trompe peut etre)...

Je plussoie, c'est très rarement une bonne idée même quand tu les aimes bien, une dose de scepticisme ne fait jamais de mal... Surtout que tes cours sur le fonctionnel n'ont pas l'air de t'avoir enthousiasmé plus que ça.


Jedaï

Ah d'accord, donc si j'avais eu des bon cours données par des bon prof, alors j'aurais comme vous tous adoré la sacro sainte programmation fonctionnelle.

Et alors ?

Et alors ? Ben comme moi tu connais un peu la programmation fonctionnelle (peut etre plus que moi d'ailleurs), tu sais qu'elle interdit les boucle et que de ce fait elle encourage la récursivité. La récursivité est réputé plus lente que les boucles (d'ou la réputation de lourdeur des langages fonctionnelles) parce qu'a chaque appel la pile s'agrandit. Ce n'est justement pas le cas avec des fonctions récursives terminales ou la rapidité d'execution est a peu pres la même qu'une bonne vieille boucle. En gros ce que tu gagne en concision tu le perd en performance. Apres on a pas tout le temps besoin d'avoir des programmes super performant mais le surplus syntaxique d'une boucle for par rapport a un List.map compense selon moi la différence de performance.

[Jedai]

Il y expose aussi certains défaut d'un langage fonctionnel dans son industrie... morceau choisi : "The syntax is ... scary" dans la partie finale "Why Haskell is not my favorite programming language", ça m'étonnerait qu'il préfere la syntaxe du lisp (je me trompe peut etre)...

Je n'ai pas dit que la syntaxe n'était pas différente, mais comprend bien que Tim Sweeney cherche ici à établir les caractéristiques d'un futur langage de programmation mainstream, comme il dit un tel langage "Must not scare away mainstream programmers.". Il souligne également à plusieurs reprise dans cet article qu'Haskell a déjà beaucoup des caractéristiques qu'il recherche. En fait c'est bien pour ça qu'à la fin il doit préciser quels sont les problèmes d'Haskell dans sa perspective (problèmes réels).

Ah d'accord, donc si j'avais eu des bon cours données par des bon prof, alors j'aurais comme vous tous adoré la sacro sainte programmation fonctionnelle.

Peut-être pas, mais peut-être aurais-tu plus apprécié les avantages du fonctionnel, note que l'un des point important pour Sweeney est que le défaut doit être le fonctionnel, avec possibilité d'introduire de l'impératif, pas l'inverse....

Et alors ? Ben comme moi tu connais un peu la programmation fonctionnelle (peut etre plus que moi d'ailleurs), tu sais qu'elle interdit les boucle et que de ce fait elle encourage la récursivité. La récursivité est réputé plus lente que les boucles (d'ou la réputation de lourdeur des langages fonctionnelles) parce qu'a chaque appel la pile s'agrandit. Ce n'est justement pas le cas avec des fonctions récursives terminales ou la rapidité d'execution est a peu pres la même qu'une bonne vieille boucle.

Sauf que dans le cas de map, les appels peuvent être optimisés également, pour obtenir une rapidité quasiment identique à celle d'une boucle for() (excepté qu'on travaille avec une liste chaînée, pas avec un tableau), bien que vérification faite, OCaml ne le fasse pas (Haskell le fait par contre). La récursivité terminale n'est pas la seule astuce pour compiler du code fonctionnel efficacement.

--
Jedaï