Pascal J. Bourguignon a écrit :Wykaaa writes:Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce
que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Je ne suis absolument pas d'accord, mais vraiment pas du tout, avec vous
car ce que l'on constate c'est que les débutants, quand ils sont "lâchés
dans la nature", reproduisent les premiers exemples qu'ils ont eu sous
les yeux.
Si ces exemples ne sont pas ce qu'on peut attendre d'un
programmeur professionnel, ce sera la catastrophe à moins que le
débutant ne se trouve dans un "environnement riche" avec un encadrement
au top (ce qui est de plus en plus rare de nos jours).
Je persiste à penser qu'il n'est pas plus dur de donner des exemples
professionnels dès le début.
Un des absolus de la qualité n'est-il pas,
d'ailleurs, de "le faire bien dès la première fois".
Pascal J. Bourguignon a écrit :
Wykaaa <wykaaa@yahoo.fr> writes:
Marc Boyer a écrit :
On 2009-02-02, Marc Espie <espie@lain.home> wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.
Si tu autorises les gens a prendre des habitudes differentes "parce
que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Je ne suis absolument pas d'accord, mais vraiment pas du tout, avec vous
car ce que l'on constate c'est que les débutants, quand ils sont "lâchés
dans la nature", reproduisent les premiers exemples qu'ils ont eu sous
les yeux.
Si ces exemples ne sont pas ce qu'on peut attendre d'un
programmeur professionnel, ce sera la catastrophe à moins que le
débutant ne se trouve dans un "environnement riche" avec un encadrement
au top (ce qui est de plus en plus rare de nos jours).
Je persiste à penser qu'il n'est pas plus dur de donner des exemples
professionnels dès le début.
Un des absolus de la qualité n'est-il pas,
d'ailleurs, de "le faire bien dès la première fois".
Pascal J. Bourguignon a écrit :Wykaaa writes:Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce
que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Je ne suis absolument pas d'accord, mais vraiment pas du tout, avec vous
car ce que l'on constate c'est que les débutants, quand ils sont "lâchés
dans la nature", reproduisent les premiers exemples qu'ils ont eu sous
les yeux.
Si ces exemples ne sont pas ce qu'on peut attendre d'un
programmeur professionnel, ce sera la catastrophe à moins que le
débutant ne se trouve dans un "environnement riche" avec un encadrement
au top (ce qui est de plus en plus rare de nos jours).
Je persiste à penser qu'il n'est pas plus dur de donner des exemples
professionnels dès le début.
Un des absolus de la qualité n'est-il pas,
d'ailleurs, de "le faire bien dès la première fois".
In article ,
Pascal J. Bourguignon wrote:C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Faut quand meme rappeler le contexte, hein. On parlait du bien-fonde
d'utiliser
using namespace std;
au top-level (et dans un fichier d'entete, de surcroit).
Le seul point que ca peut illustrer, c'est toutes les merdouilles qu'on
va se prendre avec de telles pratiques.
A proscrire absolument.
Un peu comme quand j'enseigne le C. Je ne parle que peu du preprocesseur,
et dans des contextes bien definis. Style,
#define TAILLE 1024
(necessaire en C, je le rappelle, puisque const int taille24; ne fonctionne
pas).
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
... avant tres tard, parce que c'est nocif avant le polymorphisme, et en C
moderne, on a inline de toutes facons.
Bref... fin de digression.
In article <7cab9234l3.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Faut quand meme rappeler le contexte, hein. On parlait du bien-fonde
d'utiliser
using namespace std;
au top-level (et dans un fichier d'entete, de surcroit).
Le seul point que ca peut illustrer, c'est toutes les merdouilles qu'on
va se prendre avec de telles pratiques.
A proscrire absolument.
Un peu comme quand j'enseigne le C. Je ne parle que peu du preprocesseur,
et dans des contextes bien definis. Style,
#define TAILLE 1024
(necessaire en C, je le rappelle, puisque const int taille24; ne fonctionne
pas).
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
... avant tres tard, parce que c'est nocif avant le polymorphisme, et en C
moderne, on a inline de toutes facons.
Bref... fin de digression.
In article ,
Pascal J. Bourguignon wrote:C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Faut quand meme rappeler le contexte, hein. On parlait du bien-fonde
d'utiliser
using namespace std;
au top-level (et dans un fichier d'entete, de surcroit).
Le seul point que ca peut illustrer, c'est toutes les merdouilles qu'on
va se prendre avec de telles pratiques.
A proscrire absolument.
Un peu comme quand j'enseigne le C. Je ne parle que peu du preprocesseur,
et dans des contextes bien definis. Style,
#define TAILLE 1024
(necessaire en C, je le rappelle, puisque const int taille24; ne fonctionne
pas).
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
... avant tres tard, parce que c'est nocif avant le polymorphisme, et en C
moderne, on a inline de toutes facons.
Bref... fin de digression.
Wykaaa wrote:Pascal J. Bourguignon a écrit :Wykaaa writes:Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes
"parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Je ne suis absolument pas d'accord, mais vraiment pas du tout, avec
vous car ce que l'on constate c'est que les débutants, quand ils sont
"lâchés dans la nature", reproduisent les premiers exemples qu'ils ont
eu sous les yeux.
Le problème est peut être le fait de les *lâcher dans la nature*
justement mais le fait que cela ne s'enseigne pas. Le professeur peut
tout juste donner les bases et aider en appréciation de ce que
l'étudiant fait.
Pour filer la métaphore de Pascal J. Bourguignon, il y a un monde entre
apprendre à lire et lire un français littéraire. Les professeurs de
littératures ne peuvent pas apprendre la littérature à leurs élèves, il
peuvent tout au plus leur décrypter certains livre; à la charge ensuite
de l'étudiant de développer sa sensibilité.
Si ces exemples ne sont pas ce qu'on peut attendre d'un programmeur
professionnel, ce sera la catastrophe à moins que le débutant ne se
trouve dans un "environnement riche" avec un encadrement au top (ce
qui est de plus en plus rare de nos jours).
Je persiste à penser qu'il n'est pas plus dur de donner des exemples
professionnels dès le début.
Un programme professionnel est normalement plus facile à lire donc je
suis d'accord. Mais si cela se fait au dépend de la lisibilité, je ne
pense pas.
Pour revenir au using namespace std;, je comprends que ça puisse rendre
les choses plus clair dans un header. Maintenant, l'étudiant doit savoir
qu'il ne peut le faire que dans un cadre didactique et pas dans un
environnement pro.
Un des absolus de la qualité n'est-il pas, d'ailleurs, de "le faire
bien dès la première fois".
C'est la traduction de "right first time" qui est décliné dans les faits
en "the measurement of quality is the price of non-conformance" i.e. la
qualité doit se mesurer par le coût de la qualité donc le coût de ce qui
n'est pas conforme dès le début.
Je ne vois pas en quoi cela s'applique ici, un TP a typiquement une
durée de vie très courte et ce que les étudiants en retiennent est
idéalement l'objectif du TP, pas la façon de programmer dans un langage
spécifique.
Ce qui n'empêchait pas mes professeurs, en soutenance de tester la
qualité de nos programmes pour les projets; mais les projets n'avaient
pas le temps limité d'un TP.
Wykaaa wrote:
Pascal J. Bourguignon a écrit :
Wykaaa <wykaaa@yahoo.fr> writes:
Marc Boyer a écrit :
On 2009-02-02, Marc Espie <espie@lain.home> wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.
Si tu autorises les gens a prendre des habitudes differentes
"parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Je ne suis absolument pas d'accord, mais vraiment pas du tout, avec
vous car ce que l'on constate c'est que les débutants, quand ils sont
"lâchés dans la nature", reproduisent les premiers exemples qu'ils ont
eu sous les yeux.
Le problème est peut être le fait de les *lâcher dans la nature*
justement mais le fait que cela ne s'enseigne pas. Le professeur peut
tout juste donner les bases et aider en appréciation de ce que
l'étudiant fait.
Pour filer la métaphore de Pascal J. Bourguignon, il y a un monde entre
apprendre à lire et lire un français littéraire. Les professeurs de
littératures ne peuvent pas apprendre la littérature à leurs élèves, il
peuvent tout au plus leur décrypter certains livre; à la charge ensuite
de l'étudiant de développer sa sensibilité.
Si ces exemples ne sont pas ce qu'on peut attendre d'un programmeur
professionnel, ce sera la catastrophe à moins que le débutant ne se
trouve dans un "environnement riche" avec un encadrement au top (ce
qui est de plus en plus rare de nos jours).
Je persiste à penser qu'il n'est pas plus dur de donner des exemples
professionnels dès le début.
Un programme professionnel est normalement plus facile à lire donc je
suis d'accord. Mais si cela se fait au dépend de la lisibilité, je ne
pense pas.
Pour revenir au using namespace std;, je comprends que ça puisse rendre
les choses plus clair dans un header. Maintenant, l'étudiant doit savoir
qu'il ne peut le faire que dans un cadre didactique et pas dans un
environnement pro.
Un des absolus de la qualité n'est-il pas, d'ailleurs, de "le faire
bien dès la première fois".
C'est la traduction de "right first time" qui est décliné dans les faits
en "the measurement of quality is the price of non-conformance" i.e. la
qualité doit se mesurer par le coût de la qualité donc le coût de ce qui
n'est pas conforme dès le début.
Je ne vois pas en quoi cela s'applique ici, un TP a typiquement une
durée de vie très courte et ce que les étudiants en retiennent est
idéalement l'objectif du TP, pas la façon de programmer dans un langage
spécifique.
Ce qui n'empêchait pas mes professeurs, en soutenance de tester la
qualité de nos programmes pour les projets; mais les projets n'avaient
pas le temps limité d'un TP.
Wykaaa wrote:Pascal J. Bourguignon a écrit :Wykaaa writes:Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes
"parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Je ne suis absolument pas d'accord, mais vraiment pas du tout, avec
vous car ce que l'on constate c'est que les débutants, quand ils sont
"lâchés dans la nature", reproduisent les premiers exemples qu'ils ont
eu sous les yeux.
Le problème est peut être le fait de les *lâcher dans la nature*
justement mais le fait que cela ne s'enseigne pas. Le professeur peut
tout juste donner les bases et aider en appréciation de ce que
l'étudiant fait.
Pour filer la métaphore de Pascal J. Bourguignon, il y a un monde entre
apprendre à lire et lire un français littéraire. Les professeurs de
littératures ne peuvent pas apprendre la littérature à leurs élèves, il
peuvent tout au plus leur décrypter certains livre; à la charge ensuite
de l'étudiant de développer sa sensibilité.
Si ces exemples ne sont pas ce qu'on peut attendre d'un programmeur
professionnel, ce sera la catastrophe à moins que le débutant ne se
trouve dans un "environnement riche" avec un encadrement au top (ce
qui est de plus en plus rare de nos jours).
Je persiste à penser qu'il n'est pas plus dur de donner des exemples
professionnels dès le début.
Un programme professionnel est normalement plus facile à lire donc je
suis d'accord. Mais si cela se fait au dépend de la lisibilité, je ne
pense pas.
Pour revenir au using namespace std;, je comprends que ça puisse rendre
les choses plus clair dans un header. Maintenant, l'étudiant doit savoir
qu'il ne peut le faire que dans un cadre didactique et pas dans un
environnement pro.
Un des absolus de la qualité n'est-il pas, d'ailleurs, de "le faire
bien dès la première fois".
C'est la traduction de "right first time" qui est décliné dans les faits
en "the measurement of quality is the price of non-conformance" i.e. la
qualité doit se mesurer par le coût de la qualité donc le coût de ce qui
n'est pas conforme dès le début.
Je ne vois pas en quoi cela s'applique ici, un TP a typiquement une
durée de vie très courte et ce que les étudiants en retiennent est
idéalement l'objectif du TP, pas la façon de programmer dans un langage
spécifique.
Ce qui n'empêchait pas mes professeurs, en soutenance de tester la
qualité de nos programmes pour les projets; mais les projets n'avaient
pas le temps limité d'un TP.
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter de
parler de la pratique du langage (comment il DOIT se pratiquer)
Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter de
parler de la pratique du langage (comment il DOIT se pratiquer)
Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter de
parler de la pratique du langage (comment il DOIT se pratiquer)
In article <4989af4b$0$4057$,
Wykaaa wrote:Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter de
parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code utilisant
gets! ou des bouts de code utilisant scanf sans verification de la valeur de
retour).
In article <4989af4b$0$4057$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter de
parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code utilisant
gets! ou des bouts de code utilisant scanf sans verification de la valeur de
retour).
In article <4989af4b$0$4057$,
Wykaaa wrote:Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter de
parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code utilisant
gets! ou des bouts de code utilisant scanf sans verification de la valeur de
retour).
In article ,
Pascal J. Bourguignon wrote:Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Tiens, ca faisait longtemps que tu n'avais pas essaye de nous vendre du lisp.
Ben non, je n'ai pas besoin d'etre nuance, parce que je parle d'un mecanisme
tres specifique dans le cadre d'un cours en particulier, c'est-a-dire les
macros du preprocesseur C. Ca n'est vraiment pas le moment d'essayer de
generaliser a d'autres langages.
Deja que quand je leur parle de portee lexicale et de problemes de capture,
en general, ca fait bloub bloub au fond de la piscine...
In article <7chc3a1c8s.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Tiens, ca faisait longtemps que tu n'avais pas essaye de nous vendre du lisp.
Ben non, je n'ai pas besoin d'etre nuance, parce que je parle d'un mecanisme
tres specifique dans le cadre d'un cours en particulier, c'est-a-dire les
macros du preprocesseur C. Ca n'est vraiment pas le moment d'essayer de
generaliser a d'autres langages.
Deja que quand je leur parle de portee lexicale et de problemes de capture,
en general, ca fait bloub bloub au fond de la piscine...
In article ,
Pascal J. Bourguignon wrote:Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Tiens, ca faisait longtemps que tu n'avais pas essaye de nous vendre du lisp.
Ben non, je n'ai pas besoin d'etre nuance, parce que je parle d'un mecanisme
tres specifique dans le cadre d'un cours en particulier, c'est-a-dire les
macros du preprocesseur C. Ca n'est vraiment pas le moment d'essayer de
generaliser a d'autres langages.
Deja que quand je leur parle de portee lexicale et de problemes de capture,
en general, ca fait bloub bloub au fond de la piscine...
Marc Espie a écrit :In article <4989af4b$0$4057$,
Wykaaa wrote:Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter
de parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code
utilisant
gets! ou des bouts de code utilisant scanf sans verification de la
valeur de
retour).
Un autre exemple : combien j'ai vu d'étudiants fraîchement émoulus de la
fac ou d'une grande école, incapables d'établir correctement les
dépendances en C++ d'une dizaine de .h et autant de .cpp et n'avoir
toujours pas compris la différence entre une déclaration et une
définition d'externe...
Je trouve cela vraiment triste !
Marc Espie a écrit :
In article <4989af4b$0$4057$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter
de parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code
utilisant
gets! ou des bouts de code utilisant scanf sans verification de la
valeur de
retour).
Un autre exemple : combien j'ai vu d'étudiants fraîchement émoulus de la
fac ou d'une grande école, incapables d'établir correctement les
dépendances en C++ d'une dizaine de .h et autant de .cpp et n'avoir
toujours pas compris la différence entre une déclaration et une
définition d'externe...
Je trouve cela vraiment triste !
Marc Espie a écrit :In article <4989af4b$0$4057$,
Wykaaa wrote:Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter
de parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code
utilisant
gets! ou des bouts de code utilisant scanf sans verification de la
valeur de
retour).
Un autre exemple : combien j'ai vu d'étudiants fraîchement émoulus de la
fac ou d'une grande école, incapables d'établir correctement les
dépendances en C++ d'une dizaine de .h et autant de .cpp et n'avoir
toujours pas compris la différence entre une déclaration et une
définition d'externe...
Je trouve cela vraiment triste !
In article ,
Pascal J. Bourguignon wrote:Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Tiens, ca faisait longtemps que tu n'avais pas essaye de nous vendre du lisp.
Ben non, je n'ai pas besoin d'etre nuance, parce que je parle d'un mecanisme
tres specifique dans le cadre d'un cours en particulier, c'est-a-dire les
macros du preprocesseur C. Ca n'est vraiment pas le moment d'essayer de
generaliser a d'autres langages.
Deja que quand je leur parle de portee lexicale et de problemes de capture,
en general, ca fait bloub bloub au fond de la piscine...
In article <7chc3a1c8s.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Tiens, ca faisait longtemps que tu n'avais pas essaye de nous vendre du lisp.
Ben non, je n'ai pas besoin d'etre nuance, parce que je parle d'un mecanisme
tres specifique dans le cadre d'un cours en particulier, c'est-a-dire les
macros du preprocesseur C. Ca n'est vraiment pas le moment d'essayer de
generaliser a d'autres langages.
Deja que quand je leur parle de portee lexicale et de problemes de capture,
en general, ca fait bloub bloub au fond de la piscine...
In article ,
Pascal J. Bourguignon wrote:Je leur dis qu'il existe des choses qui s'appellent des macros, que c'est
super-dangereux, et qu'ils n'ont aucune raison de s'en servir...
Tu devrais être plus nuancé et plus spécifique. Le système de macros
du préprocesseur du C fonctionnant par substitution _textuelle_ est en
effet dangereux, et à éviter dans la mesure du possible. Mais il y a
des systèmes de macros dans d'autres langages qui n'ont pas ce
problème est qui sont aussi peu problématique que n'importe quel autre
élément du langage, et peuvent donc être utilisées à bon escient par
tout programmeur compétent. (Oui, je pense aux macros de Lisp et
Scheme).
Tiens, ca faisait longtemps que tu n'avais pas essaye de nous vendre du lisp.
Ben non, je n'ai pas besoin d'etre nuance, parce que je parle d'un mecanisme
tres specifique dans le cadre d'un cours en particulier, c'est-a-dire les
macros du preprocesseur C. Ca n'est vraiment pas le moment d'essayer de
generaliser a d'autres langages.
Deja que quand je leur parle de portee lexicale et de problemes de capture,
en general, ca fait bloub bloub au fond de la piscine...
Wykaaa wrote:Marc Espie a écrit :In article <4989af4b$0$4057$,
Wykaaa wrote:Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter
de parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises
pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code
utilisant
gets! ou des bouts de code utilisant scanf sans verification de la
valeur de
retour).
Un autre exemple : combien j'ai vu d'étudiants fraîchement émoulus de
la fac ou d'une grande école, incapables d'établir correctement les
dépendances en C++ d'une dizaine de .h et autant de .cpp et n'avoir
toujours pas compris la différence entre une déclaration et une
définition d'externe...
Je trouve cela vraiment triste !
Sans vouloir déprécier ton ressenti, j'entends tellement de plaintes de
ce genre que:
1. soit il y à un problème d'éducation
2. soit la génération baisse
3. soit les attentes des pros sont trop haute
Concernant le point 1, j'ai eu des professeurs qui faisaient des erreurs
flagrantes de code mais ce n'était pas le sujet du cours alors on
passait. La question est de savoir si on forme des programmeurs ou des
ingénieurs:
- si on forme des programmeurs alors je suis d'accord qu'il faut
mettre l'accent sur la bonne utilisation du langage.
- si on forme des ingénieurs alors c'est à eux d'avoir la démarche de
maitriser leurs outils.
Ce qui nous ramène au point 2; ce qui est possible: je vois beaucoup de
jeunes pour qui l'informatique est un travail comme un autre. Dans ma
génération c'était encore une histoire de passion ou de réelle envie de
faire de l'informatique. Alors peut être y a-t-il une adaptation à faire
de la part des enseignants pour adresser ce type d'élève; je ne sais pas.
Concernant le point 3, c'est à la discrétion de chacun. Je me demande,
vu la multiplicité des technologies aujourd'hui si il est normal d'avoir
les même attentes sur un domaine particulier.
Pour revenir au sujet originel, je suis d'accord qu'il vaut mieux
montrer à l'élève la bonne pratique dès le début et qu'un TP ne doit pas
saborder cet objectif à la restriction que cela ne brouille pas le
message: je ne vois pas l'intérêt de faire écrire std:: ou
boost::bidule::subtruc:: à tout bout de champ si cela ne sers pas
l'objectif pédagogique du TP.
Wykaaa wrote:
Marc Espie a écrit :
In article <4989af4b$0$4057$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter
de parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises
pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code
utilisant
gets! ou des bouts de code utilisant scanf sans verification de la
valeur de
retour).
Un autre exemple : combien j'ai vu d'étudiants fraîchement émoulus de
la fac ou d'une grande école, incapables d'établir correctement les
dépendances en C++ d'une dizaine de .h et autant de .cpp et n'avoir
toujours pas compris la différence entre une déclaration et une
définition d'externe...
Je trouve cela vraiment triste !
Sans vouloir déprécier ton ressenti, j'entends tellement de plaintes de
ce genre que:
1. soit il y à un problème d'éducation
2. soit la génération baisse
3. soit les attentes des pros sont trop haute
Concernant le point 1, j'ai eu des professeurs qui faisaient des erreurs
flagrantes de code mais ce n'était pas le sujet du cours alors on
passait. La question est de savoir si on forme des programmeurs ou des
ingénieurs:
- si on forme des programmeurs alors je suis d'accord qu'il faut
mettre l'accent sur la bonne utilisation du langage.
- si on forme des ingénieurs alors c'est à eux d'avoir la démarche de
maitriser leurs outils.
Ce qui nous ramène au point 2; ce qui est possible: je vois beaucoup de
jeunes pour qui l'informatique est un travail comme un autre. Dans ma
génération c'était encore une histoire de passion ou de réelle envie de
faire de l'informatique. Alors peut être y a-t-il une adaptation à faire
de la part des enseignants pour adresser ce type d'élève; je ne sais pas.
Concernant le point 3, c'est à la discrétion de chacun. Je me demande,
vu la multiplicité des technologies aujourd'hui si il est normal d'avoir
les même attentes sur un domaine particulier.
Pour revenir au sujet originel, je suis d'accord qu'il vaut mieux
montrer à l'élève la bonne pratique dès le début et qu'un TP ne doit pas
saborder cet objectif à la restriction que cela ne brouille pas le
message: je ne vois pas l'intérêt de faire écrire std:: ou
boost::bidule::subtruc:: à tout bout de champ si cela ne sers pas
l'objectif pédagogique du TP.
Wykaaa wrote:Marc Espie a écrit :In article <4989af4b$0$4057$,
Wykaaa wrote:Non, le rôle du professeur ne se limite pas à donner "tout juste les
bases" comme vous dites, surtout en programmation. Il ne peut éviter
de parler de la pratique du langage (comment il DOIT se pratiquer)
Je vais etre tres mauvaise langue, mais j'ai vu suffisamment de charges
de TD occupes a faire des cours de C montrer de super-mauvaises
pratiques
pour ne pas avoir envie de faire pareil (exemple: des bouts de code
utilisant
gets! ou des bouts de code utilisant scanf sans verification de la
valeur de
retour).
Un autre exemple : combien j'ai vu d'étudiants fraîchement émoulus de
la fac ou d'une grande école, incapables d'établir correctement les
dépendances en C++ d'une dizaine de .h et autant de .cpp et n'avoir
toujours pas compris la différence entre une déclaration et une
définition d'externe...
Je trouve cela vraiment triste !
Sans vouloir déprécier ton ressenti, j'entends tellement de plaintes de
ce genre que:
1. soit il y à un problème d'éducation
2. soit la génération baisse
3. soit les attentes des pros sont trop haute
Concernant le point 1, j'ai eu des professeurs qui faisaient des erreurs
flagrantes de code mais ce n'était pas le sujet du cours alors on
passait. La question est de savoir si on forme des programmeurs ou des
ingénieurs:
- si on forme des programmeurs alors je suis d'accord qu'il faut
mettre l'accent sur la bonne utilisation du langage.
- si on forme des ingénieurs alors c'est à eux d'avoir la démarche de
maitriser leurs outils.
Ce qui nous ramène au point 2; ce qui est possible: je vois beaucoup de
jeunes pour qui l'informatique est un travail comme un autre. Dans ma
génération c'était encore une histoire de passion ou de réelle envie de
faire de l'informatique. Alors peut être y a-t-il une adaptation à faire
de la part des enseignants pour adresser ce type d'élève; je ne sais pas.
Concernant le point 3, c'est à la discrétion de chacun. Je me demande,
vu la multiplicité des technologies aujourd'hui si il est normal d'avoir
les même attentes sur un domaine particulier.
Pour revenir au sujet originel, je suis d'accord qu'il vaut mieux
montrer à l'élève la bonne pratique dès le début et qu'un TP ne doit pas
saborder cet objectif à la restriction que cela ne brouille pas le
message: je ne vois pas l'intérêt de faire écrire std:: ou
boost::bidule::subtruc:: à tout bout de champ si cela ne sers pas
l'objectif pédagogique du TP.