Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 10 sur 10
  1. #1
    Max.Adorable
    Invité(e)

    Par défaut 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.

  2. #2
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 78
    Points
    78

    Par défaut

    Citation Envoyé par Max.Adorable Voir le message
    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.

  3. #3
    Max.Adorable
    Invité(e)

    Par défaut

    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.

  4. #4
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 162
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 162
    Points : 18 669
    Points
    18 669

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  5. #5
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 48

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 205
    Points
    2 205

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    [..]
    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.

  6. #6
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 48

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 205
    Points
    2 205

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    [...]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.

  7. #7
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 160
    Points
    1 160

    Par défaut

    Citation Envoyé par Max.Adorable Voir le message
    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 Voir le message
    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.

    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.

  8. #8
    Max.Adorable
    Invité(e)

    Par défaut

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

    Max.

  9. #9
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 073
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 073
    Points : 8 265
    Points
    8 265

    Par défaut

    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ï

  10. #10
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 48

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 205
    Points
    2 205

    Par défaut

    Citation Envoyé par Jedai Voir le message
    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 !!!


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

    ---

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

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •