Discussion :

[LLB]

Comment faire un choix entre deux familles ou deux de ces langages ? Quels-sont les avantages/inconvénients les uns par rapport au autres ?

Lisp est quand même à part : il est dynamique. Considère-le comme l'équivalent fonctionnel des langages de script Ruby/Perl/Python.

D'autres part, Impur veut dire que le paradigme n'est pas 100% respecté et que le langage comporte des fonctionnalités pouvant induire des effets de bord, c'est ça ?

Oui.

Dans ce cas, quels avantages apportent ces langages impurs ?

C'est moins contraignant, puisque tu peux mélanger les paradigmes. Mais en gros, ML et Haskell peuvent servir pour les mêmes besoins, c'est une question de gout (je n'ai jamais utilisé Haskell sur un gros projet, je laisse quelqu'un d'autre en parler).

Avec mes maigres connaissances du fonctionnel, j'ai l'impression de pouvoir imiter en C# (3.0) beaucoup de spécificités de F# par exemple. (Démo sur demande )

C'est ce que je disais plus haut pour le C++ : tu peux souvent imiter des fonctionnalités, mais en perdant beaucoup d'avantages (notamment, clarté et concision). Je pourrais aussi répondre que je peux imiter beaucoup de spécificités de C# avec F#, en tapant 2 fois moins de code et en aillant plus de sûreté (cf réponse de Jean-Marc).

En gros :
- inférence de type (C# n'en fait que le dixième)
- types somme
- pattern matching
- évaluation paresseuse
- définition d'opérateurs, syntaxe basée sur l'indentation
- méta-programmation. Par exemple, Linq n'est qu'un cas particulier d'un mécanisme bien plus générique de F# (il est/sera donc possible de générer d'autres langages que du SQL avec cette technique).
- active patterns
- compréhensions de listes, de séquences
- expressions monadiques
- classes anonymes, méthodes d'extension (ok, C# l'a déjà piqué)

Mais surtout, F# est fonctionnel. Là où C# te recommande fortement l'impératif, F# t'incite à utiliser du fonctionnel. C'est surtout la philosophie du langage qui est différente. C# est basé sur la notion d'instructions (une méthode est une liste d'instructions), alors F# est conçu sur le concept d'expressions (une fonction est une expression). S'il y a besoin que je détaille des points, ou si tu veux comparer C# et F#, on peut le faire dans un autre thread.

[Keihilin]

Je te remercie pour cette réponse...

C'est vraiment un sujet intéressant, et je souhaiterais vraiment trouver le temps de me mettre à F#, ne serait-ce que par curiosité intellectuelle car dans mon domaine (informatique de gestion, systèmes d'informations, banques et compagnie...), j'ai du mal à trouver des justifications techniques qui permettraient d'introduire du fonctionnel. En ce sens, l'intégration de F# avec .Net est certainement un gros avantage...

Puisqu'on parlait d'imitation, il me paraît clair que cela marche dans les deux sens et que l'on peut toujours tenter de reproduire des fonctionnalités; mais je me pose naturellement la question des performances...

Exemple idiot : créer un tableau des nombres naturels de 1 à 20.

En C# on ferait :

Code :

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

1
2
3
4
int[] a = new int[20];
for (int x = 0; x < a.Length; x++)
  a[x] = x + 1;

Alors qu'en F# on peut faire :

Code :

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

1
2
let a = Array.init 20 (fun x -> x + 1)

Je suis d'accord pour dire que la syntaxe F# est particulièrement concise, mais est-ce qu'il s'agit-là d'un simple sucre syntaxique ? Est-ce qu'au final le code F# est moins/aussi/plus rapide que le C# ?

et si l'on va plus loin et qu'on utilise C# pour imiter F# :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static class ArrayF
{
  public delegate T CreateItem<T>(int index);
 
  public static T[] Create<T>(int length, CreateItem<T> createItem)
  {
    if (length < 0)
      throw new ArgumentOutOfRangeException("length");
 
    if (length == 0)
      return new T[0];
 
    T[] result = new T[length];
    if (createItem != null)
    {
      for (int i = 0; i < length; i++)
        result[i] = createItem(i);
    }
    return result;
  }
}

