Enseigner un langage de manière différente

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Nous avons eu sur le forum des discussions sur par exemple Comment enseigner les maths.
Je me demandais si une telle discussion était possible pour les langages de programmation.

En effet, je constate que les tutos sur les langages suivent toujours grosso-modo le même schéma : qu'est-ce que programmer, les variables, les conditions, les boucles, les fonctions....

Or il est apparu par exemple dans la discussion sur l'avenir de ZdS que pour attirer les gens, il fallait du contenu original. Or les tutos débutants sur les langages, il y en a à foison sur le net.

D'où ma question : connaissez-vous des manières originales d'enseigner un langage ? La question peut être aussi plus restreinte : comment enseigner le concept de variable, de pointeur, d'objet, d'héritage.... d'une manière différente. Avez-vous des exemples de tels tutoriels ?

Édité par Looping

L'héritage et l'OO, faire différemment ça peut être facile tellement les concepts sont mal maitrisés.

Typiquement, j'ai du monter une formation OO pour le taf' il y a 2 mois et j'ai cherché ce que l'on pouvait trouver comme exercices et exemples. Et que voyais-je ? Un accent systématique sur l'organisation des données. Des conceptions de bases de données en veux-tu, en voilà : gestion de bibliothèque, gestion de stock de pharmacie.

Alors que l'objet, si on reprend les définitions des pionniers, c'est avant tout du comportement et des messages qui circulent entre objets, et du extreme late binding of all things. Bref. Le meilleur exo que j'ai trouvé, ce fut celui du Javaquarium (et encore, on peut y observer les limites du paradigmes OO, avec les ECS qui se prêtent bien à l'exercice.)

Autre exemple de la totale non maitrise du concept objet : la quantité d'agrégats de données (dépourvus d'invariants) organisés à coup de getters et de setters parce que "il est inadmissible de donner un accès direct aux données". Ben oui il faut encapsuler. Sauf qu'il y a confusion. Si l'encapsulation se fait techniquement par masquage (cachage, ça sonne pas bien!) des données dans beaucoup de langages (hormis Python et Eiffel p.ex.), son but n'est pas de cacher, mais de protéger les invariants. Mais non. Il faut absolument cacher toutes les données d'un agrégat, même s'il n'a aucun invariant.

Dans les trucs qui ne vont pas, vous trouverez aussi plein de présentations techniques de l'héritage où l'on voit des PointColore dériver de Point. Or, dans les classes valeurs, l'héritage ça ne marche pas. Cf une démonstration que l'on trouve dans Effective Java de J.Bloch -> on ne peut pas avoir une méthode equals qui respecte à la fois la transitivité, la symétrie et le LSP.

Pour l'héritage, dans nos langages, la technique de l'héritage répond à deux besoins: l'import de code, et la substituabilité/le sous-typage. Encore une autre piste à creuser si on veut se distinguer.

Ce qui me fait penser à la critique que je fais aux cours historiques de C++ : ils présentent la syntaxe du langage sans s'intéresser aux besoins. Pour chaque besoin, il va y avoir un "pattern", ou "idiome" qui correspond. Et ces derniers vont se retranscrire en éléments syntaxiques associés. Si l'approche syntaxique était tolérable en BASIC à partir du moment où on suppose que le développeur connait variables et les principes des structures de contrôle. Ça ne marche plus très bien avec certains langages modernes comme le C++.

EDIT: je ne parle là que de contenu. Il y a après la façon de présenter les choses. Et là, comme toujours, il est important de connaitre son public. Pour des tutos en lignes, c'est plus complexe de cibler un public bien précis. Quand je le peux, j'essaie de me raccrocher à ce qu'il connaissent en termes de besoin propres à leur métier. Ainsi quand je présente les concepts objets, je cherche à les raccrocher aux équivalents qu'ils connaissent et de les démystifier en expliquant à quel besoin va répondre tel ou tel concept. Et comment la nouvelle réponse se distingue des alternatives qu'ils pouvaient connaitre. Je tâche à chaque fois de disposer de métaphores dans le métier du public ou dans la vie de tous les jours.

Édité par lmghs

+4 -0

L'héritage et l'OO, faire différemment ça peut être facile tellement les concepts sont mal maitrisés.

lmghs

Et dire que tout à l'heure je me suis retenu de poster. En même temps, ça aurait plus ressemblé à ça :

"On pourrait les enseigner correctement, on se démarquerait de la majorité des cours."

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein

+5 -0

Le plan majoritairement adopté par les cours de programmation est un plan qui suit une logique de programmeur confirmé : on va présenter ensemble tout ce qui se rattache aux structures conditionnelles, parce que cette notion de structure conditionnelle fait sens quand on a l'habitude de la programmation. En cela, c'est une erreur, parce que le débutant en programmation ne considère pas ces classifications comme acquises et elle ne font pas sens pour lui.

C'est pourquoi l'organisation d'un cours de programmation pour débutants doit répondre à la question « Qu'est-ce que je veux que mon apprenant soit capable de faire à une étape donnée du cours ? ». L'ordre de présentation des notions va alors être gouverné par les besoins de l'apprenant, la priorité étant donnée à ce qu'il soit le plus vite possible capable de résoudre un problème « crédible » (je ne retrouve plus le terme exact).

Et il importe peu que la solution apportée à ce problème soit sous-optimale : les outils permettant de l'améliorer seront introduits par la suite, et l'apprenant comprendra alors d'autant mieux pourquoi ces outils sont « meilleurs ».

Dans cette optique, il n'y a aucune raison de présenter les structures de type switch en même temps que les structures de type if, par exemple : l'introduction du switch doit répondre à un besoin de l'apprenant, qui ne parvient pas à résoudre un certain problème de manière satisfaisante à l'aide de ifs.

Dans un autre ordre d'idée, les structures de données de type tableau/liste seront sûrement abordées très tôt dans l'apprentissage, et il n'est pas grave de laisser à beaucoup plus tard l'explication sur les pointeurs (impératif) / structures récursives de données (fonctionnel).

#JeSuisGrimur #OnVautMieuxQueÇa

+4 -1
Auteur du sujet

Dans cette optique, il n'y a aucune raison de présenter les structures de type switch en même temps que les structures de type if, par exemple : l'introduction du switch doit répondre à un besoin de l'apprenant, qui ne parvient pas à résoudre un certain problème de manière satisfaisante à l'aide de ifs.

Le problème c'est lorsque le lecteur va vouloir reprendre le tuto pour rechercher une info quelconque : il aura du mal à retrouver le swich s'il n'est pas à coté du if, dans un chapitre Strutures de controle. Du coup, même s'il a adoré le tuto, il dira plus tard à un autre débutant : "Oui je crois que j'avais bien aimé ce tuto mais il est assez mal organisé".

Le problème c'est qu'un lecteur peut être : débutant complet, débutant mais connaissant déjà un autre langage, pas débutant mais qui recherche une info qu'il a oublié, expert qui cherche un tuto pour son apprenti....

Après je suis d'accord qu'il faille donner le pourquoi on introduit tel truc, mais ça peut se faire dans une organisation classique de cours.

@Looping : tu mets précisément le doigt sur le défaut de la structure classique de cours d'informatique, à savoir vouloir être à la fois un cours d'apprentissage du langage et une cheat sheet de la syntaxe.

Pense les choses en termes de langage naturel : il y a une grande différence d'organisation entre un manuel de langue et une grammaire. Le premier vise à enseigner efficacement la langue, la seconde à retrouver rapidement une information donnée sur celle-ci.

C'est pareil pour un langage informatique, il ne faut pas organiser un cours pour apprendre le langage comme une référence sur sa syntaxe, c'est contre-productif. Si vraiment c'est nécessaire, il est plus judicieux d'ajouter un index en annexe du cours pour retrouver plus facilement une notion spécifique.

#JeSuisGrimur #OnVautMieuxQueÇa

+1 -0

Quand j'ai vu que mes élèves bloquaient totalement sur des exercices extrêmement simples, j'ai commencé à utiliser des exemples partiellement travaillés. Dans le détail, je leur donnais des codes qui contenaient volontairement des erreurs : ils devaient vérifier si il y avait des erreurs ou non, et ils devaient corriger ces éventuelles erreurs de manière à obtenir un code qui faisait ce que l'énoncé demandait.

Sinon, un truc très simple (et donc pas forcément dithyrambique) que j'ai essayé cette année, c'était de donner aux élèves plusieurs exercices dans lesquels j'utilisais mal certaines constructions du langage, et où je demandais aux élèves de simplifier. Par exemple, ils devaient me simplifier des codes comme ceci en utilisant des if…else, ou des if…elseif…else :

1
2
3
4
5
6
7
8
if ( $a > 18 )
{

}
if ( $a <= 18 )
{

}

J'ai aussi sorti plusieurs exercices du genre pour les boucles, genre des while utilisés à la place d'une boucle FOR, et les élèves avaient pour consigne de simplifier les codes ou de les corriger. Comme cela, cela leur apprenait quand utiliser telle ou telle boucle, telle ou telle structure de contrôle, etc.

Édité par anonyme

+1 -1
Auteur du sujet

La question du pourquoi est importante, et effectivement ça peut passer par montrer ce qu'il ne faut pas faire.

Je pense par exemple aux design pattern. Une approche pourrait être de montrer une mauvaise conception, montrer ce qui ne va pas, puis montrer en quoi le design pattern résout le problème. Et même pourquoi pas montrer ensuite une mauvaise utilisation de ce design.

Pour les design patterns, j'ai beaucoup aimé le livre Designs Pattern la Tête la Première. Justement parce qu'il part de problématiques plausibles et que l'auteur explore des solutions, montre les limitations au fur et à mesure pour conclure "voilà, cette solution est le Design Pattern Toto".

Mieux que de partir d'une mauvaise conception : partir d'un problème concret à résoudre.

+4 -0

Il faut savoir aussi rester dans la logique, et ne pas faire de l'original juste pour l'original. Il faut que ce soit utile. Par exemple, dans le cours de C++ que je rédige avec informaticienzero et Akulen, on reste dans un plan assez classique pour la partie "Les bases", mais on a choisi de ne pas présenter la bibliothèque standard dans une partie avancée, et de ne pas présenter du bas niveau genre pointeurs dès le début.

(J'avoue cependant ne pas avoir lu suffisamment de cours de C++ pour débutants pour savoir si c'est vraiment original)

Plus on apprend, et, euh… Plus on apprend. | Coliru, parfait pour tester ses codes sources !

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte