Mon avis sur la question du rapport entre algorithmique et structures données est assez partagé.

Primo, parce que les structures de données, si importantes et fondamentales soient elles, ne sont quand même pas tout en algorithmique.
Secundo, parce qu'il est raisonnable de penser qu'il y a un rapport entre algorithmique et possibilité, j'entends que l'algorithmique reste finalement conditionnée par les possibilités d'un contexte donné (ainsi on pourrait séparer "algorithmique pour humains" d'"algorithmique pour ordinateur", par exemple).

Il peut être extrêmement intéressant de comparer les approches différentes pour résoudre un même problème selon le langage employé. Et nul besoin de chercher des exemples très loin pour cela.

Reste tout de même que les structures de données sont effectivement fondamentales dans la formation à l'algorithmique, et que les restrictions de certains langages (devoir tout recoder en C, absence de certaines en Python par exemple) sont effectivement des inconvénients.

PS :
Au fait, il y a des "vrais" array en Scheme (acces en O(1)) ? La doc sur les vector est plutôt floue à ce sujet, il est simplement écrit :

Citation : R6RS

Vectors are heterogenous structures whose elements are indexed by integers. A vector typically occupies less space than a list of the same length, and the average time required to access a randomly chosen element is typically less for the vector than for the list.

En ce qui concerne le while True, je trouve que c'est un faux problème et certainement pas un argument en défaveur de Python.

D'une part, Python ne force jamais personne à utiliser ce type de boucles infinies, c'est faux. En fait, d'une façon générale, je n'utilise quasiment jamais de boucles while tout court : le for couplé au système d'itérateurs et d'expressions génératrices sont suffisamment puissants pour me convenir la plupart du temps, en plus d'être plus pythoniques. La seule situation dans laquelle on est obligé d'utiliser une boucle infinie en Python, c'est lorsque l'on veut gérer un système d'événements à pile de façon explicite comme dans Pygame, mais là encore je trouve que cette façon de faire tient plus d'un héritage malheureux de la SDL, que les développeurs de Pygame devaient probablement utiliser intensivement, que d'une limitation du langage : il n'y a qu'à voir le système d'observateurs extrêmement élégant de Pyglet pour appréhender des façons de faire "orientées objet" et bien plus souples que la boucle évènementielle explicite.

Citation : FirstZero

Après j'ai préciser pourquoi le C ainsi que le C++. Certes en lisant le C t'auras un gros brouillard. C'est pas grave si t'a pas tout compris de suite. Tu verras qu'une fois deux trois applications consoles faites (pas très grandes ) et surtout ton passage au C++, tout va s'éclarcir (en tout cas sa a été mon cas).

Non mais ça n'a rien à voir : C et C++ sont complémentaires par rapport à Python. La différence de complexité et de confort d'utilisation est réelle, et elle se mesure en jours.homme sur le développements d'outils un peu poussés. L'intérêt de la simplicité de Python n'est pas seulement sur sa courbe d'apprentissage, mais aussi sur le temps et les efforts que cela prend pour développer une application donnée, modulo la question des performances qui ne se pose pas si souvent que ça.

Citation

Au pire, je comprends que le C/C++ sont très compliqué, je ne peux pas le nier. Je vais donc te conseiller autre chose (à part si t'a été d'accord ). Cette autre chose est le Java. Sa syntaxe est clair, tout est objet DÈS LE DÉPART (très important) et puis c'est suffisament bas niveau pour que tu puisse tout gérer

Mon dieu, cette envie de troller !

Java n'est pas plus simple que C et C++. Sa syntaxe n'est PAS plus claire (elle est au contraire encore plus verbeuse que celle du C++), et il est complètement faux de dire que tout est objet en Java : les types natifs comme int ou double ne le sont pas. Par ailleurs depuis quand tu peux gérer explicitement ta mémoire en Java de façon correcte (c'est-à-dire sans faire appel explicitement au garbage collector) ?

Je n'utilise pas R6RS, donc je ne sais pas trop pour ce standard. En Racket, la doc dit bien :

Citation : Racket Documentation

A vector is a fixed-length array with constant-time access and update of the vector slots [...].

EDIT :

R6RS dit ceci :

Citation : R6RS

Whereas the elements of a list are accessed sequentially through the chain of pairs representing it, the elements of a vector are addressed by integer indices. Thus, vectors are more appropriate than lists for random access to elements.

Même si c'est pas dit clairement, je pense qu'on peut considérer que l'accès aux éléments se fait en temps constant.

Je dépile un truc -- même si dans l'ensemble, je suis rassuré que vous voyez aussi une partie des choses que je reproche.

Citation : candide

a-

Citation : fred1599

Pour une personne n'ayant jamais vu ce qu'était la programmation, c'est totalement inadapté et incompréhensible (syntaxe) [C]

Peux-tu être plus précis ? De quelle syntaxe incompréhensible parles-tu ? Moi j'avais trouvé que la syntaxe du C était compliquée à partir des pointeurs. Bon avant, y'avait des choses que j'avais pas trouvé totalement claires comme quand mettre un point virgule ou pas le mettre, en particulier avec les instructions composées (if, while, for).

b-

Citation : lmghs

Les conséquences ? Les étudiants apprennent les idiomatismes sans même s'en rendre compte. Et cerise sur le gâteau : le code que l'on utilise pour les former est plus simple et donc ils retiennent mieux les leçons.
C'est gagnant-gagnant sur toute la ligne.

Non, ça c'est une vue de l'esprit. Un idiomatisme, c'est un automatisme qui s'acquiert après un travail de répétition et compréhension (un idiomatisme est souvent -- pas toujours -- cryptique parce que justement il est propre à l'idiome et donc il n'a rien de naturel ; un idiomatisme doit être compris car on a souvent des idiomatismes paramétrés et si l'idiomatisme n'est pas compris, on reste à des versions restreintes de l'idiomatisme).


c-

Citation : lmghs

Je suis dans la continuité de mon paragraphe précédent : les fondement de comment écrire des codes qui ne tournent pas au pays magique où tout va toujours bien.

OK, tu veux donc parler de connaissance approfondie, le prix fort de l'apprentissage.

d-

Citation : lmghs

Regarde les tutos sur les listes chainées. Les échecs d'allocation se sont pas propagés jusqu'à l'utilisateur.. Ou encore le tuto sur les chaines à taille variables qui enseigne exit(FAILURE) sur les échecs d'allocation...

Ça ne me choque pas plus que ça, c'est volontairement schématique, le but étant d'apprendre le concept de listes chaînées. Un enseignant doit masquer certaines connaissances pour éviter la surcharge.

a- Ou pourquoi on critique le C comme premier langage, et moins le C++.
En C les pointeurs sont un passage obligatoire dès les premiers chapitres. Pas en C++, ni en Pascal, ni en Ada, ni ...
Accessoirement, la syntaxe pour utiliser les pointeurs en Pascal ou en Ada n'a rien à envier à celle du C (en matière d'obfuscation)

Quand on parle de syntaxe incompréhensible, je ne vois pas l'intérêt des ':' à la fin des if en python -- quand on compare à tous les autres langages qui s'en passent très bien.
Mais bon, ce n'est pas important, la vraie difficulté d'un langage n'est pas la syntaxe mais les concepts qui doivent être maitrisés pour réaliser des applications. Trop de complexes non triviaux sont exigés dès le début de la phase d'apprentissage en C.

b- Ouais enfin, entre un cours qui montre "char ch[80]; cin >> ch;/scanf("%s", ch);" et "std::string ch; cin >> ch;"
Il y a une écriture idiomatique et une catastrophique. Apprendre l'idiomatique ne coute rien.
Pareil entre les vecteurs et les tableaux.
Et le jour où il y aura besoin de comprendre les subtilités, l'ancien élève sera prêt.

c- Non, je parle de coder correctement.
Le C ne permet pas d'enseigner en toute tranquillité à produire du code correct et robuste. Les autres langages oui.

d- Voilà, et l'étudiant apprend à faire et à utiliser une brisque bancale. Dans d'autres langages, tu aurais appris à faire et à utiliser une brique robuste.
(cf l'article donné en lien dans cette réponse de FAQ: http://www2.research.att.com/~bs/bs_faq.html#prerequisite ).


e- Concernant définition précise ou pas, je suis dans le camp des "pas". Les définitions sont souvent passées à la trappe et absolument pas maitrisées. Souvent savoir manipuler est plus important. Cela n'empêche pas de rajouter des encarts (/notes de fin de page) pour dire où trouver plus d'infos.
Par exemple, entre comprendre très précisément le LSP, et savoir distinguer EST-UN(-TRUC-UTILISABLE-EN-PLACE-DE) avec UTILISE-UN, le second suffit amplement.

Citation

Mais bon, ce n'est pas important, la vraie difficulté d'un langage n'est pas la syntaxe mais les concepts qui doivent être maitrisés pour réaliser des applications. Trop de complexes non triviaux sont exigés dès le début de la phase d'apprentissage en C.

T'as été étudiant en informatique, c'est sûr! La syntaxe est hyper importante pour un mec qui a jamais vu la programmation de sa vie, ça c'est du vécu, je te l'assure. En ce qui me concerne maintenant, la syntaxe m'importe peu, mais débutant c'est primordiale.

Ils se trouvent que quand j'avais fais du C, (c'est perso) les ";" et les "{}" étaient moins parlant que les ":" de python.

Mais il faut revenir sur un point très important. J'étais débutant et n'avait aucune théorie en programmation.

Après quelques années avec python, j'ai pu (re)découvrir quelques langages dont le C, et certaines choses se sont éclairées.

Si on reste dans le sujet principal, c'est en tant que débutant qu'on ne propose pas le C, mais ce qui m'a rébuté principalement était tout de même la syntaxe, je trouve cela tout de même important, avant même les concepts du C.

Ce que je conseillerais à un débutant c'est un langage dont la syntaxe lui paraît simple, facile à comprendre et surtout lui donnant une impression de "à tiens, j'aurais pu le deviner, c'est logique!"

Il est important aussi pour le débutant de pouvoir tester quelques petites lignes de code, pour voir quel résultat, tel ligne de code peut donner "A la vache! c'est ça que fait cette ligne, c'est cool, je dormirais moins bête ce soir, demain je rajoute cette ligne et celle-ci, et je suis sûr que ça donnera ce résultat."
Un peu dur à faire en C, non?

Citation : fred1599

Si on reste dans le sujet principal, c'est en tant que débutant qu'on ne propose pas le C, mais ce qui m'a rébuté principalement était tout de même la syntaxe, je trouve cela tout de même important, avant même les concepts du C.

Ce que je conseillerais à un débutant c'est un langage dont la syntaxe lui paraît simple, facile à comprendre et surtout lui donnant une impression de "à tiens, j'aurais pu le deviner, c'est logique!"

Ton avis est totalement subjectif, il me semble. Moi non plus n'ai jamais été étudiant en info, et la syntaxe de C ne m'a jamais posé problème. Mais je suis d'accord que certaines syntaxes plus ou moins "ésotériques" peuvent donner du mal.

Citation : fred1599

Il est important aussi pour le débutant de pouvoir tester quelques petites lignes de code, pour voir quel résultat, tel ligne de code peut donner "A la vache! c'est ça que fait cette ligne, c'est cool, je dormirais moins bête ce soir, demain je rajoute cette ligne et celle-ci, et je suis sûr que ça donnera ce résultat."

Quel que soit le langage, on apprends beaucoup par ses expérimentations. Je dis parfois que l'un de mes meilleurs profs de C est GCC. L'avantage d'avoir un interpréteur est que ce genre d'utilisation est beaucoup plus immédiat. Couplé avec un bon système de rapport d'erreurs, des exceptions claires et explicites, c'est un atout indéniable pour l'apprentissage.

Citation : yoch

Ton avis est totalement subjectif

Pour la syntaxe C, non! Je dirais que tu es une des exceptions approuvant le fait que la syntaxe C ne pose pas de problème

Si on généralise c'est plutôt le contraire qui se passe, j'ai pas de statistiques, mais on voit cela assez souvent dans les forums.

Citation : yoch

Quel que soit le langage, on apprends beaucoup par ses expérimentations. Je dis parfois que l'un de mes meilleurs profs de C est GCC. L'avantage d'avoir un interpréteur est que ce genre d'utilisation est beaucoup plus immédiat. Couplé avec un bon système de rapport d'erreurs, des exceptions claires et explicites, c'est un atout indéniable pour l'apprentissage.

Et donc, est-ce que le C permet ce type d'apprentissage? Tu en déduis?

Citation : fred1599

Pour la syntaxe C, non! Je dirais que tu es une des exceptions approuvant le fait que la syntaxe C ne pose pas de problème
Si on généralise c'est plutôt le contraire qui se passe, j'ai pas de statistiques, mais on voit cela assez souvent dans les forums.

Pas du tout. Sur ce fil même, au moins un intervenant a mentionné qu'il trouve la syntaxe de Python "spéciale" (je n'ai plus le terme exact), et à part toi il n'y a pas grand monde pour critiquer la syntaxe globale du C (pointeurs hormis). C'est pourquoi j'ai qualifié ton avis de subjectif.
Personnellement les deux syntaxes ne me posent aucunement problème.

Si je devais critiquer la syntaxe du C, je mentionnerais peut-être certaines incohérences, mais pas le fait qu'elle soit difficile ou contre-intiutive en soi. (je vais prendre un exemple pour faire concret: déclarer les types me parait plus clair pour un débutant que le système de typage dynamique de Python).

Citation : fred1599

Citation : yoch

Quel que soit le langage, on apprends beaucoup par ses expérimentations. Je dis parfois que l'un de mes meilleurs profs de C est GCC. L'avantage d'avoir un interpréteur est que ce genre d'utilisation est beaucoup plus immédiat. Couplé avec un bon système de rapport d'erreurs, des exceptions claires et explicites, c'est un atout indéniable pour l'apprentissage.

Et donc, est-ce que le C permet ce type d'apprentissage? Tu en déduis?

En fait, je venais appuyer ton argument, tout en soulignant que le C permet ce type d'apprentissage, mais dans une moindre mesure (erreurs moins parlantes, erreurs d’exécutions silencieuses ou mystiques), de façon moins naturelle (compiler un code avec un main() et tout pour tester si ça compile ou pas, bof comme tu dis), et moyennant parfois une certaine maitrise de l'outil (réglages de compilation).

Néanmoins, je reste d'avis que l'expérimentation est une excellente pratique pour apprendre, et devrait dans doute être plus développée dans les cours (notamment, pour le C, au niveau de la maitrise du compilateur et ses options), en tous cas tout au moins mentionnée.

Citation : yoch

Quel que soit le langage, on apprends beaucoup par ses expérimentations.

Absolument, mais pour arriver à ce stade, il faut déjà être avancé et avoir une certaine confiance en soi, avoir un certain recul et même une certaine autonomie. L'immense majorité des débutants n'osent pas essayer, et ça se comprend, la plupart du temps, ils ne sauraient pas quoi écrire. En les supports d'apprentissage n'incitent pas du tout à ça : les supports d'apprentissage ont très souvent un discours abstrait, ils proposent peu de codes (des codes incomplets et décontextualisés) et peu de vrais exemples, ils incitent à la paralysie et au manque d'initiative.

Citation : fred1599

Pour la syntaxe C, non! Je dirais que tu es une des exceptions approuvant le fait que la syntaxe C ne pose pas de problème

Franchement, je ne vois pas comment on peut dire lorsqu'on a eu des difficultés pour apprendre un langage (et surtout si on était débutant!) que la difficultés proviennent spécifiquement de la syntaxe. Il est très difficile de dissocier les difficultés venant de la syntaxe, de celle venant de la sémantique, et de la pragmatique, voire de l'algorithmique ou du paradigme du langage. Par exemple, une des difficultés du C est la distinction entre tableaux et pointeurs. La syntaxe joue un rôle, et encore assez peu, la sémantique beaucoup plus, bon de toutes façons, les rôles de deux sont très imbriqués. Par contre ce qui est possible, c'est que certaines expressions du C, par exemple certaines déclarations de fonctions (lire dans signal.h certaines qui sont assez tordues), sont difficiles à décoder pour un humain, bon parfois peu intuitive. Mais ce n'est pas vraiment de la faute du langage, c'est surtout de la faute de ceux qui conçoivent les manuels d'apprentissage.

Citation : fred1599

Citation : yoch

Ton avis est totalement subjectif

Pour la syntaxe C, non! Je dirais que tu es une des exceptions approuvant le fait que la syntaxe C ne pose pas de problème

Si on généralise c'est plutôt le contraire qui se passe, j'ai pas de statistiques, mais on voit cela assez souvent dans les forums.

Citation : yoch

Quel que soit le langage, on apprends beaucoup par ses expérimentations. Je dis parfois que l'un de mes meilleurs profs de C est GCC. L'avantage d'avoir un interpréteur est que ce genre d'utilisation est beaucoup plus immédiat. Couplé avec un bon système de rapport d'erreurs, des exceptions claires et explicites, c'est un atout indéniable pour l'apprentissage.

Et donc, est-ce que le C permet ce type d'apprentissage? Tu en déduis?

Je ne pense pas qu'il parle du C++ dont les messages sont réputés peu lisibles et verbeux Il parle peut-être de Python Par ailleurs, la phrase de yoch n'est pas très claire : est-ce le système d'expérimentation par gcc qui est un atout indéniable pour l'apprentissage ou est-ce l'interpréteur ?

Sinon, oui, il existe des interpréteurs C et cela peut même un bon moyen d'apprendre certains éléments du langage.

Citation : candide

Je ne pense pas qu'il parle du C++ dont les messages sont réputés peu lisibles et verbeux Il parle peut-être de Python Par ailleurs, la phrase de yoch n'est pas très claire : est-ce le système d'expérimentation par gcc qui est un atout indéniable pour l'apprentissage ou est-ce l'interpréteur ?

Pas claire du tout, même, en me relisant. Je précise ma pensée :

Citation

Quel que soit le langage, on apprends beaucoup par ses expérimentations. Je dis parfois que l'un de mes meilleurs profs de C est GCC.
L'avantage d'avoir un interpréteur à sa disposition dans certains langages comme par exemple Python est que ce genre d'utilisation est beaucoup plus immédiat. Couplé avec un bon système de rapport d'erreurs, des exceptions claires et explicites, c'est un atout indéniable pour l'apprentissage. Ce n'est malheureusement pas du tout le cas du langage C.

Citation

En fait, je venais appuyer ton argument,

J'avais bien compris, je voulais simplement revenir au post de départ. Est-ce que le C est un langage pour de vrai débutant?

Citation

Franchement, je ne vois pas comment on peut dire lorsqu'on a eu des difficultés pour apprendre un langage (et surtout si on était débutant!) que la difficultés proviennent spécifiquement de la syntaxe.

Si tu sais parler français, et que tu veux rechercher une définition dans le dictionnaire pas de soucis, mais si tu ne comprends pas le français, comment tu fais avec ton dico?

Une bonne maîtrise de la langue, permet de comprendre, apprendre et progresser de façon exponentielle, alors que le contraire te demande un double effort.

Maintenant les concepts, font que l'on rajoute une difficulté supplémentaire aux débutants et les pointeurs, c'est vrai, ça fait très mal.

Dire au débutant que le pointeur est un espace mémoire pouvant contenir une adresse, ça aide vachement le débutant

Donc le mec qui apprend le C seul, doit connaître du vocabulaire.

En python ou autres, on ne se préoccupe pas de tout ce vocabulaire, et c'est pour ça que je dis que le C n'est pas fait pour le débutant.

Edit : Quand je dis "on ne se préoccupe pas de tout ce vocabulaire", je parle du vocabulaire en rapport avec la machine.

Je vais parler par expérience (même si celle-ci n'est pas longue)
Au tout début, j'ai appris le langage C. Cela a été dur en effet, mais surmontable. On apprend beaucoup de choses, comme tu le disais Fred1599,

• - "Le pointeur est un espace mémoire pouvant contenir une adresse"
• - "Une chaîne de caractères et un tableau contigu en mémoire qui prend généralement 1 octet par cellule. Chaque cellule à son adresse mémoire."

C'est très intéressant et cela te permet de voir ce qu'il se passe (ou plutôt une partie )lorsque tu fais telle ou telle chose.
Il est bénéfique de commencer par le langage C, quitte à le laisser tomber après quelque mois, parce qu'il te forme.
Lorsque je suis passé du C à Python, j'ai vraiment été surpris que ce dernier était "moins emmerdant" pour coder. (Je prends les devants en précisant que j'aime le langage C, ne vous imaginez pas le contraire)

Pour faire une comparaison, le langage C c'est comme l'armée, c'est formateur !
En conséquence, je dis OUI, je suis pour apprendre le langage C en premier.

Citation : realmagma

[...] On apprend beaucoup de choses, comme tu le disais Fred1599,

• - "Le pointeur est un espace mémoire pouvant contenir une adresse"
• - "Une chaîne de caractères et un tableau contigu en mémoire qui prend généralement 1 octet par cellule. Chaque cellule à son adresse mémoire."

C'est très intéressant et cela te permet de voir ce qu'il se passe (ou plutôt une partie )lorsque tu fais telle ou telle chose.

Il me semble que fred1599 était ironique, donc en fait tu prends le contrepieds.

Citation : realmagma

Il est bénéfique de commencer par le langage C, quitte à le laisser tomber après quelque mois, parce qu'il te forme.
[...]
Pour faire une comparaison, le langage C c'est comme l'armée, c'est formateur !
En conséquence, je dis OUI, je suis pour apprendre le langage C en premier.

Franchement, je trouve ta thèse intéressante, mais limitée à un certain cadre d'apprentissage : des personnes qui cherchent à comprendre "comment ça marche", et pas seulement à programmer.

EDIT : un petit texte intéressant, avec en appendice un mot sur le choix d'un langage. (Peter Norvig est directeur de recherche chez Google)

Citation : fred1599

Si tu sais parler français, et que tu veux rechercher une définition dans le dictionnaire pas de soucis, mais si tu ne comprends pas le français, comment tu fais avec ton dico?

Une bonne maîtrise de la langue, permet de comprendre, apprendre et progresser de façon exponentielle, alors que le contraire te demande un double effort.

Maintenant les concepts, font que l'on rajoute une difficulté supplémentaire aux débutants et les pointeurs, c'est vrai, ça fait très mal.

Mais ça je n'en disconviens pas, et d'ailleurs, je trouve que beaucoup trop de cours se livrent à des intellectualisations prématurées. Ce que je conteste c'est l'incrimination de la syntaxe :

1°) un débutant en C n'a pas la compétence pour juger si ses difficultés viennent de la syntaxe du langage C
2°) la syntaxe d'un langage de programmation n'est qu'un petit élément dans la compréhension d'un langage.

D'un point de vue très subjectif, je ne trouve pas que la syntaxe du langage C soit spécialement repoussante. La polysémie de certain opérateurs (comme *) peut rendre le déchiffrement difficile. Certaines déclarations permissives (de structures, de typedef par exemple) peuvent être assez difficiles à digérer. Et certaines déclarations peuvent être très complexes, exemple la signature de qsort, ou la fonction standard bien connue suivante :

void (*signal(int sig, void (*handler)(int sig)))(int sig);

Citation : fred1599

Donc le mec qui apprend le C seul, doit connaître du vocabulaire.

Dans les faits oui. Mais, ça n'a rien d'obligatoire

