fonctionnel : mutable et orienté objet

Bonjour à tous,

Je suis débutant dans les langages fonctionnels, je commence avec F# car j'aime bien le framework dotNEt et que j'ai quelques connaissance dedans.

J'ai lu quelques documents présentant les langages fonctionnels. Maintenant, il y a deux questions que je me pose.

1° J'ai cru comprendre qu'en programmation fonctionnelle "pur" il n'y a pas de variable. F# est un langage hybride et à moyen de définir des variables grâce à mutable. Est-ce possible de s'en passer où dans certains cas c'est inévitable ? N'est pas un peu en contradiction avec le paradigme fonctionnel ? http://jyliao.blogspot.com/2007/11/w...tate-in-f.html Sur ce blog je vois une traduction d'une page ASP.Net en F# est-ce possible de se passer de mutable ?

2° La programmation orienté objet est apparenté avec le paradigme impératif pour moi. Je vois que Haskell n'a pas de possibilité de faire de l'orienté objet alors que F# oui. Est-ce que paradigme fonctionnel et orienté objet sont ils complémentaires ou est-ce la partie permettant de faire de la programmation impérative avec F# ?

Merci d'avance.
Max.

Citation:

---

Envoyé par Max.Adorable

Bonjour à tous,

Je suis débutant dans les langages fonctionnels, je commence avec F# car j'aime bien le framework dotNEt et que j'ai quelques connaissance dedans.

J'ai lu quelques documents présentant les langages fonctionnels. Maintenant, il y a deux questions que je me pose.

1° J'ai cru comprendre qu'en programmation fonctionnelle "pur" il n'y a pas de variable. F# est un langage hybride et à moyen de définir des variables grâce à mutable. Est-ce possible de s'en passer où dans certains cas c'est inévitable ? N'est pas un peu en contradiction avec le paradigme fonctionnel ? http://jyliao.blogspot.com/2007/11/w...tate-in-f.html Sur ce blog je vois une traduction d'une page ASP.Net en F# est-ce possible de se passer de mutable ?

2° La programmation orienté objet est apparenté avec le paradigme impératif pour moi. Je vois que Haskell n'a pas de possibilité de faire de l'orienté objet alors que F# oui. Est-ce que paradigme fonctionnel et orienté objet sont ils complémentaires ou est-ce la partie permettant de faire de la programmation impérative avec F# ?

Merci d'avance.
Max.

---

Oui en fonctionnel pur il n'y a pas de variable variable. Mais dans ce cas là tu pleures. Il suffit d'imaginer un tableau excell que se passe-t-ilo quand l'utilisateur veut modifier une cellule, on recrée un tableau ? et pelin de trucs comme ça.

Par contre le fonctionnel et l'objet sont deux points de vue antinomique. Il vaut mieux ne pas les mixer.

Bonsoir,

D'abord merci pour ces explications. Cependant mon esprit est un peu borné et ayant toujours développé mes applications en objet j'ai un peu de mal à saisir la manière d'architecturer une application avec le paradigme fonctionnel.

Peut-être n'est-ce pas un domaine pour le paradigme fonctionnel mais comment construire une simple application CRUD avec ce dernier ?
Auriez-vous des exemples d'architectures ou de projet développé avec ce paradigme ? Parce que j'ai du mal à saisir.

Merci bien,
Max.

Citation:

---

Envoyé par NokyDaOne

Par contre le fonctionnel et l'objet sont deux points de vue antinomique. Il vaut mieux ne pas les mixer.

---

pas d'accord... la POO a également parue très étrange à l'époque où tout le monde faisait de la programmation procédurale, mais sans passer au tout objet on voit vite l'utilité des enregistrements & cie même avec du code fonctionnel

au passage, l'utilisation des modules auquel on passe une variable d'un type dont le fonctionnement interne n'est connu que de ce module, est aussi une façon de faire un peu de la POO ;)

Citation:

---

Envoyé par NokyDaOne

[..]
Par contre le fonctionnel et l'objet sont deux points de vue antinomique. Il vaut mieux ne pas les mixer.

---

C'est très faux...
Je suppose que tu confonds « impératif » et « non fonctionnel » en disant ça. Car au fond tu vois l'objet comme nécessairement impératif.

Or, d'une part, le fonctionnel peut-être aussi impératif et, d'autres part, l'objet peut être non impératif avec copie des objets à chaque fois (effectivement).

Un objet en fonctionnel est simplement une fonction qui attend un message.
C'est toute la distinction entre (f e) qui représente l'approche procédurale (et non le fonctionnel) et (e f) qui représente l'approche objet. Écris ainsi, on voit bien que le paradigme fonctionnel transcende cette distinction, puisque syntaxiquement, on ne voit pas la différence.

Citation:

---

Envoyé par gorgonite

