Discussion :

[gorgonite]

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

en caml, ça donnerait cela (si j'ai bien compris)

Code :

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

1
2
3
4
5
let x = 2 in
let f = fun y -> x + y in
let x = 5 in
f(1);;

la valeur renvoyée est bien 3

gorgonite@GorgonMobile:~$ ledit |ocaml
Objective Caml version 3.09.2

# let x = 2 in let f = fun y -> x + y in let x = 5 in f(1);;
Warning Y: unused variable x.
- : int = 3
#

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.

si je me souviens bien, c'est l'une des raisons de l'utilisation massive des my devant les déclarations de variables en Perl, pour garder arrêter les portées dynamiques

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.

je ne serai si intransigeant... le C n'a pas été fait pour ce genre de manipulation (faut pas oublier de se rappeler que c'est un langage impératif à la base )

sinon, dans le même style, je pourrais reprocher à prolog de ne pas accepter la programmation événementielle, sauf moyennant quelques immondes acrobaties comme dans leur librairie graphique

[gorgonite]

tu as lu trop vite, ou tu te moques de moi...


parce que je donne un argument x et je veux récupérer une fonction qui prend en argument y et renvoie x + y
rien à voir avec ce que tu as écrit... j'aurais pu le trouver cela quand même


perso, je sais le faire... mais ça prend facilement une trentaine de lignes

[gorgonite]

avec ton code c je ne peux pas faire ceci :

Code :

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

1
2
void* inc_by_2 = inc_by(2);
int n = inc_by_2(5);

donc ça ne va pas....


bien sûr l'exemple que j'ai mis ici est bidon, mais c'est juste pour la "forme"

[Garulfo]

[...]
je ne serai si intransigeant... le C n'a pas été fait pour ce genre de manipulation (faut pas oublier de se rappeler que c'est un langage impératif à la base )

Dr Topos n'est pas intransigeant. Il énonce une simple vérité: le C est à la base un langage de remplacement de l'assembleur. La notion de type est mal conçu. Contrairement à ocaml qui a un système de type on ne peut plus réussi.

On peut tout faire en C qu'on peut faire sur un ordinateur puisqu'il permet d'accéder directement à la mémoire. Cependant, nous parlions ici, enfin je pense, des éléments qui sont mis à la disposition pour faire de la programmation fonctionnelle et là ce n'est pas disponible, de base, en C. On peut contourner le problème, y compris le problème des types et des fermetures.

De la même manière, si on suppose que le scheme n'a pas de set! (l'affectation) on pourrait croire qu'il n'y a pas possibilité de faire de l'impératif (modification des variables), or c'est faux puisque la capture des continuités permet de le faire.

Aucun langage (dans ceux qu'on site ici) ne sont purement quelque fonctionnel ou impératif sans être l'autre. Ça ne s'oppose pas, c'est juste une autre direction.

Sinon, pour la composition de deux fonctions, tu as tort IOCWT, on peut le faire aussi en C avec un niveau aussi élevé qu'en ocaml. Il suffit d'utiliser la capture de continuation. Mais bon toujours est-il que si on ramène ça à notre problèmatique (le naturel de telle ou telle approche) on voit bien que la composition n'est pas du tout naturelle dans une approche impérative non ?

Donc, la programmation n'est pas, de facto, naturellement impérative. C'était là tout mon point. Ce que le Dr Topos a apporté est très pertinent. C'est vrai qu'il semble, a priori, que ce qui gère des variables « physiques » semble plus « naturellement » modélisé par de l'impératif, alors que ce qui gère des symboles « mathématiques » sera plus « naturellement » représenté par du fonctionnel. Je crois que c'est même plus subjectif que ça. Mais, à ma connaissance, aucune preuve ni argument sérieux n'existe.

[fasteez]

Hmmm l'idée c'est de calculer des choses, en fp on exprime ces calculs 'facilement' ( car plus court, plus précis, et plus généralement )

Par contre l'automate en dessous est une machine à registres memoire .. donc on est obligé de traduire ces jolis concepts en modifications de ces registres.

C'est la facon d'aborder les choses dans SICP et je la trouve particulièrement simple et "universelle". on part de principes qui nous intéressent et on exprime l'infrastructure d'execution via l'impératif.

'mon avis à 3 cents'

[bredelet]

Je trouve que le plus naturel pour les problemes mathematiques est la programmation "dataflow reactive"

Mais le mieux c'est d'avoir toutes les possibilites sous la main, imperatif, fonctionnel, reactif, logique... Pour cela vois le langage Oz et le livre "
Concepts, Techniques, and Models of Computer Programming"

[NokyDaOne]

Pour l'algortihme de pgcd (je ne savais pas qu'il était d'Eculide, on m'a bien sûr présenté son algo, mais on m'a aussi présenté la version des grecs), je vais partir sur la version grecque

il ya le truc on trace les deux segments on retranche le plus petit au plus grand et on recommence avec le petit et le nouveau jusqu'à la fin.

Ca se programme de deux façons :

Code :

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

1
2
3
4
5
let pgcd a b =
  if b = 0 then
    a
  else
    pgcd b (a - b)

mais aussi

Code :

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

1
2
3
4
5
6
7
8
9
let pgcd a b =
  let grand = ref a and
  let petit = ref b in
   while !petit <> 0 do
    let nouveau = !grand - !petit;
    grand := !petit;
    !petit := nouveau
  done;
  !grand

ces deux visions correspondent totalement à l'algorithme bien que l'une soit fonctionnelle et l'autre impérative

et je pense que souvent l'impératif et le fonctionel sont les deux facettes d'une seule et même chose


Après parler d'une vision plus naturelle, cela dépend des gouts et des couleurs. Etant matheux sur les bords, quand j'ai découvert le fonctionel (camllight) j'ai adoré car c'est ma façon de penser, mais il y en a qui pense impératif. Et je ne pense pas que l'on puisse en juger une plus naturelle que l'autre.

[alex_pi]

et je pense que souvent l'impératif et le fonctionel sont les deux facettes d'une seule et même chose

L'équivalence entre lambda calcul et machine de Turing résumée en une phrase :-p

[Garulfo]

L'équivalence entre lambda calcul et machine de Turing résumée en une phrase :-p

Je pense plutôt qu'il sous-entendait que c'était des notions duals.

[bredelet]

Oui. Eh bien essaie de programmer sans effets de bord en imperatif (c'est possible).

Je pense qu'il y a une raison pourquoi on considere en general que le fonctionel donne des resultats plus previsibles... Moins d'effets de bord!

[Garulfo]

Oui. Eh bien essaie de programmer sans effets de bord en imperatif (c'est possible).

Je pense qu'il y a une raison pourquoi on considere en general que le fonctionel donne des resultats plus previsibles... Moins d'effets de bord!

Ça dépend ce que tu veux dire par « en impératif ». Si tu veux dire : avec un langage impératif, tu n'as pas tort puisqu'on peut assurer une transparence référentielle en général (parfois avec beaucoup d'effort). Mais si tu veux dire « avec une approche impérative » c'est beaucoup moins évident puisque toute affectation à un effet de bord (ce n'est pas une simple liaison lexicale).

Maintenant... bizarre de parler de prévisibilité. Tout est prévisible en informatique ^_^

[bredelet]

Oui je voulais dire a l'aide d'un langage imperatif.

Et quand je parle de resultats previsibles, je veux dire previsibles par le programmeur! Que se passe-t-il si les taches ne s'executent pas dans l'ordre prevu? Si l'on oublie de donner une valeur initiale a une variable utilisee plus tard? Les effets de bord introduisent une dose d'imprevu certain.

[Garulfo]

[...]Les effets de bord introduisent une dose d'imprevu certain.

Oh oui définitivement. C'est, statistiquement, l'origine de la majorité des erreurs de programmation.

[GnuVince]

Salut,

Je suis peut-être en retard au party, mais je voudrais donner mon avis tout de même.

• Ni le paradigme impératif, ni le paradigme fonctionnel sont naturels; le seul "paradigme" naturel, c'est le téton.
• Le paradigme impératif se centre autour de la notion de la modification de l'état des objets.
• Comme l'a mentionné DrTopos, l'ordre des opérations dans un langage impératif a une très grande importance; il y un "avant" et un "après" pour chaque modification de variable, et le programmeur doit garder en tête tous les changements qui se produisent.
• Le paradigme fonctionnel se centre sur la composition de fonctions afin de retourner un nouveau résultat sans modifier la ou les entrées originales.
• La notion de temps n'entre pas en considération dans du pur fonctionnel, car rien ne change.
• À prime abord, l'impératif peut sembler plus facile, car on peut faire pratiquement n'importe quoi. "Ah, ça fonctionne pas, ben je vais juste changer telle variable et ajouter telle valeur et..." Les étudiants et professionnels finissent par faire fonctionner leurs programmes (avec différents niveau de succès et de sacres) avec l'illusion de facilité.
• Le paradigme fonctionnel est très simple à comprendre, il suffit de déplier les appels de fonctions jusqu'à ce qu'on arrive à notre résultat. Dans les vidéos du SICP, Gerry Sussman se lamente de la perte de ce modèle si simple et si élégant à l'apparition de set!.
• Le paradigme impératif demeure le paradigme le plus populaire de nos jours pour des raisons strictement historiques. Les premiers langages (Fortran, PL/I, COBOL, C, etc.) utilisaient ce paradigme et leurs descendants ont continué à le faire.
• Pour répéter les propos de Simon Peyton-Jones, un des créateurs de Haskell et du compilateur GHC, d'ici les 10 prochaines années, nous allons très certainement voir un mouvement d'adoption du paradigme fonctionnel. Il est plus probable de voir les langages impératifs populaires actuels acquérir ces fonctionalités plutôt que de voir une migration vers Haskell, OCaml et Scheme.
• Les processeurs multi-core vont forcer les gens à coder de façon à éviter les effets de bords, et les techniques apprises au cours des 30 dernières années dans la communauté fonctionnelle vont venir aider les programmeurs.

[Garulfo]

Salut,
[...]le seul "paradigme" naturel, c'est le téton.[...]

Et encore ^_^ je ne sais pas si tu as déjà un enfant, mais tu verras qu'un enfant ne sait pas téter par instinct. Il faut lui montrer.

[Garulfo]

[...]
Pour répéter les propos de Simon Peyton-Jones, un des créateurs de Haskell et du compilateur GHC, d'ici les 10 prochaines années, nous allons très certainement voir un mouvement d'adoption du paradigme fonctionnel. Il est plus probable de voir les langages impératifs populaires actuels acquérir ces fonctionalités plutôt que de voir une migration vers Haskell, OCaml et Scheme.

Content de voir que d'autres sont de mon avis ^_^

[InOCamlWeTrust]

Oh oui définitivement. C'est, statistiquement, l'origine de la majorité des erreurs de programmation.

Parce que statistiquement les langages de programmation les plus utilisés sont à effets de bord ?

[GnuVince]

Parce que statistiquement les langages de programmation les plus utilisés sont à effets de bord ?

Non, parce que les effets de bords, surtout ceux qui sont difficiles à contrôler, sont extrêmement difficile à tester. Tester une fonction pour calculer la moyenne d'une liste de nombres est facile à faire, et on peut facilement couvrir tous les cas possible (liste vide, liste d'un élément, liste de x éléments, liste avec des nombres décimaux, etc.) C'est moins évident de tester une fonction qui doit manipuler des fichiers. On doit pouvoir tester des possibles race conditions, des problèmes de permissions, des problèmes d'un autre processus qui a changé le fichier, etc.

[Garulfo]

Parce que statistiquement les langages de programmation les plus utilisés sont à effets de bord ?

Non, parce que les effets de bords, surtout ceux qui sont difficiles à contrôler, sont extrêmement difficile à tester. [...]

Hum je ne serais pas aussi impératif (humour ) que toi Vince... Il est possible que le résultat brut tel que je le donne ici soit biaisé... Par exemple, je ne suis pas sûr que les études faites sur ces problèmes n'aient pas été presque exclusivement fait sur du Fortran, du Cobol, du C, du Ada et peut-être de l'Algol... c'est un résultat des travaux Boehm basé sur les projets en industrie. Or, je doute qu'ils aient rencontré beaucoup de Lisp ou de Scheme...