Citation : fred1599

En python ou autres, on ne se préoccupe pas de tout ce vocabulaire, et c'est pour ça que je dis que le C n'est pas fait pour le débutant.

Edit : Quand je dis "on ne se préoccupe pas de tout ce vocabulaire", je parle du vocabulaire en rapport avec la machine.

Avec la machine ? Je vois pas où en a besoin en C. Mais du vocabulaire (et du jargon) en Python, tu en as un max, regarde les manuels qui expliquent la POO, c'est particulièrement hermétique à cause d'une accumulation de termes très techniques et abstraits, le C est très très sage en regard.

Citation : candide

Mais du vocabulaire (et du jargon) en Python, tu en as un max, regarde les manuels qui expliquent la POO, c'est particulièrement hermétique à cause d'une accumulation de termes très techniques et abstraits, le C est très très sage en regard.

Sur ce point je suis tout à fait d'accord avec toi : je ne suis jamais tombé sur un manuel capable de très bien expliquer la POO à un débutant complet. J'ai d'ailleurs un peu réfléchi sur le sujet et j'en suis arrivé aux points suivants :

* Des langages d'apprentissage de la POO pas toujours adaptés. On pourra dire ce que l'on veut, Java et C++ ne sont pas adaptés pour faire comprendre la POO à un débutant. Le fait que le débutant doive d'abord comprendre la syntaxe relativement complexe et surtout verbeuse de ces langages (C++ remporte la palme) est selon moi un frein. Nécessairement, si l'attention du débutant est portée sur la syntaxe, c'est autant de concentration qu'il perd sur l'aspect conception (et la conception, c'est le cœur de la POO).

* Des explications trop abstraites/intellectualisées et pas assez ciblées sur l'essentiel pour débuter. On s'en fout, par exemple, de connaître la visibilité d'une méthode ou d'un attribut dès le départ ! Autant garder ces explications pour quand le débutant saura déjà réfléchir en termes d'objets et de relations entre eux et tout coller public dans un premier temps (et non, l'encapsulation n'a rien à voir avec le fait d'avoir des attributs privés). J'estime personnellement ne pas avoir assez vu dans les cours de POO les 3 points fondamentaux suivants, qui sont à mon avis la clé de la compréhension de la POO : "1 objet = 1 responsabilité", "encapsulation = A UN", "héritage = EST UN". D'ailleurs, je pense que les notions d'héritage et de polymorphisme d'héritage devraient être introduites dans un second temps par rapport à celles de classe (= responsabilité) et d'encapsulation. Une erreur de conception beaucoup trop fréquente chez les débutants (et pas que chez eux, d'ailleurs...) consiste à utiliser l'héritage à tort et à travers là où l'encapsulation serait bien plus commode : c'est pour moi un signe que les manuels n'expliquent pas assez bien que l'une et l'autre sont des relations du même ordre, mais qui ont des significations et des bénéfices bien différents l'une de l'autre. L'héritage étant plus complexe à appréhender que le principe d'encapsulation, alors qu'il est finalement moins souvent utile, je crois vraiment que c'est une notion à aborder une fois seulement acquise une intuition suffisamment bonne du reste.

* La POO c'est avant tout des bonnes pratiques. Ça englobe les deux précédents points, mais c'est encore un truc que j'estime ne pas avoir assez lu : la POO, c'est un paradigme qui est né, a été forgé, et a évolué en fonction de ce que les développeurs ont constaté dans la pratique de la programmation. Ça signifie qu'un cours assez complet sur la POO doit impérativement, à mon avis, prendre le temps de mettre le débutant, à chaque nouvelle notion, dans une mise en situation réaliste, voire deux (pour montrer aussi les limites). Il est bien plus facile de retenir une notion lorsque l'on en constate la puissance par nous-mêmes.

* Le cas de Python. Python (et son cousin Ruby dans une certaine mesure), sont des langages qui me semblent corrects pour appréhender la POO parce qu'ils partent tous les deux du principe que « tout est objet », et que leur nature de langages de script leur confère une syntaxe simple et lisible. J'entends par là qu'il est assez commode de montrer la définition d'une classe en Python parce que lorsque le principe 1 classe = 1 responsabilité est respecté, cette définition complète tient en peu de lignes, et l'essentiel est exprimé simplement, de façon claire et concise. En revanche, pour bien faire, il faudrait là aussi faire l'impasse dans un premier temps sur plusieurs mécanismes peu intuitifs du langage (je pense aux décorateurs, aux métaclasses, et aussi aux capacités d'introspection du langage, par exemple). En somme, un bon tutoriel sur la POO concernerait plus la POO elle-même que le langage et ses capacités…

Cela fait un bon moment qu'écrire un tutoriel sur la POO me démange, mais depuis plusieurs semaines, je me demande si la meilleure façon de faire ne serait pas d'utiliser un langage minimaliste et très simple comme Smalltalk (dont la syntaxe tient largement sur un post-it) de façon à construire avec le lecteur les notions au fur et à mesure. Si le gros inconvénient de cela reste que le langage utilisé n'est que très peu répandu (donc que le lecteur devrait apprendre à côté un second langage plus "pragmatique"), ça aurait quand même le mérite de rendre le cours indépendant et facilement généralisable.

La POO c'est un principe d'organisation pour du code un peu gros. Ça ne sert à rien d'essayer de l'enseigner à quelqu'un qui n'a aucune expérience de la conception logicielle, n'a jamais créé quelque chose organisé, même petit (je dirais, au dessus de 200 lignes, mais ça dépend des langages), et n'a pas l'expérience de la programmation nécessaire pour comprendre l'intérêt de cette organisation.

Pour moi c'est donc une erreur d'essayer d'enseigner la POO aux "débutants en programmation", et c'est sans doute pour ça que ça ne marche pas très bien. Ceci dit, ça n'interdit pas de faire débuter les gens dans un langage objet, du moment qu'on se contente de l'utiliser plutôt que d'expliquer la conception objet.

Citation : bluestorm

La POO c'est un principe d'organisation pour du code un peu gros. Ça ne sert à rien d'essayer de l'enseigner à quelqu'un qui n'a aucune expérience de la conception logicielle, n'a jamais créé quelque chose organisé, même petit (je dirais, au dessus de 200 lignes, mais ça dépend des langages), et n'a pas l'expérience de la programmation nécessaire pour comprendre l'intérêt de cette organisation.

Pour moi c'est donc une erreur d'essayer d'enseigner la POO aux "débutants en programmation", et c'est sans doute pour ça que ça ne marche pas très bien. Ceci dit, ça n'interdit pas de faire débuter les gens dans un langage objet, du moment qu'on se contente de l'utiliser plutôt que d'expliquer la conception objet.

C'est en grande partie ce que je m'apprêtais à écrire. La POO n'est pas une affaire de débutants car comme le dit Nohar la POO est une question de design, de conception et donc la POO se justifie lorsqu'on a besoin d'avoir des composants logiciels réutilisables et maintenables. En particulier, il s'agit d'écrire le code le plus pérenne et souple possible (capable de s'adapter à de futures modifications). Donc, ça ne concerne pas le type de code qu'un débutant en programmation va rencontrer (rien qu'à cause de la taille di code concerné), il ne peut pas comprendre ou même imaginer ce genre de question, il ne cherche pas à faire de façon réutilisable, il cherche déjà à faire tout court.

