Apprendre la programmation ... Commencer directement par la POO

[cedric49fr2000]

salut a tous,

j'ai lu que la programmation imperative t procedurale est plus proche de la machine et qu'il est mieux de faire coprendre le line avec la machine.

personnellement, je n'en vois pas l'interet. L'informatique de bas niveau est interessante uniquement si on veux gagne en performance. c'est de l'informatique de technicien. la le but est d'enseigner l'art de la programmation qui par principe doit etre separe de l'implementation (materielle et logiciel a savoir le compilateur ou l'interpreteur).


Pour ce qui est de java. on ne peux tout expliquer sur tout avant de commencer. certaine zone doivent rester flou et ce quelque soit le langage.


Quand j'ai appris la programmation on m'a pas enseigner directement le langage mais nous avon fait de l'algorythmique (en francais) avant que nous avon sensuite traduit dasn le langage(en laissant de cote les choses que nous ne pouvions comprendre: comme en math, il ya une part de chose que nous devons admettre. nous les comprendrons plus tard).

LA POO est un paradygme plus humain et donc devrait etre plus facilement comprehensible. en effet; quand nous ouvrons une porte. c'est pas sur l'action d'ouverture que nous portons notre attention mais bien avant tout sur la porte.

Nous ne nous disons pas que nous allons ouvrir quelque chose pour ensuite nous demande ce que nous allons ouvrir. la porte viens bien en premier dans notre visions du monde.

cedric; au plaisir.

[davcha]

Le problème de l'approche "POO tout de suite", c'est que, à 16-18 ans, la plupart des gens n'ont pas le recul nécessaire par rapport aux choses pour réellement faire de la POO "efficace".

C'est bien beau de faire Porte.Ouvrir(); au lieu de Ouvrir(Porte);, mais ça n'est rien de plus qu'une syntaxe différente.
Porte.Ouvrir(); n'est, en soi, pas fondamentalement différent, ni "davantage objet" que Ouvrir(Porte);. La seule réelle différence à ce niveau là, c'est que dans Porte.Ouvrir();, le paramètre formel se trouve devant la méthode/fonction.

Faut pas oublier que la POO c'est aussi (surtout), le polymorphisme d'inclusion. Qui irait expliquer à quelqu'un n'ayant jamais programmé l'utilité des interfaces, des mots clefs comme protected, virtual, abstract...

Je suis pas loin d'être certain que si on donnait un cours de POO à un jeune, n'ayant jamais fait de programmation, quand on en viendrait au concept des classes abstraites, par exemple, il nous demanderait quelque chose du genre : "beuh ? à quoi ça sert ce machin là si je peux pas l'instancier ? A me faire pisser du code en plus pour rien ??"

Et plus tard, quand on lui parlerait d'interfaces : "hein ? mais ça sert à quoi ce machin, on peut même pas mettre d'algorithme dedans... ??!?"

La POO c'est bien, ça structure davantage le programme et le rend "plus humain", disons, mais ça demande une sacrée dose de recul par rapport aux choses quand même.

J'allais vous poser une question : "Et lui faire faire de la POO, oui, mais dans quel but ? On programme pas sans raisons."...
C'est vrai que le but ici est d'enseigner, donc d'une certaine manière je réponds moi-même à ma question. Mais tout de même : programmer sans raisons, c'est quelque chose que j'ai toujours trouvé pénible.
D'ailleurs je vivais assez mal le fait que mes beaux programmes faits durant contrôles TP finissaient à la poubelle, et je vivais encore plus mal le fait que ces programmes ne servaient strictement à rien.

Actuellement, sur le forum general dotnet, y'a un gars qui demande "que programmer ?", dans une optique d'apprentissage, visiblement. Et il demande à faire quelque chose d'utile, pas un hello world merdique de 50 lignes programmé tout en objet.

A mon avis, je sais que je sors un peu du cadre du débat, mais une autre question concernant l'enseignement de la prog pourrait être posée : enseigner via des algorithmes simples, "unitaires" (genre : factorielle, tri, etc...), ou bien enseigner via des projets de plus grande envergure nécessitant plein de petits algorithmes "simples et unitaires" ?

[Luc Hermitte]

Le débat me semble un peu faussé. N'oubliez pas, et je crois bien que cela a déjà été dit, la POO dans beaucoup de langages est batie autour de l'impératif. Vous savez. Quand "inst1; inst2;" exécute l'instruction une puis la deux.

Opposez POO à impératif ne me parait pas avoir pas grand sens, vu que les opérations seront implémentées à l'impérative (dans les principaux langages OO du marché dont certains ont été cités).

[outs]

Envoyé par davcha

C'est bien beau de faire Porte.Ouvrir(); au lieu de Ouvrir(Porte);, mais ça n'est rien de plus qu'une syntaxe différente.
Porte.Ouvrir(); n'est, en soi, pas fondamentalement différent, ni "davantage objet" que Ouvrir(Porte);. La seule réelle différence à ce niveau là, c'est que dans Porte.Ouvrir();, le paramètre formel se trouve devant la méthode/fonction.

Je suis pas d'accord. La version POO est bcp plus naturelle. Toi tu dis qu'il n'y a pas de différence mais c'est pasque tu es déjà un programmeur averti et maitrisant plusieurs paradigmes.

Moi je trouve beaucoup plus simple a expliquer à un néophite la methode ouvrir est rattachée a une porte et n'a pas d'existance sans elle, que une procédure ouvrir qui se ballade dans le vide comme ça.

Envoyé par davcha

Faut pas oublier que la POO c'est aussi (surtout), le polymorphisme d'inclusion. Qui irait expliquer à quelqu'un n'ayant jamais programmé l'utilité des interfaces, des mots clefs comme protected, virtual, abstract...

Cet argument est fallacieux, il est évidement qu'il ne faut pas commencer par les choses les plus évolués mais par les bases. Et la base ce n'est pas le polymorphisme d'inclusion c'est le fait que tu définis une entité sur lequel des méthodes sont réalisables.

C'est plus naturel que de se focaliser sur les traitements comment en programmation impératives (qui contient aussi un bon paquet de concepts compliqué comme les pointeurs par exemples)

Sinon j'ai un autre sujet de débat secondaire, quel langage serait le plus approprié pour l'enseignement (pour l'impératif ainsi que pour la POO) selon vous ? (attention sujet a haute teneur en troll ... (désolé mais c'est évidement important))

[Hephaistos007]

Envoyé par outs

Sinon j'ai un autre sujet de débat secondaire, quel langage serait le plus approprié pour l'enseignement (pour l'impératif ainsi que pour la POO) selon vous ? (attention sujet a haute teneur en troll ... (désolé mais c'est évidement important))

Pour l'enseignement de quoi d'abord ?

Si tu fais du système, il y a pas de débat, tous le monde fais du C/C++
Si tu fais de l'algo (ce qui est sous-entendu par ta question je suppose), les universités sont friantes de Pascal ainsi que ADA95.
Ce sujet a déjà été traité 1000 fois et comme d'hab, tous les langages qui existent seront cités, et tu sera pas plus avancé.

[HanLee]

Envoyé par outs

Moi je trouve beaucoup plus simple a expliquer à un néophite la methode ouvrir est rattachée a une porte et n'a pas d'existance sans elle, que une procédure ouvrir qui se ballade dans le vide comme ça.

Je sais pas, on a presque tous un tire-bouchon à la maison, qui sert à enlever les bouchons des bouteilles de vin.

Le tire bouchon (<=> fonction/procédure) peut très bien être chez toi sans que tu aies de bouteille de vin (l'objet/structure en paramètre), c'est ta responsabilité de ne pas faire mauvais usage du tire-bouchon .

[Hephaistos007]

J'ai pas compris ton exemple. Qu'est ce qui te choques ?

[Matthieu Brucher]

Envoyé par outs

Je suis pas d'accord. La version POO est bcp plus naturelle. Toi tu dis qu'il n'y a pas de différence mais c'est pasque tu es déjà un programmeur averti et maitrisant plusieurs paradigmes.

Moi je trouve beaucoup plus simple a expliquer à un néophite la methode ouvrir est rattachée a une porte et n'a pas d'existance sans elle, que une procédure ouvrir qui se ballade dans le vide comme ça.

J'étais aussi partisant du tout fonction membre, et en fait j'ai pas mal changé. Je ne mets une fonction en membre que lorsqu'elle est complètement interne ou qu'elle appelle des mécanismes internes, le reste est en externe - cf Stutter, Alexandrescu, ... -

[HanLee]

Envoyé par Hephaistos007

J'ai pas compris ton exemple. Qu'est ce qui te choques ?

Bah le tire bouchon qui est chez toi alors que ta pas de bouteille de vin, c'est comme la procédure qui se balade dans le vide, attendant en vain une objet en paramètre.

Et outs a dit qu'un débutant aurait plus de mal à appréhender ça qu'un objet et sa fonction membre qui iraient toujours de paire, c'est à dire des bouteilles de vin toujours fournies avec le tire-bouchon pour les ouvrir!

[outs]

Et la marmotte ...

On peut très facilement programmer en procédural en POO et vous le savez très bien. Le contraire necessitant nettement plus de travail.

Personne n'a dis qu'un paradigme était parfait pour tout.

Ce que l'on prétend c'est que la POO est bien plus utile pour la grande majorité des cas. De plus ses capacités d'abstraction et de représentation sont bien plus évolué, et c'est ceci que le rend plus simple a comprendre.

[HanLee]

Envoyé par outs

Et la marmotte ...

On peut très facilement programmer en procédural en POO et vous le savez très bien. Le contraire necessitant nettement plus de travail.

Personne n'a dis qu'un paradigme était parfait pour tout.

Ce que l'on prétend c'est que la POO est bien plus utile pour la grande majorité des cas. De plus ses capacités d'abstraction et de représentation sont bien plus évolué, et c'est ceci que le rend plus simple a comprendre.

Bah j'suis pas foncièrement en désaccord avec toi...
C'est juste que sur l'exemple ...

[Hephaistos007]

Oui mais ton exemple ne l'illustre en rien HanLee. Ce que soulignait implicitement outs, c'est qu'il est plus intuitif de coupler les comportements avec les objets concernés. C'est un apport majeur de l'objet.

La porte est un objet, ouvrir est son comportement. Donc l'OO impose laPorte.ouvrir();

Dans ton exemple, le tire bouchon est un objet, l'ouverture est son comportement (qui effectivement prend un autre objet en paramètre : la bouteille). Donc l'OO impose leTireBouchon.ouverture(Bouteille);

Et alors ? le comportement (ouverture) ne traine pas tout seul dans le code, il est bien lié à l'objet concerné (le tire bouchon). Maintenant, qu'il y est une bouteille ou non cela n'a rien à voir. Tu as a confondu.

[Franck.H]

Je pense que le meilleur compromis qu'on puisse avoir dans le cas de la question initiale, c'est en fait de n'étudier que Python qui reste néanmoins multi paradygme et peut être un langage assez facile à apprendre ... même pour un premier langage (voir le cours de Gérard Swinnen) !

Il n'impose pas d'utiliser strictement que de la POO donc pour une premiere approche de la programmation commencer simplement en procédural puis par la suite voir la côté objet du langage ... de plus il intègre TKinter qui permet de faire des IHM (meme si leur design reste plus que moche mais c'est déjà ca de pris) donc tu peux même par la suite leur donner des cours sur ce sujet !

Je pense que ca reste un très bon compromis ... à méditer !

[Hephaistos007]

Pourquoi dans ce cas Python n'est pas utilisé dans le monde académique ? (c'est une question, je n'ai pas la réponse)

[Jean-Marc.Bourguet]

J'ai deja ecrit que je ne voyais pas comment faire de la POO sans avoir au moins quelques bases de programmation imperative, l'aspect OO etant dans generalement une couche de structuration ajoutee a un noyau imperatif (le seul langage que je vois pour lequel on peut discutter de cette vision des choses, c'est SmallTalk ou meme if/then est un message envoye a un bool). Je n'ai pas vu de reponse la dessus, sauf Luc qui a l'air d'etre du meme avis.

Un mot important ci-dessus est structuration, je vois la POO comme un moyen de structurer les programmes (ou des parties de ceux-ci) et pour voir l'interet de la POO, il faut etre en contact avec des programmes suffisemment gros pour que la structure POO apporte quelque chose. Et sincerement, j'ai du mal a voir comment un cours peut commencer par des programmes de cette taille avec des gens qui n'ont aucune notion de programmation.

Au fait, la vision du monde OO pure, me semble deformer le monde; c'est une technique de structuration utile, mais il y a des choses qui ne sont pas aisement structuree de cette maniere. Et les langages OO "pur" ont tendance a ne pas permettre d'autres couches de structuration meme quand elles sont les plus pertinentes. Par exemple, j'ai du mal a voir a quel objet il faut l'attacher un calcul de plus court chemin sur un graphe. Pour moi, c'est par contre un bon exemple de necessite de fonctions libres generiques (et il me semble plus facile de montrer l'interet de la genericite que de montrer l'interet de la POO).

[cedric49fr2000]

Faut tout de meme admettre que l'on a imagine le tire bouchon (enfin l'objet sous cette forme ) pour ouvrir des bouteilles, pas pour nettoyer un tuyau ou pour "eventrer" son voisin. on peux toujours faire autres choses avec un objet destine a un usage precis.

comme on peux parfaitement herite d'une classe pour obtenir sa methode et oublie ses autres constituants. c'est aussi aberent que de vouloir ouvrir une porte avec un tire bouchon plutot qu'une clef.

cedric

[outs]

Envoyé par Jean-Marc.Bourguet

J'ai deja ecrit que je ne voyais pas comment faire de la POO sans avoir au moins quelques bases de programmation imperative, (...) c'est SmallTalk ou meme if/then est un message envoye a un bool).

Faut pas confondre les structures de contrôles impératives et le procédural. La POO ne rejette pas l'impératif. (d'ailleurs le procédural non plus, il est juste remplacé par quelque chose de plus intéressant dans la plupart des cas). Le sondage dit "uniquement POO pendant deux ans" mais c'est mal dit : l'impératif fait partit de l'objet ce n'est pas le problème.