du coup on peut faire ça en C# :

Code :

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

1
2
var a = ArrayF.Create(20, x => x + 1);

et on a du F#like en C# Mais encore une fois, quel impact sur les perfs ?

[gorgonite]

dans mon domaine (informatique de gestion, systèmes d'informations, banques et compagnie...), j'ai du mal à trouver des justifications techniques qui permettraient d'introduire du fonctionnel. En ce sens, l'intégration de F# avec .Net est certainement un gros avantage...

au contraire, en fonctionnel typé statiquement il est possible de construire des types si précis qu'on peut détecter de nombreux bugs dès la compilation... ce qui est intéressant pour respecter à coup sûr des protocoles complexes

[Keihilin]

au contraire, en fonction il est possible de construire des types si précis qu'on peut détecter de nombreux bugs dès la compilation... ce qui est intéressant pour respecter à coup sûr des protocoles complexes

Attention, je ne dis pas qu'il n'existe pas de justifications techniques en faveur de l'introduction du fonctionnel dans ces domaines, c'est juste moi qui ai de la peine à les définir, à les imaginer en pratique et à les transmettre.

[LLB]

Code :

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

let a = Array.init 20 (fun x -> x + 1)

Personnellement, j'écris plutôt :

Code :

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

[|1..20|]

Et tu auras du mal à faire ça avec C#.

Et sinon, oui, C# gère maintenant les fonctions anonymes de façon correcte (C#2 ou C#1 avait des syntaxes assez verbeuses), et permet de faire des fonctions d'ordre supérieur. On remarque quand même que ces mécanismes restent peu utilisés dans C# (la preuve, tu as dû recoder la fonction d'init).

Donc, oui, tu peux faire une bibliothèque en C# pour simuler quelques fonctionnalités de F#. Si tu ne veux pas tout refaire, je te conseille d'utiliser directement la bibliothèque standard de F# avec C#. Mais si tu veux aller plus loin (F# ne se résume pas aux fonctions d'ordre supérieur), je te conseille d'utiliser F# (ou Nemerle, qui assez intéressant aussi). Regarde les autres fonctionnalités que j'ai citées : tu auras du mal à les simuler de façon élégante.

D'ailleurs, ton code le montre bien : C# t'oblige quasiment à faire des effets de bord. Tu souhaitais juste avoir un tableau, dans l'absolu, pourquoi aurais-tu besoin de modifier des variables ? Quand tu déclares un entier, tu peux lui donner directement sa valeur (sans faire d'effet de bord). Par défaut, on ne peut pas faire la même chose avec un tableau, c'est dommage.

Quelques remarques en lisant ton code, vu que c'est typique de ce qu'on fait en impératif :

1. "createItem != null". Tiens ? Null est une fonction valide ? Heureusement que tu as pensé le cas, pour éviter une exception. Mais dans certains cas, une valeur null peut être le signe d'une erreur : en effet, si on ne souhaitait pas initialiser le tableau, il aurait été plus simple de ne donner que la taille en argument. En gérant l'argument null, tu transformes peut-être une faute dans le code en erreur silencieuse.
2. "i++". Un effet de bord.
3. "i < length". Si tu te trompes sur les bornes, que se passe-t-il ? Soit, tu dépasses, tu as une exception à l'exécution. Soit, tu ne vas pas assez loin et tu as une valeur non initialisée. Cette valeur peut devenir par la suite, soit une erreur silencieuse ("tiens, que fait ce 0 ? je n'ai jamais parlé de 0 dans mon code"), soit une exception (null pointer...)
4. "result[i] =". Un autre effet de bord.

Concernant les performances, les benchmarks que j'ai vus donnent des résultats plutôt bons pour F# (sous Windows, c'est le même ordre de grandeur que pour Caml ou C#).

http://strangelights.com/blog/archiv...6/17/1588.aspx
http://cs.hubfs.net/forums/thread/3196.aspx

Pour l'exemple précis de l'initialisation, je n'en sais rien. Désassembler le code en IL n'aide pas ici. Il faudrait connaitre le fonctionnement du JIT pour pouvoir répondre.

Exemple idiot : créer un tableau des nombres naturels de 1 à 20.

Autre exemple idiot : créer l'ensemble des nombres naturels, et travailler dessus.

Code :

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

1
2
3
4
5
6
7
> let N = Seq.unfold (fun x -> Some (x, x+1)) 0;;
val N : seq<int>

> N |> Seq.map (fun x -> x * x)
    |> Seq.filter (fun x -> x % 3 = 0)
    |> Seq.take 10;;
val it : int list = [0; 9; 36; 81; 144; 225; 324; 441; 576; 729]

[Keihilin]

Code :

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

let a = Array.init 20 (fun x -> x + 1)

Personnellement, j'écris plutôt :

Code :

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

[|1..20|]

Et tu auras du mal à faire ça avec C#.

Ah ben oui, forcément

Si tu ne veux pas tout refaire, je te conseille d'utiliser directement la bibliothèque standard de F# avec C#.

Testé et approuvé ? Ca cohabite bien ?
Est-ce que tu peux classiquement (dans le sens, comme on mélangerait projets VB.Net et projets C#) utilisé un projet F# dans une solution composée de projets C# ?

Regarde les autres fonctionnalités que j'ai citées : tu auras du mal à les simuler de façon élégante.

C'est certain...et des fonctionnalités comme le pattern matching me font un peu saliver.
Maintenant, je serais vraiment curieux de voir le MSIL généré par F# avec ses spécificités et l'équivalent généré par C# avec des tentatives de simulation...

Autre exemple idiot : créer l'ensemble des nombres naturels, et travailler dessus.

Code :

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

1
2
3
4
5
6
7
> let N = Seq.unfold (fun x -> Some (x, x+1)) 0;;
val N : seq<int>

> N |> Seq.map (fun x -> x * x)
    |> Seq.filter (fun x -> x % 3 = 0)
    |> Seq.take 10;;
val it : int list = [0; 9; 36; 81; 144; 225; 324; 441; 576; 729]

ouais mais bon, personne n'a besoin de ce genre de code

En tout cas, merci pour tes réponses.

[Jean-Marc.Bourguet]

C'est ce que j'appelle un non-choix : ...

On ne peut pas discuter du choix de langage, si tu n'as pas réellement ce
choix.

Tu m'as l'air de tomber exactement dans le travers que j'avais prédit: les
critères qui vont dans le sens de ta préférence, ce sont des facteurs de
choix; les critères qui vont dans l'autre sens, c'est des facteurs de
non-choix.

Si ce n'est pas ça, c'est quoi avoir le choix pour toi? Ne pas avoir un
clair meilleur choix et choisir plus ou moins au hasard? (En fait pour mes
projets perso, la situation n'est pas aussi claire que tu le crois et seule
l'histoire récente fait pencher la situation en faveur de C++ plutôt qu'Ada;
et il suffirait que je décide de tester un langage fonctionnel typé
statiquement -- j'ai quand même pas mal de lisp à mon actif -- sur quelque
chose d'autres que les petits exemples utilisés pour explorer les langages
pour que j'en fasse un en Haskell)

Le terme n'est peut-être pas très bien choisi (et peut prêter à
discussion), mais je vais expliquer ce que je voulais. Selon Wikipedia, un
langage de haut-niveau « permet au programmeur de s'abstraire de détails
inhérents au fonctionnement de la machine ».

Je suis d'accord avec cette définition.

Je crois que certains langages sont plus détachés que d'autres du
fonctionnement de la machine.

Ce n'est pas parce qu'on utilise un langage qui permet d'être proche de la
machine qu'on est obligé de le faire.

Le C++ ne m'offre peut-être pas autant d'abstractions de base que d'autres
langages. Mais sa capacité à travailler à plusieurs niveaux me permet de
me bâtir les abstractions dont j'ai besoin de façon efficace (la seule
chose qui manque est le GC -- contourner ce manque est souvent possible
mais parfois pénible -- mais l'absence de GC n'est pas une caractéristique
ontologique du C++ et en faire le critére déterminant d'un langage de haut
niveau me semble un peu réducteur). Et alors je travaille à aussi haut
niveau qu'avec n'importe quel autre langage.

Et la sûreté dans tout ça ?

Elle est moindre. Mais ça reste quand même l'équivalent plus proche qu'une
structure de classes.

Je crois que je suis globalement d'accord avec toi sur ce que sont les
avantages des langages fonctionnels. Simplement j'ai une autre évaluation
de leur importance.

Généralement, quand j'ai des problèmes de pointeurs, et qu'ils pointent
vers n'importe quoi, c'est qu'on a oublié de les mettre à jour, pas qu'il
fallait conserver l'objet qui a été supprimé. Et exactement le même bug
aurait lieu avec un langage sûr -- je le sais, j'en ai debuggé en Lisp et
c'est beaucoup plus pénible qu'en C++. Les autres cas sont plus rares et
peu problématiques dans ma pratique.

[Garulfo]

[...]
Généralement, quand j'ai des problèmes de pointeurs, et qu'ils pointent
vers n'importe quoi, c'est qu'on a oublié de les mettre à jour, pas qu'il
fallait conserver l'objet qui a été supprimé. Et exactement le même bug
aurait lieu avec un langage sûr -- je le sais, j'en ai debuggé en Lisp et
c'est beaucoup plus pénible qu'en C++. Les autres cas sont plus rares et
peu problématiques dans ma pratique.

Si je suis complètement d'accord avec la partie « j'en ai debuggé en Lisp et
c'est beaucoup plus pénible qu'en C++ », je ne comprends pas le problème en tant que tel. Comment en Lisp as-tu pu pointer sur n'importe quoi ? Je ne vois pas ce que tu veux dire.

[Jean-Marc.Bourguet]

Si je suis complètement d'accord avec la partie « j'en ai debuggé en Lisp et
c'est beaucoup plus pénible qu'en C++ », je ne comprends pas le problème en tant que tel. Comment en Lisp as-tu pu pointer sur n'importe quoi ? Je ne vois pas ce que tu veux dire.

L'absence de mise à jour en lisp -- ou dans n'importe quel langage à GC -- ne fait pas pointer vers n'importe quoi avec souvent des crash à la clef mais une possibilité de détection avec des outils comme purify mais fait pointer vers un objet valide, mais pas le bon, avec donc des comportements plus subtilement incorrects. Note que ça peut avoir des avantages dans certains contextes -- pas de trous de sécurité à exploiter par exemple.

Et note je suis plutôt pour les GC, mais ils ne sont pas une panacée universelle. Ils simplifient l'implémentation, pas l'analyse. En simplifiant l'implémentation, ils évitent des bugs, mais pas tous les bugs se manifestant par des problèmes de pointeurs, et ils en rendent encore plus difficiles à débugger les bugs qui sont déjà les plus pénibles à débugger. L'effet est globalement positif, mais il y a des aspects négatifs qui ne se résument pas simplement à une consommation de mémoire plus grande.

[GnuVince]

On m'a demandé de réécrire un commentaire que j'ai fait dans un autre thread, alors voilà:

Pour ceux qui s'ostinent (Québecois aussi) sur la programmation fonctionnelle vs programmation impérative, arrêtez: les deux paradigmes sont pas mutuellement exclusifs. Des langages fonctionnels tels que Scheme et O'Caml ont des moyens de modifier des variables, ont des boucles, etc. et les langages impératifs ont des moyens de créer des fonctions et des types de données récursifs, d'utiliser des fonctions comme data, etc. Utilisez ce qui est le mieux pour le problème que vous avez.

Pour les questions de "practicalité" des langages fonctionnels, voici mon opinion:

• Les compilateurs Stalin, Bigloo, SBCL, OCaml, GHC et j'en passe devraient avoir éliminé tout doute que les langages fonctionnels sont condamnés à être lents
• Certaines implémentations telles F#, Clojure, SISC visent la machine virtuelle .NET ou le JVM et ont accès à la tonne de modules déjà disponibles sur ces plateformes. Pas besoin de tout refaire à partir de zéro.
• Les langages fonctionnels ont été utilisé avec succès dans toutes sortes d'industries (on peut penser à Erlang en télécommunications par exemple) et les études menées sur ses projets ont montré que le produit final était écrit en moins de lignes de code et avaient moins de défaillance. Ce n'est pas pour dire qu'on ne peut pas atteindre un haut degré de fiabilité avec du impératif, mais il semblerait que l'effort nécessaire soit plus grand
• 2007 a semblé donné un souffle aux langages fonctionnels: le livre de Erlang est énormément populaire, Haskell a eu une nouvelle grosse version, des logiciels sont écrits dans des langages fonctionnels. 2008 risque de continuer sur la même lancée

Finalement, les langages fonctionnels sont le fun. Je suis entrain de passer au travers du livre "The Little Schemer", et j'ai un plaisir fou!

[Jean-Marc.Bourguet]

Il me semblait bien que j'avais lu quelque chose de pertinent quelque part:

http://homepages.inf.ed.ac.uk/wadler...ogramming.html

Ca a presque dix ans, mais les choses ont peu change (ce qui a change le plus, c'est que les VM et les GC sont de plus en plus répandus -- mais comme d'un point de vue industriel, .NET c'est quasiment reserve a Windows, ca aide moins qu'on pourrait le penser).

Pour ceux que les langages de programmation interessent, je n'avais pas trouve les mots cles pour me ramener au papier par Google jusqu'a ce qu'aujourd'hui je tombe sur ce custom search engine: http://www.cdiggins.com/search/ qui me l'a trouve sans probleme.

[souviron34]

MERCI

très intéressant...