Citation : bluestorm

Pour moi c'est donc une erreur d'essayer d'enseigner la POO aux "débutants en programmation", et c'est sans doute pour ça que ça ne marche pas très bien. Ceci dit, ça n'interdit pas de faire débuter les gens dans un langage objet, du moment qu'on se contente de l'utiliser plutôt que d'expliquer la conception objet.

Mais est-ce que les langages à objets comme Python ou Ruby ne posent à ce moment-là des œillères aux débutants, en tentant de tout présenter comme un objet comme si c'était la panacée ?

Citation : nohar

Cela fait un bon moment qu'écrire un tutoriel sur la POO me démange, mais depuis plusieurs semaines, je me demande si la meilleure façon de faire ne serait pas d'utiliser un langage minimaliste et très simple comme Smalltalk (dont la syntaxe tient largement sur un post-it) de façon à construire avec le lecteur les notions au fur et à mesure. Si le gros inconvénient de cela reste que le langage utilisé n'est que très peu répandu (donc que le lecteur devrait apprendre à côté un second langage plus "pragmatique"), ça aurait quand même le mérite de rendre le cours indépendant et facilement généralisable.

Cela existe déjà un peu. Par exemple il y a How to design classes, qui présente la programmation avec classes à l'aide d'un ensemble de langages de programmation, et notamment Scheme. Ça peut t'intéresser pour y trouver de l'inspiration.

On en arrive donc à la conclusion que la POO n'est _pas_ une affaire de débutants, et n'a pas à leur être imposée dès qu'ils apprennent à programmer. C'est aussi ce que je pense dans une certaine mesure.

Il convient donc de dissocier le débutant en programmation "tout court" du débutant en programmation objet. C'est là qu'intervient l'approche assez sympa du tutoriel de prolixe, qui consiste à différentier dès le départ la "consommation" (l'utilisation de code OO) de la "production" de ce type de code…

Citation : Euphorion

Mais est-ce que les langages à objets comme Python ou Ruby ne posent à ce moment-là des œillères aux débutants, en tentant de tout présenter comme un objet comme si c'était la panacée ?

On va coller un procès à GvR parce que "tout" est objet en Python ? Ton reproche est absurde.

Les langages n'ont aucune responsabilité dans l'usage que des «pédagogues» vont en faire. Effectivement on lit souvent cette phrase selon laquelle "tout est objet en Python" ou encore "Everything is an object in Python". C'est une phrase complètement creuse, dont le contenu est inexploitable tel quel et qui n'a aucun sens énoncée à des débutants et à peine plus si elle s'adresse à des programmeurs plus expérimentés. C'est un slogan beaucoup plus qu'une phrase et qui doit venir en conclusion d'explications plus qu'en introduction.

Citation : Euphorion

Cela existe déjà un peu. Par exemple il y a How to design classes,

Merci de donner une information complète en précisant un lien : (pdf)ICI.

Quel horreur ce genre de livre. 600 pages de blabla qui viennent après un autre livre How to Design Programs de la même verbosité. Quoique je lise dans le livre, je n'arrive même pas à savoir où il veut en venir tant le discours est enveloppé de généralité et d'abstractions. Je suis sidéré de voir à quel point les auteurs sont dans l'incapacité de mettre en correspondance des exemples et de la théorie. Je me demande combien de vrais débutants ont appris à organiser des classes en lisant l'intégralité des 666 pages de cet ouvrage. Certainement fort peu puisque le livre suppose qu'on connait Java.

Je me demande parfois s'il faut croire en les capacités organisatrices de la POO quand je vois le design indigent des ouvrages qui lui sont consacrés : des couches de couches de couches de couches ...

Citation : nohar

Ça peut t'intéresser pour y trouver de l'inspiration.

... de ce qu'il ne faut pas faire

Citation : nohar

C'est là qu'intervient l'approche assez sympa du tutoriel de prolixe, qui consiste à différentier dès le départ la "consommation" (l'utilisation de code OO) de la "production" de ce type de code…

Sauf qu'il n'est absolument pas utile de parler de POO dans la 1ère situation. D'autant que nombre de situations décrites dans cette partie sont complètement indépendantes de la POO. Même l'argument de la syntaxe Toto.truc ne donne pas un argument valide, c'est juste de la syntaxe, pas difficile de comprendre que pour mettre une chaîne en majuscule, eh bien la syntaxe upper("toto") ne marche pas mais, pour des raisons que l'enseignant n'a pas à expliquer [car le rôle de l'enseignant c'est de cacher ou dévoiler un savoir au gré de son interlocuteur tout en gardant un exposé cohérent dans la réalisation d'un objectif qu'il a fixé au départ], il donne la syntaxe valide "toto".upper() sans détailler sous peine de compliquer la compréhension, en évitant les out-of-the-box, genre que c'est comme si on faisait l'appel str.upper("toto").

