Discussion :

[gorgonite]

Une question que peut se poser pas mal de monde :
y a-t-il un style de programmation plus "naturel" ?

en gros, l'impératif étant apparu en premier, a-t-il eu le monopole de fait, ou est-il plus simple à appréhender ?

[Garulfo]

Je ne pense vraiment pas que l'évaluation paresseuse soit un plus pour apprendre l'informatique : ce n'est tout simplement pas naturel. L'homme raisonne naturellement de façon stricte, avec effets de bords, du moment que l'on convient que la machine possède une mémoire dont on peut en modifier l'état, et il est ainsi naturel d'écrire des boucles, des affectations et autres.

Ça j'attends des preuves
Car jusqu'à preuve du contraire, personne ne sait comme l'humain raisonne naturellement. Et personne ne peut dire si la programmation impérative est plus naturelle ou moins naturelle qu'une purement fonctionnelle. Je te ferais remarquer qu'en mathématique c'est du purement fonctionnel qu'on nous enseigne. Par exemple, je doute que tu n'ais jamais vu une seule fois l'équivalent d'un traitement itératif en math ou d'une modification de la valeur d'une variable ?

Il semblerait que c'est souvent le premier langage qui défini ce qui semble « naturel. » Mais encore là, rien n'est vraiment établi sur des bases solides.

[gasche]

J'ai l'impression qu'il y a un amalgame dans votre discussion entre ce qui le choix "strict ou lazy ?" et le choix "fonctionnel ou impératif ?".

InOCamlWeTrust : Ce que tu dis est intéressant, mais le ton que tu emploies est parfois un peu pénible pour l'interlocuteur. Garulfo n'est pas d'accord avec toi, mais ce n'est pas la peine d'être autant sur la défensive. Je pense que tes posts profiteraient beaucoup d'un peu de mesure dans le propos.

Si on convient que le but de l'algorithmie est de mettre en oeuvre des procédés, on entre naturellement dans une logique impérative

Cela me semble juste. Mais la description est là à ta convenance, tu parles de "mettre en oeuvre".
Justement, on peut voir dans la programmation dite "déclarative" (à plus ou moins grande échelle) un point de vue différent sur ce que sont les algorithmes.
Là où le programme impératif "mettra en oeuvre" comme tu dis, le programme déclaratif "décrira" le processus choisi. Je ne vois pas en quoi la deuxième méthode est moins naturelle que la première, et je ne pense donc pas que les algorithmes soient par nature plus liés à l'impératif qu'à un autre mode de programmation.

Exemple de procédé : aller à l'école.

En impératif ça donnerait une chose comme...
- se lever
- prendre son petit déjeûner
- sortir de chez soi
- emprunter le chemin en passant par certains point habituels
- rentrer dans l'établissement

... en fonctionnel, c'est-à-dire en regardant le problème sous l'aspect données et non nécessairement sous l'aspect enchaînement des calculs, je doute que ça soit aussi clair et simple...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
let ( --> ) garçon action = action garçon
let agir acte garçon = garçon ^ ",  " ^ acte

let lever = agir "je me lève"
and dejeuner = agir "je déjeune"
and sortir = agir "je sors"
and aller_ecole = agir "je vais a l'école"

let () =
  let garcon = "le matin" in
  let matin = garcon --> lever --> dejeuner --> sortir --> aller_ecole in
  print_endline matin