Et je retiens (ce qui m'apparaît tout à fait raisonnable) le paragraphe autour de :

"...advocates promote functional and logic languages as general purposes, good for whatever ails you..".

Ce qui me semble une bonne vue (enfin pas ça, mais ce qu'il dit autour).

Et qui m'apparaît nettement plus fondée que l'attitude que j'ai vu ici précédemment (qui ferait plus partie de ces "avocats")..

Et ce que je disais un peu au début est apparent sur les points "négatifs" par rapport à l'industrie..

A suivre donc...

(mais conséquemment peut-être pas à utiliser maintenant).

[gorgonite]

MERCI
très intéressant...

+1000

et merci pour le lien vers ce moteur de recherche (que je ne connais pas )

[Garulfo]

L'absence de mise à jour en lisp -- ou dans n'importe quel langage à GC -- ne fait pas pointer vers n'importe quoi avec souvent des crash à la clef [...]

Euh.. tu voulais dire « fait pointer vers n'importe quoi » ?
Sinon je ne vois pas en quoi ça répond à ce que tu disais.
Mais tu ne parles pas d'une manipulation de l'utilisateur ?
Aurais-tu un exemple en bonne et due du forme.

Et qui m'apparaît nettement plus fondée que l'attitude que j'ai vu ici précédemment (qui ferait plus partie de ces "avocats")..

Si tu veux dire par là que ceux qui sont pour sont un peu aveuglément pour, je pense que ce n'est pas le cas ici. Du moins ce n'est pas comme ça que j'ai perçu les avis, ni comme cela que j'ai écris le mien. Est ce comme cela que tu les as perçus ?

[Jedai]

A suivre donc...

(mais conséquemment peut-être pas à utiliser maintenant).

Ca a presque dix ans

Peut-être alors que s'il ne fallait pas l'utiliser "maintenant" il y a dix ans, il serait temps de s'apercevoir que certaines choses ont changé ? En particulier la viabilité des implémentations ?

Ce qui n'a effectivement pas changé c'est le problème des bibliothèques et des outils, d'un autre côté, ce n'est pas en attendant encore dix ans que ceci va magiquement s'améliorer... Il faut bien commencer quelque part.

Et je ne me rappelle pas avoir dit que les langages fonctionnels étaient parfait pour toutes les applications, en fait j'ai dit explicitement :

bien que le paradigme impératif ait tout à fait sa place

Autrement dit, il y a bien tout une catégorie d'application où l'impératif est préférable.
L'essentiel de ce que j'ai dit est que tes contres-arguments étaient ridicules et trahissait ta méconnaissance complète du domaine : tu ne savais même pas ce que voulais dire "fonctionnel" au début de la discussion, et tu n'as pas commencé par t'informer...

Quelques documents intéressants :
Le dernier rapport du CUFP (Commercial Users of Functional Programming).
Une étude comparative du DOD.
...

--
Jedaï

[souviron34]

Ca a presque dix ans

Peut-être alors que s'il ne fallait pas l'utiliser "maintenant" il y a dix ans, il serait temps de s'apercevoir que certaines choses ont changé ? En particulier la viabilité des implémentations ?

bah C99 a presque 10 ans et n'est pas encore implanté partout...

D'ailleurs, je trouve que le cycle de Fortran (20 ans d'avance : dans 10 ans ces fonctions/variables deviendront non recommandées, dans 20 ans obsolètes) est beaucoup plus mûr pour du développement industriel..

Ce qui n'a effectivement pas changé c'est le problème des bibliothèques et des outils, d'un autre côté, ce n'est pas en attendant encore dix ans que ceci va magiquement s'améliorer... Il faut bien commencer quelque part.

Oui, mais justement. C'est je pense ce qui fait considérer tout ça comme encore très académique...

L'essentiel de ce que j'ai dit est que tes contres-arguments étaient ridicules et trahissait ta méconnaissance complète du domaine : tu ne savais même pas ce que voulais dire "fonctionnel" au début de la discussion, et tu n'as pas commencé par t'informer...

je répondais à tes affirmations de l'époque (et dans un autre fil également) que "pourquoi ne pas conseiller Haskell aux débutants", en gros.. Et que les langages impératifs étaient "dépassés".. Que c'était la panacée...

Quelques documents intéressants :
Le dernier rapport du CUFP (Commercial Users of Functional Programming).
Une étude comparative du DOD.

Merci pas le temps en ce moment (Nouel ), mais je regarderais ça..

[ptah35]

Bonjour à tous,

Je suis nouveau dans ce forum et j'ai parcouru plusieurs fils avec intéret. Bien que mon expérience se limite essentiellement à quelques langages impératifs - C, C++, VB6 et C# -, j'ai toujours eu un intéret pour la programmation fonctionnelle. Ainsi, quelque soit le language, je m'applique à programmer dans un style fonctionnel et j'ai, depui peu, ajouter F# à ma boîte à outils.

Je pense que je comprends assez bien les avantages des languages fonctionnels, mais est-ce que le débat fonctionnel contre impératif ne serait pas plutôt un débat opposant typage statique et typage dynamique, et mémoire gérée et mémoire non gérée.

En effet, je constate qu'on oppose volontier le C et C++ à OCml ou à Haskell.

Le C et le C++ sont en principe statiquement typé, mais sont système de type est si faible que nous passons notre temps à dire au compilateur quelle structure référence tel ou tel pointeur sans qu'il ait les moyens de le vérifier. De plus, l'allocation et la libération de la mémoire sont la responsabilité du programmeur et on ne pas dire que la bibliothèque standard de C soit un modèle de cohérence à ce niveau.

D'un autre côté OCml et Haskell ont un typage statique très fort, et le programmeur n'a pas la responsabilité de la gestion de la mémoire.

A la vue de ces éléments, je me demande si le guain de productivité est réellement dû à l'utilisation d'un language fonctionnel, ou plutôt à l'utilisation d'un language fortement typé et d'un "garbage collector".

Bien à vous,
Jérôme

[DarkVenoM]

Je me permet de donner mon avis sur le sujet je suis étudiant et au cours de mon parcours j'ai eu deux enseignements (durant tout un semestre chacun) sur la programmation fonctionnelle.
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. En programmation fonctionnelle, on privilégie la récursivité l'usage d'un garbage collector. Alors oui dans certains cas la programmation fonctionnelle a de gros avantages, mais la plupart du temps ils sont limités par rapports a des langages impératifs.

La pluparts des étudiants qui ont suivi des cours de programmation fonctionnelles ne deviennent pas des fans de la programmation fonctionnelles bien qu'ils ait assimilé la plupart des concepts clé. Même pour les prof de ma fac, la programmation fonctionnelle ne fait pas l'unanimité (loin de là...).Aussi je pense que si la programmation fonctionnelle (pur ou a dominante fonctionnelle) devait supplanter la programmation impérative elle l'aurait déja fait... Le lisp existe depuis bien longtemps et si les concepts de la programmation impératives ne sont pas tout jeunes, ceux de la programmation fonctionnelle ne datent pas d'hier... Si la programmation fonctionnelle apportait un gain réel a la fois en performance (temps d'execution) ,en productivité, tout en gardant un code relativement facile à comprendre, par rapport la programmation impérative, plus personne ne ferait de Java, de C# ou de PHP.

Pour moi la programmation fonctionnelle pur (en tant que paradigme) n'a pas vraiment d'avenir, par contre certains concepts de la programmation fonctionnelles ont eux un avenir... Dans des langages impératifs. C'est justement ce que je souhaite, qu'au fil du temps les fonctionnalités vraiment intéréssantes de certains langages fonctionnelles (purs ou impurs) soient intégrés dans des langages impératifs C-like, ça commence a etre le cas avec boost (fonction lambda...), en C# et en F# (a noter que Microsoft (pourtant pas le plus grand ami des ayatollah de la programmation fonctionnelle...) est le seul géant de l'industrie informatique a s'intérésser vraiment a des fonctionnalités des langages fonctionnelles (certes impurs).

Moi même j'ai fait du c, du c++, du java, du php, du lisp, de l'ocaml, et mon choix (pas ma contrainte) se porterait plus vers le c++, quite à utiliser lorsque c'est possible un langage fonctionnelle quand c'est vraiment utile.

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

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...

L'utilisation du « = » leur pose plein de problème... Ahhhh si C avait eu l'intelligence d'écrire « := » ça serait tellement mieux -_-[/LIST]

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é.

À 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.

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) ?

[GnuVince]

A la vue de ces éléments, je me demande si le guain de productivité est réellement dû à l'utilisation d'un language fonctionnel, ou plutôt à l'utilisation d'un language fortement typé et d'un "garbage collector".

Bien à vous,
Jérôme

Non, car il existe des langages fonctionnels qui ne sont pas typés statiquement: Erlang et Scheme par exemple. Pourtant, ils ont une meilleur productivité que le C ou le C++.

La raison est pas le typage, mais l'expressivité. On peut dire de façon concise (mais lisible!) les choses dans des langages fonctionnels et c'est grace à des fonctionnalités, en particulier les fonctions de première classe, qu'on peut faire celà.

[LLB]

Testé et approuvé ? Ca cohabite bien ?
Est-ce que tu peux classiquement (dans le sens, comme on mélangerait projets VB.Net et projets C#) utilisé un projet F# dans une solution composée de projets C# ?

L'interopérabilité est plutôt pas mal, d'après ce que j'ai lu (ça fait partie des objectifs). Mais je n'ai pas fait de test approfondi.

Maintenant, je serais vraiment curieux de voir le MSIL généré par F# avec ses spécificités et l'équivalent généré par C# avec des tentatives de simulation...

Un type somme se compile comme une hiérarchie de classes (un type somme est vraiment un objet et peut d'ailleurs avoir des méthodes). Le nom du type somme devient une classe abstraite et chaque constructeur du type est une classe.

S'il n'a aucun argument, dans ce cas c'est un enum.

Et quand le type somme est mixte (constructeur avec arguments et sans argument), le compilateur insère des statiques pour ne jamais dupliquer les valeurs sans argument.

Pour le pattern matching, ça dépend du type. Sur un enum ou sur un int, c'est directement un switch. Sinon, c'est une succession de if/goto assez moche. Il teste dynamiquement la classe (en IL : isinst) et fait du cast s'il doit tester (ou récupérer) une valeur.

Et oui, le code généré est assez long. Ca vient surtout du fait que F# génère automatiquement plein de méthodes : CompareTo, GetHashCode, Equals, etc. Il génère aussi des méthodes pour que les développeurs C# puisse manipuler le type somme.

Tu m'as l'air de tomber exactement dans le travers que j'avais prédit: les critères qui vont dans le sens de ta préférence, ce sont des facteurs de
choix; les critères qui vont dans l'autre sens, c'est des facteurs de
non-choix.

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 ; ou on veut garder une compatibilité forte avec un ancien code), et il y a des critères qui restent ouverts (par exemple, ne pas vouloir de garbage collector ; ne pas vouloir de typage dynamique ; etc.). C'est seulement avec ces derniers critères que l'on peut parler vraiment de choix (puisqu'il reste plusieurs langages possibles). Mais je crois que l'on tourne en rond ici.

En fait pour mes projets perso, la situation n'est pas aussi claire que tu le crois et seule l'histoire récente fait pencher la situation en faveur de C++ plutôt qu'Ada

D'accord.

Le C++ ne m'offre peut-être pas autant d'abstractions de base que d'autres langages.

Voilà. C'est de ce point que je parlais.

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é).

Généralement, quand j'ai des problèmes de pointeurs, et qu'ils pointent vers n'importe quoi, c'est qu'on a oublié de les mettre à jour

C'est peut-être de la chance, mais je n'ai jamais rencontré le moindre problème avec un GC, 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).

mais est-ce que le débat fonctionnel contre impératif ne serait pas plutôt un débat opposant typage statique et typage dynamique, et mémoire gérée et mémoire non gérée.

Non : j'ai évoqué C# et Java. Les allusions à Python/Ruby/Perl/.. sont faibles (ces langages doivent être opposés à Lisp).

Le C et le C++ sont en principe statiquement typé, mais sont système de type est si faible que nous passons notre temps à dire au compilateur quelle structure référence tel ou tel pointeur sans qu'il ait les moyens de le vérifier.

Non !
C a un typage faible, mais pas dynamique. Si tu évites les cast et les void* tant que possible, tu n'as pas trop de problème de ce côté là.

C++, quand l'utilise correctement, a un typage fort. Les références, les templates, etc. sont bien vérifiées à la compilation.

A la vue de ces éléments, je me demande si le guain de productivité est réellement dû à l'utilisation d'un language fonctionnel, ou plutôt à l'utilisation d'un language fortement typé et d'un "garbage collector".

Compare C# 2 et F#. Compare Caml et Java.
La différence est réelle.

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.

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.

La pluparts des étudiants qui ont suivi des cours de programmation fonctionnelles ne deviennent pas des fans de la programmation fonctionnelles

En général, c'est parce que le paradigme a mal été compris, que la logique n'a pas été assimilée. Dans mon école, le fonctionnel servait comme introduction à la programmation et à l'algorithmique. J'ai mis beaucoup de temps à comprendre l'intérêt du fonctionnel en lui-même (j'ai vraiment compris plus tard, après avoir fait du C++), et je sais que beaucoup ne l'ont jamais compris. Je crois que le problème vient de l'enseignement : le but était d'expliquer l'algorithmique, et non le fonctionnel.

a noter que Microsoft (pourtant pas le plus grand ami des ayatollah de la programmation fonctionnelle...) est le seul géant de l'industrie informatique a s'intérésser vraiment a des fonctionnalités des langages fonctionnelles (certes impurs).

Il y a pas mal de papiers de MS Research traitant du fonctionnel. Selon certains, Excel est d'ailleurs un langage fonctionnel. Dans le groupe "Programming Principles and Tools" de MS Research Cambridge, le fonctionnel est très représenté : http://research.microsoft.com/ppt/

Et pour le fonctionnel pur : regarde du côté de Haskell. Renseigne-toi sur GHC, Simon Marlow et Simon Peyton Jones.

sa syntaxe est contre intuitive :
5 + 3 en C s'écrirait (+ 5 3) en lisp...

Il est dur d'imaginer un langage avec une syntaxe plus simple que celle de Lisp. Pour l'arithmétique, on s'y habitue très vite.

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) ?

Relis la discussion. Il y a plein d'arguments qui t'ont échappé, visiblement.