IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Un bon développeur est un développeur flemmard !

[Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté

Noter ce billet
4 Commentaires
par
kolodz
, 30/03/2015 à 12h12 (1487 Affichages)
Dans le billet Poker time! de stendhal666, il est question de l'approche fonctionnel et ce qu'apport "en plus" un langage fonctionnel tel que LISP, par rapport à un langage orienté objet, justement grâce à son approche fonctionnel. Cela ne peux-être pas vrai.

Tout langage (de programmation) à partir du moment où celui-ci est suffisant évolué peut tout exprimer. C'est un concept de la théorie des langages. L'idée est qu'une fois qu'un langage dispose de certaines brique élémentaires, celui-ci est capable de construire autour tout le reste. Ainsi la seule différence entres deux langages n'est que la difficulté à exprimer certaines choses, par rapport à d'autres.

La machine à état VS La machine à transition
Dans l'un de mes projets étudiants, il m'a été donnée d'utilisé une machine à transition et non un machine à état. La machine à transition réalise beaucoup mieux les "ou" qu'une machine à état.
L'exemple typique est le cas ou vous devez appuyez sur 3 (A, B, C) boutons pour arriver dans l'état final, sans prendre en compte l'ordre. La machine a est obligé d'exprimer la combinatoire. Alors, que la machine a transitons n'a pas à le faire, celle-ci dit littéralement "Il faut les 3 transitions A, B, C".
Cependant, la machine à transition aura beaucoup plus de mal à exprimer les "et".
Ce qui fait qu'objectivement la machine à transition n'est pas plus intéressante qu'une machine à état, sauf si on gère un problème avec beaucoup plus de "ou" que de "et".
En résumé, une représentation ou un langage n'apporte qu'une facilité à exprimer certaines choses, par rapport à d'autres.

Note : C'est souvent un reproche qu'on fait au Framework.
Citation Envoyé par Le type qui râle sans comprendre
Quand on ne fait plus ce qui est déjà prévue, c'est atrocement compliqué.
Oui, vous voulez faire des "ou" avec un système pensé pour les "et". C'est normal !

La programmation Orienté Objet dans un langage fonctionnel impératif:
Il faut bien comprendre qu'en définitive tout les langages informatiques sont traduit en assembleur. Il est donc nécessairement possible de faire de la programmation orienté objet dans un langage fonctionnel impératif. Travaillant actuellement avec un (vieux) framework basé sur du C. Je peux vous dire que cela fait un moment qu'on sait faire !

Globalement, on utilise les structures comme suit :
Code c : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
struct base
{
    /* base class members */
};
 
struct derived
{
    struct base super;
    /* derived class members */
};
Une fois qu'on a cela il suffit de faire 2/3 casts assez malin et paf ! On fait des chocapik ! Euh... de la programmation orienté objet.
La différence avec un langage "Objet" est que ce n'est pas une mécanique mise en place par le langage, mais par l’utilisateur/développeur.

Note : il faut savoir que cette "astuce" à réellement un intérêt énorme quand on programme en C. Cela permet d'avoir des fonctions communs à de nombreuses structures (objet).

Conclusion :
L'approche que vous choisissez pour résoudre un problème, est un choix, tout comme le langage de programmation. Il est certes plus logique d'avoir une approche objet avec un langage objet. Car, celui-ci a déjà le sucre syntaxique nécessaire à cela. Mais, rien ne doit vous empêcher de comprendre que c'est bien votre choix... Et non une contrainte que vous vous imposez au moment du choix du langage. Ce choix devrait être fait à chaque fois qu'un problème est abordé, aussi petit soit-il !

Epilogue :
Honnêtement, je ne crois pas au langage miracle. Plus un langage donne de sucre syntaxique, plus celui-ci devient complexe et difficile à lire et à comprendre. Même si ces dernières années, on a vue des langages être utiliser pour tout faire. JavaScript étant le dernier dans ce cas. Ce qui n'a strictement aucun intérêt de mon point de vue. Car, il est plus facile de manipuler plusieurs langages "dédiés" simples, qu'un seul complexe.

Cordialement,
Patrick Kolodziejczyk.

Source :
http://www.developpez.net/forums/blo...86/poker-time/
https://sourceforge.net/projects/ensisaprojet2a/

Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Viadeo Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Twitter Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Google Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Facebook Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Digg Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Delicious Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog MySpace Envoyer le billet « [Avis]Pourquoi vous avez tort et j'ai raison : Programmation orienté et Langage Orienté » dans le blog Yahoo

Mis à jour 30/03/2015 à 14h17 par kolodz

Catégories
Programmation

Commentaires

  1. Avatar de stendhal666
    • |
    • permalink
    Dans le billet Poker time! de stendhal666, il est question de l'approche fonctionnel et ce qu'apport "en plus" un langage fonctionnel tel que LISP, par rapport à un langage orienté objet, justement grâce à son approche fonctionnel. Cela ne peux-être pas vrai.
    Je suis très flatté d'être cité, avec un lien et tout!

    Tout langage (de programmation) à partir du moment où celui-ci est suffisant évolué peut tout exprimer. C'est un concept de la théorie des langages. L'idée est qu'une fois qu'un langage dispose de certaines brique élémentaires, celui-ci est capable de construire autour tout le reste. Ainsi la seule différence entres deux langages n'est que la difficulté à exprimer certaines choses, par rapport à d'autres.
    Jusque là, je suis d'accord et c'était même l'objet de mon message: l'approche fonctionnelle favorise un style bottom-up. Si je m'y suis exprimé de façon trop catégorique, tant pis pour moi.

    Il faut bien comprendre qu'en définitive tout les langages informatiques sont traduit en assembleur. Il est donc nécessairement possible de faire de la programmation orienté objet dans un langage fonctionnel. Travaillant actuellement avec un (vieux) framework basé sur du C. Je peux vous dire que cela fait un moment qu'on sait faire !
    Juste en passant, le C n'est pas un langage fonctionnel

    Honnêtement, je ne crois pas au langage miracle. Plus un langage donne de sucre syntaxique, plus celui-ci devient complexe et difficile à lire et à comprendre. Même si ces dernières années, on a vue des langages être utiliser pour tout faire. JavaScript étant le dernier dans ce cas. Ce qui n'a strictement aucun intérêt de mon point de vue. Car, il est plus facile de manipuler plusieurs langages "dédiés" simples, qu'un seul complexe.
    Donc on est d'accord, apprenons les langages dédiés au bottom-up, les langages fonctionnels
  2. Avatar de kolodz
    • |
    • permalink
    Juste en passant, le C n'est pas un langage fonctionnel
    Effectivement, c'est un langage impératif... Autant pour moi.
    Mais le point était bien de montré que l'orientation de la programmation choisit n'est pas lié au langage.

    Donc on est d'accord, apprenons les langages dédiés au bottom-up, les langages fonctionnels
    Tout autant que les autres langages, pas plus, pas moins.
  3. Avatar de stendhal666
    • |
    • permalink
    Citation Envoyé par kolodz
    Tout autant que les autres langages, pas plus, pas moins.
    Hé hé, j'en ferai l'objet d'un billet sur mon blog mais en un syllogisme:
    - si on part du bas pour aller vers le haut, c'est-à-dire des éléments pour aller vers la structure, il faut un moyen de lier ces éléments entre eux
    - les langages fonctionnels permettent de lier aisément les fonctions entre elles*
    - donc l'approche bottom-up est aisée dans les langages fonctionnels

    * prétends-tu vraiment que le C permette de lier aisément les fonctions entre elles? il suffit de regarder qsort, dans la bibliothèque standard, pour se rendre compte que non...
  4. Avatar de kolodz
    • |
    • permalink
    Je dis qu'un bon développeur doit avoir un certains nombre de cordes à son arc. La programmation fonctionnel n'en n'est qu'une parmi tant d'autres.
    * prétends-tu vraiment que le C permette de lier aisément les fonctions entre elles? il suffit de regarder qsort, dans la bibliothèque standard, pour se rendre compte que non...
    Personnellement, je n'ai aucun attraits pour le C. Et pour tout te dire je n'ai réellement utilisé la librairie standard C. J'en connais une partie, mais sans plus.
    Après, il faut bien distingué le langage et la librairie "standard". Car, des librairies mal fichu, il y en a dans tout les langages...

    Après ton "aisément" est très subjectif. Je doute profondément que le fonctionnel permet de fait du bottom-up plus "aisément" qu'une autre type de langage..
    Mais, il faudrait peut-être que tu explique quels sont les éléments qu'apporte le langage fonctionnel qui permet ce bottom-up, qui est non existant autre part.
    Car :
    - si on part du bas pour aller vers le haut, c'est-à-dire des éléments pour aller vers la structure, il faut un moyen de lier ces éléments entre eux
    Oui, mais en quoi cela n'est pas possible ?

    Cordialement,
    Patrick Kolodziejczyk.