Citation : candide

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.

Une personne n'a pas compris et s'est exprimé. Combien ont lu ? Quelle est la proportion des personnes ayant compris parmi ceux qui ont lu ? Je n'en sais rien, et toi non plus... D'ailleurs, pour contribuer aux statistiques, j'avais compris moi, et je parie que toi aussi.

Plus sérieusement, si j'ai bien saisi ton point de vue, je pense que ta théorie que "tout commence par le code, tout finit par le code [...]" doit être relativisée.

Pourquoi je pense cela ? Déjà parce que il n'y a pas que les débutants complets qui ont besoins de supports d'apprentissage. Ensuite, parce que certains concepts abstraits gagnent à être expliqués de façon relativement abstraite. Et enfin parce que je trouve que tu attache un peu trop d'importance à l'aspect utilitariste ("In code we trust").

Pour reprendre ton exemple, s'il est vrai qu'un enfant apprend la langue maternelle d'une certaine façon, ce n'est pourtant pas de la même façon qu'il progressera plus tard à l'école, l'enseignement sera alors plus "formalisé", et ce pas seulement pour des raisons de commodité ou de stupidité de l'enseignant, mais pour des motifs pédagogiques.

Note que je ne conteste pas totalement ta vision des choses, mais je trouve qu'elle est surtout adaptée aux débutants, et que les autres vont plus être génés qu'autre chose avec.

Citation : yoch

Une personne n'a pas compris et s'est exprimé. Combien ont lu ? Quelle est la proportion des personnes ayant compris parmi ceux qui ont lu ? Je n'en sais rien, et toi non plus... D'ailleurs, pour contribuer aux statistiques, j'avais compris moi, et je parie que toi aussi.

Perdu Reprends le fil, trois personnes ont répondu et ces personnes n'ont pas compris (même s'ils elles ont pu comprendre vaguement certaines choses) car le propos de bluestorm était décontextualisé, flou, non tangible


Fondamentalement, je ne vois pas ce qu'apporte au débutant qui découvre Python d'essayer de traduire "toto".upper() dans un langage qu'il ne connait pas (la POO) avec un risque évident d'incompréhension et d'erreur, les réponses à la suggestion proposée par bluestorm l'ont montré. En programmation, c'est comme avec les enfants, il ne sert à rien de répondre par anticipation à des questions qu'ils ne se posent pas, cela même peut être plus troublant qu'utile. Je ne dis pas qu'il ne faut pas expliquer le mécanisme d'appel "toto".upper() mais il ne faut pas les imposer à tout le monde. Pour paraphraser, Premature explanations are the root of all evil.

Citation : yoch

Plus sérieusement, si j'ai bien saisi ton point de vue, je pense que ta théorie que "tout commence par le code, tout finit par le code [...]" doit être relativisée.

Probablement puisqu'il n'emporte pas ton adhésion ni de beaucoup d'autres sans doute. De toute façon, la prééminence du code n'est qu'un aspect de ma vision.

Citation : yoch

Ensuite, parce que certains concepts abstraits gagnent à être expliqués de façon relativement abstraite.

Oui mais c'est une question de background et de progressivité. Il faut un terrain pour qu'une abstraction puisse s'enraciner. Même quand tu fais des maths très abstraites, tu as des parcours qui te permettent de digérer certaines abstractions, par exemple je serais très inefficace si je parlais à mes étudiants d'espaces topologiques sans qu'ils n'aient jamais vu un espace normé et même la topologie de R. Ce qui au passage montre que l'abstraction pure n'existe pas, certains objets en apparence très abstraits sont en fait très concrets (et donc quand tu dis que certains abstractions ne s'expliquent que par des abstractions, tu te trompes, car tes abstractions supports sont devenues des instances de l'abstraction en cours d'acquisition).

Pour revenir à un registre plus commun, avant de parler du concept d'infini à un enfant, il faut qu'il ait vécu un grand nombre de situations qui lui permette d'abstraire le concept d'infini.

Certaines abstractions sont très difficiles à acquérir bien que souvent introduites tôt dans l'enseignement. Le cas typique, est celui de la notion de limite d'une fonction (ou d'une suite). Il faut des années (voire jamais) pour que ce concept puisse vraiment émerger chez les étudiants et devenir un objet "concret".

Citation : yoch

Et enfin parce que je trouve que tu attache un peu trop d'importance à l'aspect utilitariste ("In code we trust").

Comme disait la Fontaine, on fait cas du beau, on méprise l'utile. Et oui, parce qu'on apprend pas C ou Python pour faire causette dans les salons . Et j'attends de mes étudiants par exemple qu'ils aient d'abord une capacité non pas à disserter sur la généricité en C mais à programmer en C avec fluidité, sobriété et exactitude, ce qui n'est pas le cas du tout après plusieurs semestres d'enseignement. Ça ne veut pas dire que je néglige l'aspect conceptuel mais chaque chose en son temps.

Citation : yoch

Pour reprendre ton exemple, s'il est vrai qu'un enfant apprend la langue maternelle d'une certaine façon, ce n'est pourtant pas de la même façon qu'il progressera plus tard à l'école, l'enseignement sera alors plus "formalisé",

Bien sûr, c'est le système qui l'impose, parfois c'est adapté, parfois ça ne l'est pas, parfois ça donne des résultats, parfois ça n'en donne pas. Il faudrait examiner à quel point les élèves sont réceptifs aux abstractions qui leur sont enseignées par exemple en français, en grammaire plus précisément (tiens, tiens, grammaire, syntaxe, comme dans les langages de programmation). J'ai peur hélas qu'il y a une énorme passivité devant toutes ces abstractions.

Citation : Goten_

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

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

Même dans un langage comme le C++, ça ne se passerait pas forcément comme ça :

class animal {
public:
  virtual void foo() { std::cout << "animal!";};
};

class human: public animal {
public:
  virtual void foo() { std::cout << "human!"; };
};

void do_foo(animal &obj) {
  obj.foo();
}

Dans la fonction do_foo, on ne sait pas au moment de la compilation laquelle des deux méthodes sera appelée.

Tu n'avais pas parlé de polymorphisme. (et non même avec les noms c'était pas forcément sous entendu)

M'enfin, je vois toujours pas en quoi c'est une contre-indication à l'explication du sucre syntaxique obj.foo() vs foo(obj).

Dans les deux cas tu te retrouves à devoir expliquer le polymorphisme d'inclusion.

Citation : Goten_

M'enfin, je vois toujours pas en quoi c'est une contre-indication à l'explication du sucre syntaxique obj.foo() vs foo(obj).

Tu donnes toi-même la réponse :

Citation : Goten_

Dans les deux cas tu te retrouves à devoir expliquer le polymorphisme d'inclusion.

Moi je pense qu'il n'y a pas que le python, le C et le C++, un débutant choisira le langage qu'il veut, et peu importe que le langage lui soit adapté ou non, il n'a besoin de personne pour se rendre compte qu'il y arrive ou non.

Donc le débutant va choisir ce qu'il veut, et s'il veut, ni le C, ni le C++, ni le python, qui sont des langages difficiles, mais pas insurmontables. Et c'est justement cette expérience qui va l'orienter sur ce qu'il souhaite faire ensuite.

Enfin, on ne peut pas comparer la difficulté du C du python et du C++, ce sont des langages très différents, qui n'ont pas la même philosophie, une syntaxe différente (enfin pas trop entre le C et le C++), qui sollicitent des connaissances différentes, qui ont des avantages sur certains points ou un autre langage est mieux adapté, et inversement.

Alors personne ne va choisir pour le débutant, il faut toucher un peu à tout pour trouver sa voie, et comme on dit, on peut pas dire qu'on aime pas avant d'avoir goûté !

Citation : yoch

Et enfin parce que je trouve que tu attache un peu trop d'importance à l'aspect utilitariste ("In code we trust").

Un débutant logiquement cherchera toujours à comprendre des choses concrètes.

Citation : yoch

Ensuite, parce que certains concepts abstraits gagnent à être expliqués de façon relativement abstraite

Beaucoup de choses abstraites peuvent être expliquées de façon concrètes, c'est une grosse demande en lycée professionnel où les élèves ont des difficultés sur des théories.

Bin-R c'est bien joli mais tout l'intérêt du topic est de discuter des qualités pédagogiques intrinsèques à ces langages, et vue l'activité qu'il connaît ainsi que la pertinence des intervenants (tu noteras que ce n'est toujours pas parti en troll), la discussion a visiblement un intérêt non négligeable…

Ce que je veux dire, c'est qu'il n'y a pas de "parcours" à suivre : tel langage, puis tel autre, et enfin celui-là, etc...

Certes, certains langages sont plus simples que d'autres, mais tout débutant n'a pas les mêmes attentes, mais si je devais conseiller un langage pour débuter, je dirais le C, ou pas, et je vais m'expliquer, c'est seulement mon avis, il est critiquable:

• C'est un langage qui en a "inspiré" beaucoup d'autres, surtout pour la syntaxe, donc c'est une référence très connue et une bonne base pour ensuite faire ce que l'on veut comme autre langage.
• C'est un langage puissant et très riche, donc on a beaucoup de choses à y apprendre, même des choses difficiles !
• Contrairement aux langages de plus haut niveau, le C sollicite des connaissances sur le fonctionnement du pc (gestion de la mémoire,...), et donc après, en comparaison, on a plus de liberté qu'avec le Python par exemple.

Il y a néamoins de bonnes raisons de ne pas commencer par le C, les voici:

• C'est un langage qui nécessite de comprendre un peu le fonctionnement du pc, certaines techniques avancées peuvent faire buter le débutant (cela dit, une fois maîtrisées, ces notions sont plus un atout qu'un handicap, je pense aux pointeurs par exemple).
• Il y a beaucoup de connaissances à enregistrer, comme premier langage, ça peut embrouiller l'esprit : un langage plus "léger" peut être plus intéressant.
• Le programmeur doit vite acquérir beaucoup de réflexes pour éviter les erreurs et une fois de plus, un débutant qui ne comprendra pas leur intérêt sera perdu.

Donc pour le C, il y a du pour et du contre, selon moi, le mieux est d'attaquer le C en 2ème voire 3ème langage, car la programmation et ses principes sont alors déjà assimilées, et les difficultés du C sont alors plus faciles à résoudre. (tout cela n'est que mon avis )

C'est comme le latin. En première langue, aujourd'hui ce n'est pas très efficace. Après, cela consolide les acquis dans les autres langues latine -- parait-il.

Citation : lmghs

C'est comme le latin. En première langue, aujourd'hui ce n'est pas très efficace. Après, cela consolide les acquis dans les autres langues latine -- parait-il.

Soyons sympas : le latin ce serait plutôt le C++ (que des bons élèves) et le C serait le grec (mon dieu, quand on voit l'état de la Grèce).

Sinon il y a le langage D, je ne connais pas trop, c'est du C amélioré, mais c'est pas trop pour les débutants.

Du C amélioré? Non si c'est quelque chose ça serait plutôt du C++ "done right" (attention, je dis pas que l'objectif à été atteint ...). Y'a de bonnes idées, d'autres moins bonnes, mais là où ça pêche le plus à mon goût c'est dans la réalisation, ça part dans pas mal de directions différentes etc, (quoique ça a changé depuis l'arrivée d'Alexandrescu)

Je pense que la programmation sur les calculatrices scientifiques est un bon choix pour commencer, car elle est souvent simple comparée aux autres langages. Mais il faut assez vite essayer un autre programme, car la programmation sur calculatrice crée des automatismes. Par exemple, j'oublie très souvent de mettre un double = quand il le faut, et un ; à la fin de chaque ligne.

Tu as l’air de dire que c’est nécessairement une mauvaise chose, mais les calculatrices n’ont pas l’exclusivité des langages qui n’utilisent pas == ou ;. Leurs langages ont effectivement des problèmes, mais pas forcément ceux-là.

R.I.P grand topic !

Cessez donc de profaner les morts !

Cessons de diaboliser les déterrages. S’il reste des choses à dire sur le sujet, pourquoi s’en priver sous prétexte qu’il a été posé il y a « longtemps » ?