par , 30/03/2015 à 12h12 (1519 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.
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 :
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/