[...]mais sans passer au tout objet on voit vite l'utilité des enregistrements & cie même avec du code fonctionnel[...]

---

Historiquement, Lisp a plus inspiré Smalltalk que les Algols ou autre Fortran. Et des extensions comme CLOS sont « tout objet »... plus « tout objet » que Java a ses débuts par exemple.

Citation:

---

Envoyé par Max.Adorable

1° J'ai cru comprendre qu'en programmation fonctionnelle "pur" il n'y a pas de variable. F# est un langage hybride et à moyen de définir des variables grâce à mutable. Est-ce possible de s'en passer où dans certains cas c'est inévitable ?

---

Dans beaucoup de cas, on peut s'en passer.

Dans certains cas, on pourrait s'en passer, mais on s'en sert pour des raisons de performance, ou parce que ça simplifie le code. Quand on a besoin d'effets de bords, il vaut mieux les confiner au maximum. D'ailleurs, une fonction utilisant des effets de bords en interne peut sembler pure pour l'extérieur. Par exemple, utiliser une table de hachage localement dans une fonction est tout à fait acceptable.

Dans quelques cas, on n'a pas le choix. Ça peut arriver quand on utilise une bibliothèque .Net conçue pour des langages impératifs. J'ai l'impression que c'est le cas dans le lien que tu cites.

Citation:

---

Envoyé par Max.Adorable

N'est pas un peu en contradiction avec le paradigme fonctionnel ?

---

Non. On peut faire de l'objet sans effet de bords. Ça dépend de ce que tu souhaites faire.


En général, il vaut mieux éviter les effets de bords, mais ce n'est pas grave d'en faire. Par exemple, c'est utile d'en faire lorsque l'on crée une interface graphique. Mais il est préférable d'en limiter la portée (plus c'est local, moins c'est dangereux) et de séparer l'interface graphique du reste.

Citation:

---

Oui en fonctionnel pur il n'y a pas de variable variable. Mais dans ce cas là tu pleures.

---

Va dire ça sur le forum Haskell. :)

Merci à vous pour ces éclaircissements. Ça m'a beaucoup aidé.

Max.

On a toujours besoin d'effets de bord pour faire des vrais programmes (parce que sans IO un programme ne sert à rien...), le but du fonctionnel c'est de limiter l'usage d'effets de bord au maximum.

En OCaml ou F#, par défaut les "variables" ne varient pas, il faut utiliser le mot clé ref ou mutable pour l'autoriser. Il est parfois intéressant d'en passer par là pour des questions de performances : comme l'a dit NokyDaOne, les tableaux purement fonctionnels ne sont pas très pratiques lorsqu'on veut faire des mises à jour ponctuelles (une copie complète à chaque fois, ça te flingue les performances... Encore qu'il y ait des approches alternatives comme les DiffArray en Haskell qui permettent de garder des performances correctes dans ce cas, même avec des tableaux purement fonctionnels).

En Haskell, les effets de bords sont totalement interdits dans le code pur, les seuls endroits où ils sont permis sont dans la monade IO (qui infecte tout code l'utilisant : on ne peut pas appeler une commande IO depuis une fonction dont le type n'est pas IO) ou dans la monade ST (qui ne permet que des effets de bord type variables, pas de manipulation de fichiers par exemple, l'intérêt étant que le système de type de Haskell est suffisamment fort pour prouver automatiquement qu'une commande ST est pure vu de l'extérieur, ce qui signifie qu'on peut utiliser des commandes ST à partir d'une fonction non ST).

Donc oui, il vaut mieux se passer de mutable si tu peux à l'origine, et éventuellement l'utiliser de façon très localisé pour améliorer les performances à moindre coût.


Concernant les objets, tu te trompes si tu penses qu'Haskell ne permet pas d'en faire, ils ne sont pas intégrés au langage mais il est possible d'encoder la POO en Haskell. Néanmoins ils ne sont pas du tout indispensable et le système de type d'Haskell permet de faire beaucoup de choses pour lesquelles tu penserais avoir besoin d'objets. Connais-tu bien les mécanismes de typeclass d'Haskell par exemple ?

L'objet n'est pas complètement opposé au fonctionnel, simplement la plupart des langages objets aujourd'hui ont un modèle objet très impératif (ce qui pose pas mal de problème d'ailleurs, il suffit de voir le nombre de fois où un développeur Java est obligé de rendre ses objets immutables parce que c'est la bonne sémantique).

--
Jedaï

Citation:

---

Envoyé par Jedai

On a toujours besoin d'effets de bord pour faire des vrais programmes (parce que sans IO un programme ne sert à rien...)[…]
--
Jedaï

---

C'est pas vrai !!! :nono:


Ça sert à consommer du temps CPU ;)
C'est pas comme ça que fonctionne Windows ? :bug:

---

Bon, en fait, je suis bien sûr complètement en accord avec toi.