Citation : candide

Sauf qu'il n'est absolument pas utile de parler de POO dans la 1ère situation. D'autant que nombre de situations décrites dans cette partie sont complètement indépendantes de la POO. Même l'argument de la syntaxe Toto.truc ne donne pas un argument valide, c'est juste de la syntaxe, pas difficile de comprendre que pour mettre une chaîne en majuscule, eh bien la syntaxe upper("toto") ne marche pas mais, pour des raisons que l'enseignant n'a pas à expliquer [car le rôle de l'enseignant c'est de cacher ou dévoiler un savoir au gré de son interlocuteur tout en gardant un exposé cohérent dans la réalisation d'un objectif qu'il a fixé au départ], il donne la syntaxe valide "toto".upper() sans détailler sous peine de compliquer la compréhension, en évitant les out-of-the-box, genre que c'est comme si on faisait l'appel str.upper("toto").

Bof. Si le débutant en question est un débutant en Python mais pas en programmation, il risque fort d’être perdu s'il voit un truc comme "toto".upper(). Pourquoi cacher à tout prix le fait que l'on utilise des objets, alors que ça a un impact important sur la compréhension et la motivation pour la suite (création d'objets). Je trouve justement qu'utiliser des objets est plus à même de donner une certaine intuition de l'objet que des discours abstraits (j'ai encore en mémoire le premier texte "pour les nuls" que j'ai lu sur les objets, je n'y comprenais absolument rien).

Citation : yoch

Bof. Si le débutant en question est un débutant en Python mais pas en programmation, il risque fort d’être perdu s'il voit un truc comme "toto".upper(). Pourquoi cacher

Cacher complètement, peut-être pas, la question est de savoir : quel est mon objectif d'apprentissage ?. Si je veux juste avoir accès à des outils qui permettent de manipuler des chaînes, il suffit juste d'intégrer une syntaxe et on n'a pas besoin de savoir ce qu'est un objet. On peut dire par exemple en guise d'introduction que, de part la conception du langage, une chaîne est un «objet» et que cet objet a des «méthodes» (c'est comme des fonctions) et que ces méthodes sont accessibles par la syntaxe Toto.truc. Le tout est de savoir s'arrêter à temps pour ne pas complexifier la réalisation des objectifs qu'on s'est donné. En effet, les explications de POO que l'on peut fournir risquent d'être fort vagues et pour leur donner de la précision, on est amené à développer d'autres concepts de POO ce qui fait entrer dans une surenchère qui bien sûr éloigne de l'objectif initial, juste savoir mettre en majuscules. Sans compter qu'il y a de multiples situation où le fait de parler de méthodes d'objets entraîne plus. Par exemple,

>>> ''.join(['python', 'java'])
'pythonjava'
>>>

est très curieux car join est une méthode de la chaîne '' :
-- déjà, on a du mal à concevoir que la chaîne vide a une méthode ce qui ve devoir entraîner dans d'autres explications).
-- est-il si naturel que join() soit une méthode de chaîne plutôt que méthode d'une liste, pourquoi la méthode appartiendrait elle à l'élément séparant (ici la chaîne vide) plutôt qu'au type des éléments séparés (ici liste) ?

Bref, c'est pour ne pas avoir à répondre à des questions comme ça que je pense qu'il ne faut pas développer les concepts de POO à moins que l'objectif soit d'être introduit à la POO. Il n'existe pas d'exposé absolu, il y a plusieurs paramètre dont l'objectif d'apprentissage. Mon idée de base est que je ne veut pas payer pour quelque chose dont je n'ai pas besoin.

En même temps, je suis d'accord que la notation Toto.rangerSaChambre() peut nécessiter une petite explication, le tout est de trouver le bon équilibre. Mais en même temps, je ne vois pas pourquoi la syntaxe maFonction(monArgument) passerait et que la syntaxe MOnObjet.maMethode(monArgument) ne passerait pas. C'est juste une question de convention à admettre, je dirais même une question d'interface, et comme tous les programmeurs le savent bien, il faut cacher l'implémentation à un client et lui laisser accéder à l'objet juste par l'interface de l'objet., non ?

EDIT

Citation : yoch