C'est loin d'être parfait, mais ça montre bien que la notion de ce qui est "naturel" n'est pas si claire. Par ailleurs, contrairement à un point de vue impératif du processus que l'on décrit, ma méthode (ou du moins l'idée de ma méthode, la mise en oeuvre étant un peu minables) a quelques avantages indéniables, en particulier le principe de persistence : on peut toujours avoir accès au garçon qui a déjeuné, mais n'est pas encore sorti. Utile si un gros crash du monde pendant la phase "sortie" a corrompu les données de ce pauvre écolier.

Pourquoi crois-tu que les langages les plus utilisés dans l'industrie sont impératifs ?

Pourquoi crois-tu que le système d'exploitation le plus utilisé est Windows ? Il est fondamentalement "plus naturel" ?
Ce n'est pas une bonne argumentation.

Par ailleurs, de nombreuses personnes souhaitent que les programmeurs de l'industrie utilisent plus d'idées issues des langages fonctionnels. Si tu n'a jamais lu http://www.st.cs.uni-sb.de/edu/semin...ocs/sweeny.pdf , je te le conseille, c'est un programmeur de jeux vidéos qui parle des besoins de son industrie en matière de langages de programmation.

Ca n'a aucun sens : les mathématiques ne sont pas un langage de programmation, et même pas un langage tout court.

Il y a plusieurs langages en mathématiques, ça me semble un peu dangereux de faire des affirmations absolues comme ça. De toute manière le fait de savoir si les mathématiques sont ou non un langage n'est pas vraiment nécessaire à votre débat.

Par ailleurs, il me semble que l'argument de Garulfo mérite tout de même d'être étudié : pour progresser en mathématiques on utilise tout un tas de formalismes (voire de "langages) différents, mais le fait est que je n'ai absolument jamais vu d'objet ou de concept "mathématique" utilisant des effets de bords. On a donc un bon exemple de manipulations complexes, solides (on fait des mathématiques depuis longtemps, on peut penser que les méthodes utilisées sont éprouvées (ce qui ne veut pas dire qu'elles n'évolueront plus)), qui ne sont pas du tout impératives.

du genre l'existence de Dieu !

Bonne chance pour "constater et expérimenter" ^^

[gasche]

Non, on n'est pas obligé de voir comme ça. On peut dire (je m'occupe que du cas général, pas du cas d'arrêt) :
soient 'hd' le premier élément de la liste et 'tl son reste, alors la liste triée est la concaténation de tous les éléments plus petits que hd, triés, de hd, et de tous les éléments plus grands que hd, triés.

On n'a pas "choisi" un pivot, on a "vu" la liste comme un pivot et une suite; on n'a pas "découpé" la liste, on a déclaré deux nouveaux objets (qui correspondent au résultat de ta découpe). Par contre on applique une fonction aussi, mais ça ce n'est pas spécialement impératif :p

Code :

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

1
2
3
4
5
6
let rec qsort = function
  [] -> []
| [x] -> [x]
| pivot :: reste_liste ->
  let petits, grands = List.partition (fun element -> element <= pivot) reste_liste in
  qsort petits @ [pivot] @ qsort grands

Ça me semble tout aussi naturle comme approche. C'est peut-être moins naturel pour toi (je ne sais pas), mais ça ne m'a pas l'air clairement ni plus ni moins naturel dans l'absolu.
Je pense que là on rentre dans ce que Garulfo disait très bien, « Il semblerait que c'est souvent le premier langage qui défini ce qui semble "naturel". »

[Garulfo]

[...]
Pourquoi crois-tu que les langages les plus utilisés dans l'industrie sont impératifs ?

Pas parce que c'est plus naturel. La raison est historiquement que ceux ci pouvaient se compiler efficacement. Après c'est une question d'inertie de l'industrie. Avant d'avancer ce genre d'argument tu aurais dû te renseigner un peu plus

Comme je te l'ai dis, je te mets au défi de trouver des articles établissant sérieusement que les langages impératifs sont plus naturels.

[...]
Combien de programmes et d'algorithmes as-tu écrit en mathématiques ?

Ca n'a aucun sens : les mathématiques ne sont pas un langage de programmation, et même pas un langage tout court.

Encore une erreur de ta part. On peut programmer avec des mathématiques. Le lambda-calcul, les algèbres de processus, la théorie des ensembles (finies certes) servent à ceci. Certes tu vas me dire que ce sont des langages de programmation qui utilisent des mathématiques. Exact. Mais tu utilises donc des concepts mathématiques directement pour programmer. N'oublies pas que ce sont les mathématiciens qui ont fait l'informatique... et que d'ailleurs à ce moment ça s'appelait des mathématiques. Un algorithme est bien une notion mathématique, et les premiers algorithmes suivaient ce que savaient faire les mathématiciens, hors les mathématiciens n'utilisaient pas de boucle itérative, mais uniquement du fonctionnel pur. Comment dire donc que l'un ou l'autre est plus naturel? Tu as totalement le droit d'avoir ton avis et de penser que celui-ci est plus naturel. Je pense le contraire. Mais de toute façon, personne n'a pour l'instant démontré ou même avancé des arguments suffisamment convaincant pour convaincre la majorité de la communauté scientifique. Si tu as une référence sérieuse alors je suis preneur.

[...]
Là encore, il ne faut pas penser que les mathématiques sont une chose à tout faire, tout démontrer, et même des choses qui n'ont pas de sens en mathématiques, du genre l'existence de Dieu !

Je ne vois pas le rapport avec le sujet... mais tu as raison.

[gorgonite]

les premiers algorithmes suivaient ce que savaient faire les mathématiciens, hors les mathématiciens n'utilisaient pas de boucle itérative, mais uniquement du fonctionnel pur.

et l'algorithme d'Euclide pour trouver le pgcd de deux nombres ?
a-t-il été donné de manière récursive ou itérative ? (perso, la première présentation qu'il m'en a été faite était impérative )

je trouve que cela s'éloigne un peu trop de la question initiale... qui n'était pas impératif vs fonctionnel

[Garulfo]

et l'algorithme d'Euclide pour trouver le pgcd de deux nombres ?
a-t-il été donné de manière récursive ou itérative ? (perso, la première présentation qu'il m'en a été faite était impérative )

A priori, on est tenté de dire qu'il est impératif, mais ce n'est pas le cas dans sa conception originelle. En effet, Euclide, si je ne m'abuse, ne changeait pas la valeur de a et de b car ça n'a pas de sens de changer une valeur a vaut et vaudra tout le temps a. En mathématique, les valeurs ne peuvent pas changer au cours du temps... et pour les mathématiciens, c'était ça qui était naturel (donc pas l'impératif). L'algorithme original possède une suite de valeurs (a_i) et une suite (b_i). Ces valeurs sont calculées par induction. Tu peux trouver la version mathématique de l'algorithme, par exemple, dans F. Reinhardt et H. Soeder, Atlas des mathématiques, chez Le livre de poche, éd. française 1997, p.116.
Il doit bien y avoir un endroit sur internet où tu retrouverais cette forme... mais je ne sais pas où. De nos jours on le présente sous une autre forme puisqu'on pense à sa version informatisée pour un langage impératif.

je trouve que cela s'éloigne un peu trop de la question initiale... qui n'était pas impératif vs fonctionnel

Effectivement, je m'en excuse... c'est un peu de ma faute quand même.

[gorgonite]

L'algorithme original possède une suite de valeurs (a_i) et une suite (b_i). Ces valeurs sont calculées par induction.

mais cette représentation par une suite de valeurs ne correspond-elle pas à un modèle mathématique d'une variable ?

perso, si la conception avait été fonctionnelle, j'y aurais plutot vu cela :

Code :

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

1
2
3
4
5
6
7
8
9
// tirée de wikipedia
Fonction PGCD(a, be)
Si b=0
   alors a
Sinon
   c egal au reste de la division entière de a par b
   PGCD(b, c)
Finsi

[Garulfo]

Oui, le côté historique, je suis au courant, mais c'est aussi pour celà qu'il sont plus naturels : parce que l'on a commencé à utiliser des langages impératifs en masse (FORTRAN par exemple), on a continué à utiliser le même type de langages parce que les gens y étaient déjà habitués et que ça paraissait naturel de faire ainsi.

Ils sont plus naturel parce qu'on avait de meilleur techniques pour les compiler?? Tu disais bien que c'est parce que c'était plus naturel que c'était plus utilisé ? C'est faux. Je ne connais aucun historien des sciences ou chercheurs qui soutiendra ce que tu avances. On a trouvé un moyen de compiler efficacement un programme, on a fait le FORTRAN qui suivait ces principes. Le FORTRAN n'a pas précédé la technique de compilation qui l'a permis. Les premiers « langages » étaient purement mécanique. Étaient-ils plus naturels pour autant? Le style impératif est plus proche de la machine et, à ce moment là, clairement plus efficace.

Les gens n'étaient pas habitués à utiliser un langage impératif avant qu'il y ait des langages impératifs. Ça n'a pas de sens.

Si c'était si naturel... pourquoi a-t-il fallu que pendant 2000 ans on fasse des maths et de la physique autrement qu'en pensant un espace mémoire mutable? Et pourquoi d'autres personnes ont-ils pensé au fonctionnel?

Je t'encourage à lire Why no one uses functional languages de
Philip Wadler des Laboratoires Bell. Tu verras que jamais il ne mentionne l'argument du « naturel » pour un côté comme de l'autre. L'article est disponible sur le portail ACM.
Wolfgang Hagen conclue dans son article sur l'histoire de l'informatique (The Style of Sources disponible sur son site) que les programmations fonctionnelle et déclarative sont supérieures logiquement parlant à la programmation impérative: « And it is clear that declarative and functional languages are at least logically superior to the [procedural and imperative programming languages] » Il ne parle pas de « naturel » car ça n'a pas de sens en soi. Cependant, s'ils sont logiquement supérieurs, on peut supposer qu'ils sont en quelques sortes « naturels » à l'homme. Car sinon, ils ne nous sembleraient pas logiquement supérieurs. Mais ce n'est pas une preuve. Juste mon avis.

Alors peut-être que tous les historiens ont tort et tous les chercheurs aussi (enfin.. disons plutôt la grande majorité). Mais jusqu'à preuve du contraire, je serais tenté de pencher du côté de mes confrères et de mon intuition plutôt que de toi. Encore une fois... je ne dis pas que tu as tort; je dis que rien de concluant n'a jamais permis de trancher.

[Garulfo]

mais cette représentation par une suite de valeurs ne correspond-elle pas à un modèle mathématique d'une variable ?

perso, si la conception avait été fonctionnelle, j'y aurais plutot vu cela :

Code :

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

1
2
3
4
5
6
7
8
9
// tirée de wikipedia
Fonction PGCD(a, be)
Si b=0
   alors a
Sinon
   c egal au reste de la division entière de a par b
   PGCD(b, c)
Finsi

Tu oublies que jamais Euclide ne se serait exprimé dans l'un ou l'autre des paradigmes dont on parle ^_^. Il ne l'a exprimé dans aucune des deux façons dont on parle, mais de manière géométrique en faisant des soustractions de la longueur de ligne. Et il n'y avait pas de variable non plus... On est donc très loin de pouvoir modifier la valeur d'une variable (ce qui est le coeur de l'impératif). Je dis surtout que les maths n'ont aucune base impérative: une variable (et tu as raison ce sont des variables) ne change pas de valeurs en math. Il n'y a jamais de boucle itératif donc, mais essentiellement de la récursivité. La définition du fonctionnel c'est qu'on manipule les fonctions comme les autres données. Il me semble que la théorie des catégories, l'analyse fonctionnelle, ou plus prosaïquement la dérivation montre bien qu'on est dans un monde fonctionnel. On s'entend qu'on ne peut pas vraiment parler de fonctionnel car ce concept n'existe qu'au XXe siècle. Mais l'idée est là non ? De plus le fonctionnel ne s'oppose pas à l'impératif (pour preuve les langages qui combinent les deux).