Envoyé par Jean-Marc.Bourguet

il faut etre en contact avec des programmes suffisemment gros pour que la structure POO apporte quelque chose

Pas besoin, il y a un gros paquet de leçon classiques d'algorithmiques pour débutant qui s'illustrent très bien avec la POO comme par exemple : les nombres (un exo sur les complexes par exemples), les fractions, les piles, les files, les tableaux etc. Avec evidement les algo qui vont avec mais exprimés avec les méthodes fondamentales de chaques structures de données, c'est la tout l'intéret de l'approche.

Regarde il suffit de prendre le Cormen : une bonne partie des descriptions sont très très proches de ce que l'on fait en objet. (j'ai la flemme d'aller chercher le bouquin pour citer les pages dsl ...)

Et pour le calcul du plus court chemin dans un Graphe suffit de la rattacher a Graphe. Je suis d'accord que ce n'est pas optimal et que ce genre de chose est mieux dans une bibliothèques utilitaire séparée. Mais ce n'est pas la peine d'embeter les débutants avec ca dans un premier temps. J'ai l'impression que tout le monde voit la POO comme quelque chose de très complexe. C'est vrai que le travail que l'on fait avec la POO pour la plupart d'entre nous est complexe, mais n'oubliez pas qu'a la base et sur des exemple de débutant on n'a pas besoin d'utiliser les concepts les plus évoluées.

