éternel débutant en C pour mon plaisir, je me permets de venir vous
demander quelques éclaircissements sur une situation que je n'arrive pas
à comprendre :
J'utilise le cours en ligne spécial "grand débutant" du "site du zéro" :
<http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html>
Je réalise les exercices du cours dans deux environnements différents :
- sous windows vista avec l'IDE visual C++ 2008 express
- sous linux ubuntu 9.04 avec gcc
J'ai écrit un programme dans le cadre des exercices proposés sur les
tableaux par ce cours en ligne. Le fichier en question peut être
téléchargé ici :
< http://dl.free.fr/to7PFReLM/tableau.c>
Ce qui m'étonne, c'est que j'arrive à compiler sans difficulté ce code
sous Linux, et que le programme se comporte exactement comme je le
souhaite. Par contre, sous Windows, impossible de compiler, l'IDE me
renvoie 42 erreurs et 31 avertissements !!! La plupart des erreurs
semblent être liées aux variables. Par exemple :
"erreur de syntaxe : absence de ';' avant 'type'"
"identificateur non déclaré"
Or, j'ai beau lire et relire mon code, les variables me sembles toutes
déclarées correctement et il ne manque à mon sens pas de ";" en fin
d'instructions. De plus, comme je le disais au début, le même code se
compile sans aucune erreur sous Linux ...
Alors, comment expliquer que deux compilateurs réagissent aussi
différemment, et où et mon erreur ?
Merci par avance du temps que vous pourrez me consacrer,
Mais comme tu le disais, ça dépend si on peut s'appuyer sur une connaissance des étudiants de ce qu'est la mémoire. Si ça n'a pas été fait, faut en faire un peu. C'est plus facile d'enseigner le C après 30h d'architecure des ordinateurs.
Tu veux dire de t'appuyer sur des connaissances d'architecture pour enseigner le C ? Ça se discute, disons que ça dépend de ton objectif mais en ce qui concerne mes propres apprentissages, j'essaye d'éviter les empilements. Mais il est tout à fait possible de s'en passer. La mémoire est une abstraction et elle peut rester telle quand on enseigne le C. Probablement que dans des usages avancés voire spécialisés, des connaissances d'archi (et d'assembleur) peuvent être instructives voire utiles. Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc) est un bon outil pédagogique, ça fait vivre un programme, dommage que les interfaces soient un peu austères (même DDD).
Je suis un peu pessimiste sur le coup. Ce que tu decris ne marche pas avec toutes les populations d'etudiants. Pour que la memoire reste une abstraction, il faut qu'ils aient de bonnes capacites d'abstraction, justement. Meme avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire rentrer la notion de portabilite. La notion d'undefined behavior est tres difficile a integrer.
L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc (parce que c'est trop long) et qui me pondent du code qui "tombe en marche" (grace a la superbe idee de gcc d'initialiser a 0 les variables locales en -O0), et a qui j'ai un mal fou a expliquer que leur programme est buggue jusqu'a l'os...
Donc, j'ai du code buggue, et des questions, et je suis bien oblige d'expliquer que le code "tape" a cote, ce qu'une fonction avec pas le bon nombre de parametres va faire, et tout et tout.
On a les même étudiants.
En fait, c'est tres dommage que, sur les compilo modernes, le mode par defaut ne soit pas hyper-strict. Genre -Wall -O1 -Werror... mais pour ca, faudrait que gcc sache reconnaitre les faux positifs, et separer les "warnings" des "warnings qui devaient etre des erreurs" dans 100% des cas, quitte a etre biaise dans le sens "laisser passer des warnings", mais bon.
Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers transparents. Et de même que je refusais de lire un code mal indenté, je refusais de chercher un bug dans un code qui laissait passer des Warning avec -Wall -pedantic. Au début, tu passes pour un sale c*n, mais les résultats à terme sont bons.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 14-09-2009, Marc Espie <espie@lain.home> a écrit :
In article <4aae1943$0$25120$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Marc Boyer a écrit :
Mais comme tu le disais, ça dépend si on peut s'appuyer sur une
connaissance des étudiants de ce qu'est la mémoire.
Si ça n'a pas été fait, faut en faire un peu.
C'est plus facile d'enseigner le C après 30h d'architecure des
ordinateurs.
Tu veux dire de t'appuyer sur des connaissances d'architecture pour enseigner le
C ? Ça se discute, disons que ça dépend de ton objectif mais en ce qui concerne
mes propres apprentissages, j'essaye d'éviter les empilements. Mais il est tout
à fait possible de s'en passer. La mémoire est une abstraction et elle peut
rester telle quand on enseigne le C. Probablement que dans des usages avancés
voire spécialisés, des connaissances d'archi (et d'assembleur) peuvent être
instructives voire utiles. Un dégogueur utilisé comme un VCR (arrêt sur image,
avance rapide, etc) est un bon outil pédagogique, ça fait vivre un programme,
dommage que les interfaces soient un peu austères (même DDD).
Je suis un peu pessimiste sur le coup. Ce que tu decris ne marche pas avec
toutes les populations d'etudiants. Pour que la memoire reste une abstraction,
il faut qu'ils aient de bonnes capacites d'abstraction, justement. Meme
avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire
rentrer la notion de portabilite. La notion d'undefined behavior est tres
difficile a integrer.
L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc
(parce que c'est trop long) et qui me pondent du code qui "tombe en marche"
(grace a la superbe idee de gcc d'initialiser a 0 les variables locales
en -O0), et a qui j'ai un mal fou a expliquer que leur programme est buggue
jusqu'a l'os...
Donc, j'ai du code buggue, et des questions, et je suis bien oblige d'expliquer
que le code "tape" a cote, ce qu'une fonction avec pas le bon nombre de
parametres va faire, et tout et tout.
On a les même étudiants.
En fait, c'est tres dommage que,
sur les compilo modernes, le mode par defaut ne soit pas hyper-strict.
Genre -Wall -O1 -Werror... mais pour ca, faudrait que gcc sache reconnaitre
les faux positifs, et separer les "warnings" des "warnings qui devaient
etre des erreurs" dans 100% des cas, quitte a etre biaise dans le sens
"laisser passer des warnings", mais bon.
Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers
transparents. Et de même que je refusais de lire un code mal indenté,
je refusais de chercher un bug dans un code qui laissait passer des
Warning avec -Wall -pedantic.
Au début, tu passes pour un sale c*n, mais les résultats à terme
sont bons.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Mais comme tu le disais, ça dépend si on peut s'appuyer sur une connaissance des étudiants de ce qu'est la mémoire. Si ça n'a pas été fait, faut en faire un peu. C'est plus facile d'enseigner le C après 30h d'architecure des ordinateurs.
Tu veux dire de t'appuyer sur des connaissances d'architecture pour enseigner le C ? Ça se discute, disons que ça dépend de ton objectif mais en ce qui concerne mes propres apprentissages, j'essaye d'éviter les empilements. Mais il est tout à fait possible de s'en passer. La mémoire est une abstraction et elle peut rester telle quand on enseigne le C. Probablement que dans des usages avancés voire spécialisés, des connaissances d'archi (et d'assembleur) peuvent être instructives voire utiles. Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc) est un bon outil pédagogique, ça fait vivre un programme, dommage que les interfaces soient un peu austères (même DDD).
Je suis un peu pessimiste sur le coup. Ce que tu decris ne marche pas avec toutes les populations d'etudiants. Pour que la memoire reste une abstraction, il faut qu'ils aient de bonnes capacites d'abstraction, justement. Meme avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire rentrer la notion de portabilite. La notion d'undefined behavior est tres difficile a integrer.
L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc (parce que c'est trop long) et qui me pondent du code qui "tombe en marche" (grace a la superbe idee de gcc d'initialiser a 0 les variables locales en -O0), et a qui j'ai un mal fou a expliquer que leur programme est buggue jusqu'a l'os...
Donc, j'ai du code buggue, et des questions, et je suis bien oblige d'expliquer que le code "tape" a cote, ce qu'une fonction avec pas le bon nombre de parametres va faire, et tout et tout.
On a les même étudiants.
En fait, c'est tres dommage que, sur les compilo modernes, le mode par defaut ne soit pas hyper-strict. Genre -Wall -O1 -Werror... mais pour ca, faudrait que gcc sache reconnaitre les faux positifs, et separer les "warnings" des "warnings qui devaient etre des erreurs" dans 100% des cas, quitte a etre biaise dans le sens "laisser passer des warnings", mais bon.
Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers transparents. Et de même que je refusais de lire un code mal indenté, je refusais de chercher un bug dans un code qui laissait passer des Warning avec -Wall -pedantic. Au début, tu passes pour un sale c*n, mais les résultats à terme sont bons.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Gabriel Dos Reis
Marc Boyer writes:
[...]
| Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | on demandait de le coder, en précisant bien que c'était pour l'exercice, | et que dans la "vraie vie", on utilisait strncpy, où sa propre | bibliothèque de chaine de char (on en faisait 2 différentes).
Savent-ils pourquoi ils font ça ? Sauront-ils écrire des programmes après ça ? Il y a une différence fondamentale entre écrire une bibliothèque et écrire un programme. Savoir implémenter une bibliothèque a des exigences souvent assez différentes de celles requises pour écrire un programme.
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
[...]
| Nous, on faisait le contraire. On leur donnait la spec de strcpy, et
| on demandait de le coder, en précisant bien que c'était pour l'exercice,
| et que dans la "vraie vie", on utilisait strncpy, où sa propre
| bibliothèque de chaine de char (on en faisait 2 différentes).
Savent-ils pourquoi ils font ça ? Sauront-ils écrire des programmes
après ça ? Il y a une différence fondamentale entre écrire une
bibliothèque et écrire un programme. Savoir implémenter une bibliothèque
a des exigences souvent assez différentes de celles requises pour écrire
un programme.
| Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | on demandait de le coder, en précisant bien que c'était pour l'exercice, | et que dans la "vraie vie", on utilisait strncpy, où sa propre | bibliothèque de chaine de char (on en faisait 2 différentes).
Savent-ils pourquoi ils font ça ? Sauront-ils écrire des programmes après ça ? Il y a une différence fondamentale entre écrire une bibliothèque et écrire un programme. Savoir implémenter une bibliothèque a des exigences souvent assez différentes de celles requises pour écrire un programme.
-- Gaby
Gabriel Dos Reis
candide writes:
[...]
| > Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | > on demandait de le coder, en précisant bien que c'était pour l'exercice, | | Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il | n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé | comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en | majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon | coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction. Mon premier cours de C++ voulait m'apprendre à écrire une class IntList ; je n'y suis plus jamais retourné.
-- Gaby
candide <candide@free.invalid> writes:
[...]
| > Nous, on faisait le contraire. On leur donnait la spec de strcpy, et
| > on demandait de le coder, en précisant bien que c'était pour l'exercice,
|
| Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il
| n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé
| comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en
| majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon
| coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction.
Mon premier cours de C++ voulait m'apprendre à écrire une class
IntList ; je n'y suis plus jamais retourné.
| > Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | > on demandait de le coder, en précisant bien que c'était pour l'exercice, | | Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il | n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé | comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en | majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon | coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction. Mon premier cours de C++ voulait m'apprendre à écrire une class IntList ; je n'y suis plus jamais retourné.
-- Gaby
espie
In article , Gabriel Dos Reis wrote:
(Marc Espie) writes:
[...]
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est | indispensable, montrer les idiomes vitaux aux etudiants, ca c'est | complique.
C'est certainement compliqué, mais je crois que c'est le but d'un cours de *programmation* en C. Le professeur peut faire l'économie de sa terreur pendant qu'il est en train de confronter cette délicatesse :-)
-- Gaby
Ca, je suis bien d'accord. Moi en general, mon principal souci, c'est d'arriver a organiser le fatras dans ma tete pour le faire digerer aux etudiants. Ca reclame une discipline mentale considerable. Il y a tellement de choses interessantes a dire des qu'on montre une ligne de code, tellement de digressions, tellement de culture sous-jacente... et pourtant, il faut en dire moins, sinon, on va totalement les noyer sous les choses qui, par necessite, doivent venir plus tard.
In article <87vdjln4oq.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
espie@lain.home (Marc Espie) writes:
[...]
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est
| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est
| complique.
C'est certainement compliqué, mais je crois que c'est le but d'un cours
de *programmation* en C. Le professeur peut faire l'économie de sa
terreur pendant qu'il est en train de confronter cette délicatesse :-)
-- Gaby
Ca, je suis bien d'accord. Moi en general, mon principal souci, c'est d'arriver
a organiser le fatras dans ma tete pour le faire digerer aux etudiants.
Ca reclame une discipline mentale considerable. Il y a tellement de choses
interessantes a dire des qu'on montre une ligne de code, tellement de
digressions, tellement de culture sous-jacente... et pourtant, il faut en
dire moins, sinon, on va totalement les noyer sous les choses qui, par
necessite, doivent venir plus tard.
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est | indispensable, montrer les idiomes vitaux aux etudiants, ca c'est | complique.
C'est certainement compliqué, mais je crois que c'est le but d'un cours de *programmation* en C. Le professeur peut faire l'économie de sa terreur pendant qu'il est en train de confronter cette délicatesse :-)
-- Gaby
Ca, je suis bien d'accord. Moi en general, mon principal souci, c'est d'arriver a organiser le fatras dans ma tete pour le faire digerer aux etudiants. Ca reclame une discipline mentale considerable. Il y a tellement de choses interessantes a dire des qu'on montre une ligne de code, tellement de digressions, tellement de culture sous-jacente... et pourtant, il faut en dire moins, sinon, on va totalement les noyer sous les choses qui, par necessite, doivent venir plus tard.
Gabriel Dos Reis
Marc Boyer writes:
[...]
| Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une | spécificité de l'informatique et de sa copie facile: quelque soit le sujet | que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h), | il en existe déjà au moins 50 implantations sur Google...
Fais leur écrire des *programmes*. Oui, ils trouveront des programmes similaires sur Google ; mais au moins ils sauront ce que c'est qu'un programme.
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
[...]
| Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une
| spécificité de l'informatique et de sa copie facile: quelque soit le sujet
| que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h),
| il en existe déjà au moins 50 implantations sur Google...
Fais leur écrire des *programmes*. Oui, ils trouveront des programmes
similaires sur Google ; mais au moins ils sauront ce que c'est qu'un programme.
| Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une | spécificité de l'informatique et de sa copie facile: quelque soit le sujet | que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h), | il en existe déjà au moins 50 implantations sur Google...
Fais leur écrire des *programmes*. Oui, ils trouveront des programmes similaires sur Google ; mais au moins ils sauront ce que c'est qu'un programme.
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
[...]
| Tu va au devant de 3 problèmes avec les biblo graphiques: | - d'abord, t'es obligé de présenter des "commandes magiques" pour que | ça marche (genre #include <titi.h> + compilation avec -I /usr/lib...), | te les faire installer sur les machines (et les universités sont pas | toutes riches en ingé système), et devoir déboguer des usages bizares | de la lib que tu n'avais pas imaginé | - un bon nombre d'étudiants passent leur temps à vouloir changer la | couleur de fond, la fonte, et passent à côté de l'objectif de | l'enseignement, | - les bibliothèques d'IHM fonctionnent sur une prog évenementielle | (ce qu'on appelait "callback"), qui demande encore du temps de | présentation.
Agreed.
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
[...]
| Tu va au devant de 3 problèmes avec les biblo graphiques:
| - d'abord, t'es obligé de présenter des "commandes magiques" pour que
| ça marche (genre #include <titi.h> + compilation avec -I /usr/lib...),
| te les faire installer sur les machines (et les universités sont pas
| toutes riches en ingé système), et devoir déboguer des usages bizares
| de la lib que tu n'avais pas imaginé
| - un bon nombre d'étudiants passent leur temps à vouloir changer la
| couleur de fond, la fonte, et passent à côté de l'objectif de
| l'enseignement,
| - les bibliothèques d'IHM fonctionnent sur une prog évenementielle
| (ce qu'on appelait "callback"), qui demande encore du temps de
| présentation.
| Tu va au devant de 3 problèmes avec les biblo graphiques: | - d'abord, t'es obligé de présenter des "commandes magiques" pour que | ça marche (genre #include <titi.h> + compilation avec -I /usr/lib...), | te les faire installer sur les machines (et les universités sont pas | toutes riches en ingé système), et devoir déboguer des usages bizares | de la lib que tu n'avais pas imaginé | - un bon nombre d'étudiants passent leur temps à vouloir changer la | couleur de fond, la fonte, et passent à côté de l'objectif de | l'enseignement, | - les bibliothèques d'IHM fonctionnent sur une prog évenementielle | (ce qu'on appelait "callback"), qui demande encore du temps de | présentation.
Agreed.
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
[...]
| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers | transparents. Et de même que je refusais de lire un code mal indenté, | je refusais de chercher un bug dans un code qui laissait passer des | Warning avec -Wall -pedantic.
Pour le premier devoir de maison, je fais savoir que tout devoir rendu qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié. Oh, j'exige aussi un Makefile pour le second devoir de maison.
(Cette année, le premier TD concerne l'utilisation de SVN -- cela aurait pu être n'importe quel VCS moderne. Après le premier devoir de maison, ils apprennent à écrire un Makefile.)
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
[...]
| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers
| transparents. Et de même que je refusais de lire un code mal indenté,
| je refusais de chercher un bug dans un code qui laissait passer des
| Warning avec -Wall -pedantic.
Pour le premier devoir de maison, je fais savoir que tout devoir rendu
qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié.
Oh, j'exige aussi un Makefile pour le second devoir de maison.
(Cette année, le premier TD concerne l'utilisation de SVN -- cela aurait pu
être n'importe quel VCS moderne. Après le premier devoir de maison, ils
apprennent à écrire un Makefile.)
| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers | transparents. Et de même que je refusais de lire un code mal indenté, | je refusais de chercher un bug dans un code qui laissait passer des | Warning avec -Wall -pedantic.
Pour le premier devoir de maison, je fais savoir que tout devoir rendu qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié. Oh, j'exige aussi un Makefile pour le second devoir de maison.
(Cette année, le premier TD concerne l'utilisation de SVN -- cela aurait pu être n'importe quel VCS moderne. Après le premier devoir de maison, ils apprennent à écrire un Makefile.)
-- Gaby
espie
In article , Gabriel Dos Reis wrote:
candide writes:
[...]
| > Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | > on demandait de le coder, en précisant bien que c'était pour l'exercice, | | Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il | n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé | comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en | majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon | coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction. Mon premier cours de C++ voulait m'apprendre à écrire une class IntList ; je n'y suis plus jamais retourné.
J'ai pratique l'implementation de strcpy une annee, pour voir. C'est effectivement bof.
Je leur montre un peu des trucs de style gestion de tableaux dynamiques, ce qui est plus ou moins necessaire a faire a la main en C (le style:
struct dyn { int *t; int size; int capacity; }; ) histoire qu'ils sachent a quel point c'est facile a faire, et ca permet de voir des trucs cote design d'API. Mais on fait ca ensemble en cours, et ils sont senses s'en servir ensuite.
Pour les projets, ils ont souvent le droit de se donner des tableaux de taille fixe arbitrairement grande. Tant qu'ils verifient que ca ne deborde pas, tout va bien... voire de mettre des structures de donnees triviales et peu efficaces. Ca me parait plus utile de leur expliquer COMMENT on pourra mecaniquement remplacer tout ca par des trucs plus efficaces ensuite s'ils ont bien fait leur boulot que de les faire ch* a reimplementer une n-eme bibliotheque de listes chainees/arbres equilibres, etc. Je vois des gros bouts de ca, mais en cours, pour leur montrer comment c'est cense marcher. Mais ca se dedramatise: c'est pas important. 99% de l'informatique se fait avec des structures tres simples. Si on connait un tableau redimensionnable, une table de hachage, et un arbre binaire NON equilibre, on se demerdera avec 99% des soucis. Le reste (arbre equilibre, files de priorite), ca se retrouve dans la litterature et ca s'integre UNIQUEMENT si necessaire... donc pas la peine pour 99,9% d'entre eux.
In article <87k501n4bd.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
candide <candide@free.invalid> writes:
[...]
| > Nous, on faisait le contraire. On leur donnait la spec de strcpy, et
| > on demandait de le coder, en précisant bien que c'était pour l'exercice,
|
| Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il
| n'est pas du tout évident quand on part de zéro d'arriver à un code
bien ciselé
| comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en
| majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon
| coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction.
Mon premier cours de C++ voulait m'apprendre à écrire une class
IntList ; je n'y suis plus jamais retourné.
J'ai pratique l'implementation de strcpy une annee, pour voir. C'est
effectivement bof.
Je leur montre un peu des trucs de style gestion de tableaux dynamiques,
ce qui est plus ou moins necessaire a faire a la main en C (le style:
struct dyn {
int *t;
int size;
int capacity;
}; )
histoire qu'ils sachent a quel point c'est facile a faire, et ca permet
de voir des trucs cote design d'API. Mais on fait ca ensemble en cours,
et ils sont senses s'en servir ensuite.
Pour les projets, ils ont souvent le droit de se donner des tableaux de
taille fixe arbitrairement grande. Tant qu'ils verifient que ca ne deborde
pas, tout va bien... voire de mettre des structures de donnees triviales
et peu efficaces. Ca me parait plus utile de leur expliquer COMMENT on pourra
mecaniquement remplacer tout ca par des trucs plus efficaces ensuite s'ils
ont bien fait leur boulot que de les faire ch* a reimplementer une n-eme
bibliotheque de listes chainees/arbres equilibres, etc. Je vois des gros
bouts de ca, mais en cours, pour leur montrer comment c'est cense marcher.
Mais ca se dedramatise: c'est pas important. 99% de l'informatique se fait
avec des structures tres simples. Si on connait un tableau redimensionnable,
une table de hachage, et un arbre binaire NON equilibre, on se demerdera
avec 99% des soucis. Le reste (arbre equilibre, files de priorite), ca
se retrouve dans la litterature et ca s'integre UNIQUEMENT si necessaire...
donc pas la peine pour 99,9% d'entre eux.
| > Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | > on demandait de le coder, en précisant bien que c'était pour l'exercice, | | Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il | n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé | comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en | majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon | coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction. Mon premier cours de C++ voulait m'apprendre à écrire une class IntList ; je n'y suis plus jamais retourné.
J'ai pratique l'implementation de strcpy une annee, pour voir. C'est effectivement bof.
Je leur montre un peu des trucs de style gestion de tableaux dynamiques, ce qui est plus ou moins necessaire a faire a la main en C (le style:
struct dyn { int *t; int size; int capacity; }; ) histoire qu'ils sachent a quel point c'est facile a faire, et ca permet de voir des trucs cote design d'API. Mais on fait ca ensemble en cours, et ils sont senses s'en servir ensuite.
Pour les projets, ils ont souvent le droit de se donner des tableaux de taille fixe arbitrairement grande. Tant qu'ils verifient que ca ne deborde pas, tout va bien... voire de mettre des structures de donnees triviales et peu efficaces. Ca me parait plus utile de leur expliquer COMMENT on pourra mecaniquement remplacer tout ca par des trucs plus efficaces ensuite s'ils ont bien fait leur boulot que de les faire ch* a reimplementer une n-eme bibliotheque de listes chainees/arbres equilibres, etc. Je vois des gros bouts de ca, mais en cours, pour leur montrer comment c'est cense marcher. Mais ca se dedramatise: c'est pas important. 99% de l'informatique se fait avec des structures tres simples. Si on connait un tableau redimensionnable, une table de hachage, et un arbre binaire NON equilibre, on se demerdera avec 99% des soucis. Le reste (arbre equilibre, files de priorite), ca se retrouve dans la litterature et ca s'integre UNIQUEMENT si necessaire... donc pas la peine pour 99,9% d'entre eux.
Gabriel Dos Reis
(Marc Espie) writes:
| In article <4aae1b2a$0$32766$, | candide wrote: | >Marc Espie a écrit : | > | >>> de "cours cours" ou avec TD et TP ? | >> | >> Cours-cours, | > | > | >Madre mia ! Vous leur faites 30 heures de cours sans le moindre TP ????? | >J'espère pour eux que tu fais tes cours sur video-projecteur avec gcc dans tes | >valises. | | Si, ils passent quand meme quelques heures en salle machine avec moi derriere, | pour les lancer (genre 3 ou 6h), mais pour le reste, c'est a eux d'essayer | de faire des trucs et de revenir avec des questions au cours suivant.
Je leur fais savoir très clairement que j'attends qu'ils travaillent plus de 10heures/semaine en déhors du cours sur les projets
| Faut dire que j'ai suffisamment d'experience pour pouvoir t'inventer | du listing sans faute au tableau. Comme tu as pu le voir ici, il y a des | points obscurs du C que je ne maitrise pas sans relire la norme, mais je | n'arrive jamais jusqu'a ces points obscurs en cours.
Et un cours de programmation devrait pas arriver à ces points obscures.
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <4aae1b2a$0$32766$426a34cc@news.free.fr>,
| candide <candide@free.invalid> wrote:
| >Marc Espie a écrit :
| >
| >>> de "cours cours" ou avec TD et TP ?
| >>
| >> Cours-cours,
| >
| >
| >Madre mia ! Vous leur faites 30 heures de cours sans le moindre TP ?????
| >J'espère pour eux que tu fais tes cours sur video-projecteur avec gcc dans tes
| >valises.
|
| Si, ils passent quand meme quelques heures en salle machine avec moi derriere,
| pour les lancer (genre 3 ou 6h), mais pour le reste, c'est a eux d'essayer
| de faire des trucs et de revenir avec des questions au cours suivant.
Je leur fais savoir très clairement que j'attends qu'ils travaillent
plus de 10heures/semaine en déhors du cours sur les projets
| Faut dire que j'ai suffisamment d'experience pour pouvoir t'inventer
| du listing sans faute au tableau. Comme tu as pu le voir ici, il y a des
| points obscurs du C que je ne maitrise pas sans relire la norme, mais je
| n'arrive jamais jusqu'a ces points obscurs en cours.
Et un cours de programmation devrait pas arriver à ces points obscures.
| In article <4aae1b2a$0$32766$, | candide wrote: | >Marc Espie a écrit : | > | >>> de "cours cours" ou avec TD et TP ? | >> | >> Cours-cours, | > | > | >Madre mia ! Vous leur faites 30 heures de cours sans le moindre TP ????? | >J'espère pour eux que tu fais tes cours sur video-projecteur avec gcc dans tes | >valises. | | Si, ils passent quand meme quelques heures en salle machine avec moi derriere, | pour les lancer (genre 3 ou 6h), mais pour le reste, c'est a eux d'essayer | de faire des trucs et de revenir avec des questions au cours suivant.
Je leur fais savoir très clairement que j'attends qu'ils travaillent plus de 10heures/semaine en déhors du cours sur les projets
| Faut dire que j'ai suffisamment d'experience pour pouvoir t'inventer | du listing sans faute au tableau. Comme tu as pu le voir ici, il y a des | points obscurs du C que je ne maitrise pas sans relire la norme, mais je | n'arrive jamais jusqu'a ces points obscurs en cours.
Et un cours de programmation devrait pas arriver à ces points obscures.
-- Gaby
Gabriel Dos Reis
(Marc Espie) writes:
| In article , | Gabriel Dos Reis wrote: | > (Marc Espie) writes: | > | >[...] | > | >| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est | >| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est | >| complique. | > | >C'est certainement compliqué, mais je crois que c'est le but d'un cours | >de *programmation* en C. Le professeur peut faire l'économie de sa | >terreur pendant qu'il est en train de confronter cette délicatesse :-) | > | >-- Gaby | | Ca, je suis bien d'accord. Moi en general, mon principal souci, c'est d'arriver | a organiser le fatras dans ma tete pour le faire digerer aux etudiants. | Ca reclame une discipline mentale considerable. Il y a tellement de choses | interessantes a dire des qu'on montre une ligne de code, tellement de | digressions, tellement de culture sous-jacente... et pourtant, il faut en | dire moins, sinon, on va totalement les noyer sous les choses qui, par | necessite, doivent venir plus tard.
Je suis d'accord. Pour le cours que je fais ce semestre, j'insiste à leur montrer systématiquement (vers la fin du cours) de vrais exemples de codes tirés de logiciels libres. Évidemment, cela bouffe du temps sur le reste mais je suppose que ces 10min valent 10 slides d'exemples factices. Cela me permet de discuter de l'ideal (ce que je voudrais qu'ils sachent faire) et ce qu'on trouve dans la pratique (qu'ils devraient émuler ou éviter). Mais, j'ai un projecteur et une machine portable avec plein de programme sources dessus :-)
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <87vdjln4oq.fsf@gauss.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| >espie@lain.home (Marc Espie) writes:
| >
| >[...]
| >
| >| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est
| >| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est
| >| complique.
| >
| >C'est certainement compliqué, mais je crois que c'est le but d'un cours
| >de *programmation* en C. Le professeur peut faire l'économie de sa
| >terreur pendant qu'il est en train de confronter cette délicatesse :-)
| >
| >-- Gaby
|
| Ca, je suis bien d'accord. Moi en general, mon principal souci, c'est d'arriver
| a organiser le fatras dans ma tete pour le faire digerer aux etudiants.
| Ca reclame une discipline mentale considerable. Il y a tellement de choses
| interessantes a dire des qu'on montre une ligne de code, tellement de
| digressions, tellement de culture sous-jacente... et pourtant, il faut en
| dire moins, sinon, on va totalement les noyer sous les choses qui, par
| necessite, doivent venir plus tard.
Je suis d'accord. Pour le cours que je fais ce semestre, j'insiste à
leur montrer systématiquement (vers la fin du cours) de vrais exemples
de codes tirés de logiciels libres. Évidemment, cela bouffe du temps
sur le reste mais je suppose que ces 10min valent 10 slides d'exemples
factices. Cela me permet de discuter de l'ideal (ce que je voudrais
qu'ils sachent faire) et ce qu'on trouve dans la pratique (qu'ils
devraient émuler ou éviter). Mais, j'ai un projecteur et une machine
portable avec plein de programme sources dessus :-)
| In article , | Gabriel Dos Reis wrote: | > (Marc Espie) writes: | > | >[...] | > | >| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est | >| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est | >| complique. | > | >C'est certainement compliqué, mais je crois que c'est le but d'un cours | >de *programmation* en C. Le professeur peut faire l'économie de sa | >terreur pendant qu'il est en train de confronter cette délicatesse :-) | > | >-- Gaby | | Ca, je suis bien d'accord. Moi en general, mon principal souci, c'est d'arriver | a organiser le fatras dans ma tete pour le faire digerer aux etudiants. | Ca reclame une discipline mentale considerable. Il y a tellement de choses | interessantes a dire des qu'on montre une ligne de code, tellement de | digressions, tellement de culture sous-jacente... et pourtant, il faut en | dire moins, sinon, on va totalement les noyer sous les choses qui, par | necessite, doivent venir plus tard.
Je suis d'accord. Pour le cours que je fais ce semestre, j'insiste à leur montrer systématiquement (vers la fin du cours) de vrais exemples de codes tirés de logiciels libres. Évidemment, cela bouffe du temps sur le reste mais je suppose que ces 10min valent 10 slides d'exemples factices. Cela me permet de discuter de l'ideal (ce que je voudrais qu'ils sachent faire) et ce qu'on trouve dans la pratique (qu'ils devraient émuler ou éviter). Mais, j'ai un projecteur et une machine portable avec plein de programme sources dessus :-)