Donc (concluons, concluons) je dis surtout que les maths n'ont jamais fait de style impératif, et qu'ils ont utilisé par contre depuis au moins le 17e siècle. Par rapport à notre discussion (le langage impératif est-il le plus naturel des styles de programmation) je dirais donc que non. Sinon on aurait pensé les maths et la physique selon cet approche. ^_^ Maintenant, je n'avance pas qu'un autre est plus naturel, car il me semble que c'est difficile de parler de l'un ou de l'autre comme plus naturel. La préexistence historique n'entraîne pas le côté plus naturel de l'objet... c'est pour ça que l'argument de IOCWT selon lequel puisque FORTRAN est arrivé avant alors la programmation impérative est plus naturelle me semble très surfait.

Je vais chercher pour voir comment Euclide a exprimé ce processus dans ses éléments.

[edit]Plus besoin du P.S. merci Gorgo[/edit]

[SpiceGuid]

y a-t-il un style de programmation plus "naturel" ?

Non, tout est artificiel.
Mais plus on est habitué à l'artificiel plus il paraît naturel.

L'impératif n'est dominant ni pour des raisons historiques (le lambda-calcul est antérieur) ni pour des raisons de facilité (la difficulté de l'impératif croit avec la taille du programme). Il est dominant:

• pour une raison d'idéologie commerciale: un programme est un produit et un produit ne doit pas être il doit faire
• pour une question de ressources humaines: le programmeur impératif est plus courant donc plus disponible et moins cher

[Garulfo]

[...]
... en fonctionnel, c'est-à-dire en regardant le problème sous l'aspect données et non nécessairement sous l'aspect enchaînement des calculs, je doute que ça soit aussi clair et simple...[....]

C'est marrant j'avais pas relevé ça.
Le fonctionnel n'a pas pour caractéristique de regarder le problème sous l'aspect données: sinon la programmation objet est fonctionnelle. On en avait déjà discuté. Ton raisonnement se basait sur le fait que l'évaluation paresseuse était une caractéristique de la programmation fonctionnelle et qu'elle imposait de regarder le problème sous l'aspect donnée. Or l'évaluation paresseuse (le principe) n'est pas propre à la programmation fonctionnelle. Un if est par nature une évaluation paresseuse.

Le paradigme fonctionnel, c'est penser la fonctionnalité et se demander « qu'est ce que je peux faire ? » et non « qu'est ce que je suis ? » ou encore pour être plus précis « que faire ? » plutôt que « comment faire ? » car la donnée de base est la fonction. Ce n'est donc pas de regarder l'aspect par rapport aux données en particulier qui est plus une caractéristique de la programmation objet.

Rien n'interdit de faire de la programmation structuré en programmation fonctionnelle... où as tu vu ça ?
L'algorithme de ton exemple est donc le même qu'il soit fonctionnel ou impératif. Tu dis d'ailleurs toi même dans le message suivant que l'algorithme ne change pas, a priori, selon le type de programmation. Et c'est vrai. Conceptuellement parlant c'est la même chose.

aller à l'école.
- se lever
- prendre son petit déjeûner
- sortir de chez soi
- emprunter le chemin en passant par certains point habituels
- rentrer dans l'établissement

La réalisation est différente... mais la ce n'est pas plus « naturel » en C qu'en Lisp. Alors pourquoi dire que ceci est différent de l'impératif au fonctionnel. Où vois tu une variable qui se modifie ici de toute façon ?

[DrTopos]

Bonjour à tous,

il me semble que la programmation impérative est naturelle quand on doit tenir compte du temps (l'avant, l'après, etc...) et qu'elle ne l'est pas si ce qu'on fait est indépendant du temps. Dans ce dernier cas le fonctionnel est nettement plus naturel, car le fait de ''donner des ordres'' devient inutile. En recherchant le mot ''temps'' dans cette page et la précédente, je ne l'ai trouvé que dans une intervention de Garulfo, avec lequel je suis d'ailleurs parfaitement d'accord. Bien entendu, les mathématiques sont totalement indépendantes du temps, et donc totalement non impératives.

@InOCamlWeTrust: les mathématiques sont bien un langage, cela ne fait aucun doute. On peut d'ailleurs le formaliser. Par ailleurs, dire que les mathématiques n'ont aucun rapport avec l'algorithmique est ignorer le très populaire ``Isomorphisme de Curry-Howard''.

[SpiceGuid]

Je suis entièrement d'accord avec DrTopos: La différence fondamentale entre le paradigme impératif le paradigme fonctionnel c'est l'aspect déclaratif, la compréhension du calcul se fait sur la définition (lisibilité statique) et non sur l'exécution (lisibilité dynamique). La lisibilité statique est comsidérablement plus simple que la lisibilité dynamique (je n'ai pas dit plus "naturelle" j'ai dit plus simple au sens d'une sémantique plus facilement à expliciter).

Sinon aucun paradigme ne privilégie soit les données soit les fonctions, ce serait absurde puisque ces deux notions sont duales. Dire que le lambda-calcul ne s'intéresse qu'aux fonctions ce serait oublier que sa formalisation sémantique ne s'intéresse qu'aux fermetures lexicales. Chassez les données hors des définitions et elles iront se cacher dans la sémantique. De même, chassez les fonctions hors des TAD (Types Abstraits de Données) et elles iront se cacher dans les "interfaces".

Ce qui fait la spécificité de l'approche objets c'est:
1. la possibilité d'accéder aux fonctions enfermées dans une fermeture lexicale
2. la possibilité de déléguer une requête à une autre fermeture lexicale si la fermeture visée ne contient pas la fonction recherchée

L'appproche objets est donc compatible avec n'importe quelle approche en mesure de créer des fermetures lexicales. Si le paradigme impératif en est le premier bénéficiaire c'est tout simplement parce que son type algébrique "somme" est inexistant ou particulièrement médiocre, d'où un culte immodéré pour la délégation qui lui sert de substitut. En caricaturant on pourrait dire qu'en POO les types "produits" négocient entre eux pour décider lequel est la bonne alternative du type "somme" sélectionné.

[Garulfo]

Non, et c'est là la grande différence ! En fonctionnel on regarde souvent le if comme une fonction, paresseuse, mais en impératif, le if ne peut être sous aucun prétexte une fonction[...]

Mais c'est ta vision. On pourrait très bien le voir comme une fonction.
Encore une fois, tu rentres dans la subjectivité et l'interprétation.

Le if met en attente une partie du calcul en fonction d'une condition: c'est donc une forme d'évaluation paresseuse.

L'évaluation paresseuse n'est pas le propre de l'approche fonctionnelle, de même qu'on ne peut caractériser celle-ci par « être plus orientée vers les données ». Être un langage fonctionnel, c'est pouvoir manipuler les fonctions comme les autres données.

[gorgonite]

Le C et le FORTRAN sont donc fonctionnels, ainsi que l'assembleur.

la manipulation des fonctions en C n'est pas si triviale que cela...
en plus, je ne crois pas que tu puisses construire des fonctions "à la volée" avec une syntaxe du style fun x -> 1 + x
(ça peut se faire mais ce n'est pas si facile que cela... perso, cela m'a pris un mois pour "maitriser" une telle construction )

[DrTopos]

... et alors, ça prouve quoi ? Qu'est-ce que c'est que les mathématiques ?

Quelques éléments de réponse ici.

[Garulfo]

Le C et le FORTRAN sont donc fonctionnels, ainsi que l'assembleur.

Je crois que tu n'as pas capté ce que je voulais dire, c'est pas grave.

Ça sert à rien d'être cynique... c'est la définition d'un langage fonctionnel que de traiter les fonctions comme les autres données ! De plus Gorgonite apporte le point principal : comment construire des fonctions anonymes en C ? Une des questions simples que je pose en cours pour montrer la puissance d'un langage fonctionnel est simplement de demander à faire une fonction qui compose deux fonctions. Ça se fait en C... tout se fait en C puisque tu peux manipuler au plus bas niveau. Mais c'est quand même relativement horrible.

Comment peux tu dire pour cet exemple, la composée, qu'un langage impératif est plus naturel ?

[gorgonite]

Mis à part construire des fonctions partielles directement, tu peux tout faire ...

pas tout à fait d'accord... ce n'est pas si direct que cela

Code :

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

let inc_by x = fun y -> y +x in

comment t'y prendrais-tu en c pour faire la même chose, sans utilisation excessive de subtilités dépendant strictement de ton compilateur, et de l'architecture sous-jacente ?

[DrTopos]

Ce qui fait la différence entre un langage vraiment fonctionnel et un langage faussement fonctionnel sont les deux faits suivants. Dans un langage vraiment fonctionnel:

• les fonctions sont définissables à la volée (avec 'function' et '->' en Caml ou '|->' en Anubis),
• elles se souviennent du contexte local dans lequel elles ont été définies.
  

Quand les fonctions ont ces deux propriétés, on dit en général que le langage a des 'fonctions de première classe'. C'est le cas de Caml, Haskell, les versions assez récentes de Lisp, Anubis et même Javascript. Par contre C et C++ et la plupart des langages impératifs n'ont pas de fonctions de première classe.

Pour tester si un langage, dans lequel les fonctions ont définissables à la volée, a des fonctions de première classe, on peut utiliser l'exemple suivant (que j'écris en Anubis, car je ne connais pas assez bien Caml):

Code :

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

1
2
3
4
5
    with x = 2, 
           f  =  y |-> x + y, 
           x = 5, 
          f(1).

Si la valeur de cette expression est 3, le langage a des fonctions de première classe. Sinon , la valeur sera probablement 6.

En fait, ce qu'il se passe est que la fonction définie par f = y |-> x + y se souvient que là où elle a été définie, x valait 2. Le fait de changer ensuite la valeur de x (où plus exactement ici de redéclarer une nouvelle variable de même nom x ayant une valeur différente) n'aura aucune influence sur la fonction f. Du point de vue implémentation, ceci est réalisé grâce à des 'fermetures', c'est à dire qu'une fonction de première classe n'est pas seulement un pointeur sur un bout de code, mais est essentiellement une paire formée d'un pointeur sur du code et d'un 'micro-contexte', c'est à dire des références sur les valeurs des symboles utilisés lors de sa définition (x ci-dessus).

Un langage qui n'a pas de fonctions de première classe donnera 6 comme résultat car il confondra la nouvelle valeur de x avec l'ancienne. Ceci constitue une faute sémantique qu'on appelle 'capture de variable', phénomène maintenant bien compris (mais pas du tout dans les années 70, où la plupart des interpréteurs Lisp faisaient cette faute, et en particulier LeLisp de L'inria).

Je sais que certains considéreront que ce comportement (capture de variable) peut être normal en invoquant la notion de 'liaison dynamique' (par opposition avec 'liaison lexicale'). Je considère ce concept, qui est non déterministe, comme la source de nombreux bugs extrêmement difficiles à déboguer (croyez-en ma longue expérience), et je crois qu'il résulte d'une confusion entre la notion de variable (emplacement physique contenant une valeur qui peut varier au cours du temps), et celle de déclaration de symbole dans une expression déterministe qui est de nature complètement différente.

Alors, bien sûr on peut simuler les fermetures en C, mais au prix d'acrobaties 'indignes' (je pèse mes mots) et de 'casts' dont la seule existence est l'aveu implicite d'une conception ratée du système de types. Comme l'a fait remarquer SpiceGuid, c'est surtout l'incompréhension de la notion de type somme qui en est la cause, mais c'est une autre histoire...