(j'ai encore en mémoire le premier texte "pour les nuls" que j'ai lu sur les objets, je n'y comprenais absolument rien).

Eh oui, mais quel était l'objectif ? apprendre les objets ?

Pour moi l'idée de base, c'est qu'on doit apprendre un langage de programmation, en particulier si on débute comme un enfant acquiert sa langue maternelle : de façon non contrainte, par imprégnation (noter bien que l'enfant n'apprend pas sa langue maternelle, il l'acquiert presque sans vraiment l'apprendre, pas de leçon, pas de devoir). Un enfant n'a pas à avoir appris formellement la grammaire ou la stylistique pour comprendre ce qu'on lui dit et pouvoir s'exprimer. Naturellement, l'apprentissage d'une langue ne se limite pas au fait d'être locuteur de la langue, il manque encore beaucoup de compétences linguistiques à un enfant.

Il y a une façon très simple et très correcte d'expliquer la syntaxe foo.bar(baz), qui est simplement de dire qu'il s'agit de sucre syntaxique pour bar(foo,baz) : ce qui est avant le point est le premier paramètre de la fonction, qu'on a choisi de mettre en avant.

Citation : bluestorm

Il y a une façon très simple et très correcte d'expliquer la syntaxe foo.bar(baz), qui est simplement de dire qu'il s'agit de sucre syntaxique pour bar(foo,baz) : ce qui est avant le point est le premier paramètre de la fonction, qu'on a choisi de mettre en avant.

Ben essayons :

>>> "toto".upper()
'TOTO'
>>> upper("toto")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'upper' is not defined
>>>

et boum ! tu viens de transformer ce qui devait être une boîte noire en une boîte de Pandore et le in-the-box en out-of-the-box


Ce qui va sortir ensuite de la boîte de Pandore, c'est un expression aussi sympathique que

>>> "toto".__class__.upper("toto")
'TOTO'
>>>

puis ensuite pour être plus clair, tu vas devoir sortir de ta boîte

>>> type("toto")
<type 'str'>
>>> str.upper("toto")
'TOTO'
>>>

toute la POO va y passer et ton débutant te dira que, tout comptes faits, il va essayer javascript

Citation : bluestorm

Il y a une façon très simple et très correcte d'expliquer la syntaxe foo.bar(baz), qui est simplement de dire qu'il s'agit de sucre syntaxique pour bar(foo,baz) : ce qui est avant le point est le premier paramètre de la fonction, qu'on a choisi de mettre en avant.

Sauf que deux classes peuvent fournir cette même méthode bar — mettons Human et Animal. Du coup tu as soit Animal_foo(foo, baz) et Human_foo(foo, baz), et l’intérêt est que la fonction qui sera effectivement appelée n’est pas fixée à l’avance, même dans les langages statiquement typés grâce au polymorphisme.

Bah non, y'a deux fonctions ayant des signatures différentes et tout est résolu statiquement ... :

foo(Animal, args).
foo(Human, args).

candide > je ne sous-entendais pas que bar(foo,baz) serait directement valide en Python. Je dis juste qu'on peut penser ainsi à la syntaxe d'appel de méthode.

Mon ouïe > l'instance foo passée en paramètre à bar contient l'état de l'objet, et en particulier la table de résolution des appels de méthodes. Tu peux voir foo comme un dictionnaire contenant des valeurs et des fonctions, et implémenter bar ainsi:

def bar(foo, baz):
  return foo['bar'](baz)

Bien sûr, beaucoup d'autres implémentations sont possibles (la logique pour résoudre l'appel, ici juste un lookup dans une table, peut être arbitrairement complexe selon les situations et les langages) donc la présentation foo['bar'](baz) est moins générale que bar(foo,baz); l'important est de savoir que passer foo en paramètre donne toutes les informations nécessaires pour décider quoi faire dynamiquement.

Goten_ > Python est typé dynamiquement et ne fait pas à ma connaissance de résolution statique. De plus, dans de nombreux langages, la classe ne détermine pas uniquement la méthode, tu peux avoir deux objets ayant la même signature et des méthodes différentes (c'est même tout l'intérêt de la programmation orientée objet).

Citation : bluestorm

candide >
Goten_ > Python est typé dynamiquement et ne fait pas à ma connaissance de résolution statique. De plus, dans de nombreux langages, la classe ne détermine pas uniquement la méthode, tu peux avoir deux objets ayant la même signature et des méthodes différentes (c'est même tout l'intérêt de la programmation orientée objet).

Ok, j'ai cru qu'on parlait d'OO en général et non d'un language spécifique, my bad. (ça m'apprendra à arriver en plein milieu d'une conversation).
Pour le reste je comprends pas (encore du python-isme???), "deux objets ayant la même signature" ?

Ce que je voulais dire (ce n'est pas du python-isme, je me suis juste mal exprimé) c'est que la "résolution statique" en POO est toujours limitée; tu peux savoir statiquement quelle interface un objet implémente, mais le comportement réel d'une méthode doit pouvoir être late-bound, et déterminé au runtime seulement.

Citation : bluestorm

candide > je ne sous-entendais pas que bar(foo,baz) serait directement valide en Python. Je dis juste qu'on peut penser ainsi à la syntaxe d'appel de méthode.

Oui mais pour rester dans le cadre de la discussion [débuter la programmation et apprendre ou pas la POO], ce discours qui consiste à raconter les choses vues de très très haut (*), de façon vague ("c'est comme si", "on peut penser ainsi") et de façon très abstraite (ci-dessus, tu parles en général de la syntaxe monObjet.maMethode) conduit à l'incompréhension (on voit pas où tu veux en venir) et à l'inefficacité (le code ne marche pas ou pour en revenir à mon exemple initial, je ne sais pas mettre en majuscules) autrement dit, il ne permet pas de produire du code ("In code we trust"). Le flou ne s'applique à rien, le concret se transfère (induction)⋅ Selon moi, une règle fondamentale dans l'apprentissage de la programmation est que tout commence par le code, tout finit par le code et donc tout propos général et abstrait doit être instancié par du code et le corpus de codes doit permettre la compréhension des règles générales.


D'ailleurs, la suite de la discussion dans ce fil est en train de montrer que tu n'as pas été compris (on n'arrive pas à voir exactement à quel niveau d'abstraction tu te places), ce qui t'oblige à donner de nouvelles explications (la boîte de Pandore) plus ou moins claires (l'instance contient l'état de l'objet, etc), à recontextualiser alors que si dès le départ tu t'étais placé dans le cadre strict de tel ou tel langage (peu importe à la limite) avec un code strictement conforme, les ambiguïtés disparaissent.

(*) un livre particulièrement agaçant de ce point de vue est le livre de Lutz, Learning Python, c'est un livre que j'ai lu crayon à la main quand j'ai commencé à apprendre Python il y a trois ans et qui est un inextinguible torrent de généralités. Par exemple, il commence la POO par un chapitre intitulé OOP : The Big Picture où il parle sur des pages et des pages tantôt de concepts de très très haut niveau (un des paragraphes s'appelle OOP from 30,000 Feet), tantôt de détails de la POO de façon extrêmement abstraites si bien qu'on obtient un discours complètement décharné, incompréhensible et inexploitable, c'est à peu près aussi efficace que de vouloir devenir secouriste en lisant un livre de physiologie humaine. C'est seulement maintenant, après 3 ans de lecture, de tests et de pratique que je commence à comprendre sans douleur ce qu'il raconte. Voilà quelqu'un qui ne sait pas raconter une histoire pour confondre ainsi le début et la fin.