Et l'immense avantage de la POO est, comme Jean-Marc l'a dit, d'aider a structurer. Et quand on apprend avec juste l'impératif on prend des mauvaises habitudes qu'il est difficile de briser par la suite. C'est pour cela que je pense qu'il faut tout de suite donner une vision proche de l'objet.

[outs]

Envoyé par Franck.H

Je pense que [Python] reste un très bon compromis ... à méditer !

Difficile de donner un apprentissage clair si le prof fait des compromis et des mélanges entre des méthodologies différentes. Je pense que c'est le pire. Il faut choisir.

Je ne prend pas le procédural comme le mal absolu (même si j'en donne l'air ). C'est juste que si l'élève continu dans l'info alors il tombera forcement sur l'objet puisque c'est le courant majeur. Alors autant partir sur de bonnes bases, de plus l'objet a des vertues pédagogiques. A condition évidement d'extraire le plus pertinent pour un cours d'initiation.

[davcha]

Envoyé par outs

Et l'immense avantage de la POO est, comme Jean-Marc l'a dit, d'aider a structurer. Et quand on apprend avec juste l'impératif on prend des mauvaises habitudes qu'il est difficile de briser par la suite. C'est pour cela que je pense qu'il faut tout de suite donner une vision proche de l'objet.

Et c'est ce que je voulais dire avec mon message de l'autre jour : comment veux-tu apprendre les gens à structurer des programmes s'ils n'ont aucune notion de programmation ?

C'est un peu comme apprendre à dessiner les plans d'un immeuble sans avoir appris les notions de côte, distances, contraintes des matériaux etc...
Y'a fort à parier que l'immeuble s'envolera au premier éternuement d'hirondelle.

[outs]

Je vois vraiment pas ou est le problème, c'est en faisant des erreurs que l'on apprend.

Enfin bref je pense avoir suffisament détaillé mon point de vue, après tu pense ce que tu veux Je vais pas monopoliser le fil de discussion.