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.
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.
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.
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
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).
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).
Hélas ! C'est cela que j'essaie de dénoncer.
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...
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).
Hélas ! C'est cela que j'essaie de dénoncer.
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...
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).
Hélas ! C'est cela que j'essaie de dénoncer.
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...
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
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.
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
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.
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
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.
In article <498ab645$0$18363$,
Wykaaa wrote:On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
In article <498ab645$0$18363$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
In article <498ab645$0$18363$,
Wykaaa wrote:On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
In article <498ab645$0$18363$,
Wykaaa wrote:On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
Microsoft n'a pas du tout aide dans l'histoire: windows a totalement habitue
les gens a avoir des applis qui, parfois fonctionnent, et tres souvent
finissent en ecran bleu. Le tres fameux "c'est la faute a l'ordinateur", alors
que derriere il y a un debile leger a qui on a file une tache de programmation
qui outrepassait ses competences.
Si on fabriquait les immeubles comme on fait du logiciel, nous habiterions
tous dans des cabanes en bois...
In article <498ab645$0$18363$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
Microsoft n'a pas du tout aide dans l'histoire: windows a totalement habitue
les gens a avoir des applis qui, parfois fonctionnent, et tres souvent
finissent en ecran bleu. Le tres fameux "c'est la faute a l'ordinateur", alors
que derriere il y a un debile leger a qui on a file une tache de programmation
qui outrepassait ses competences.
Si on fabriquait les immeubles comme on fait du logiciel, nous habiterions
tous dans des cabanes en bois...
In article <498ab645$0$18363$,
Wykaaa wrote:On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
Microsoft n'a pas du tout aide dans l'histoire: windows a totalement habitue
les gens a avoir des applis qui, parfois fonctionnent, et tres souvent
finissent en ecran bleu. Le tres fameux "c'est la faute a l'ordinateur", alors
que derriere il y a un debile leger a qui on a file une tache de programmation
qui outrepassait ses competences.
Si on fabriquait les immeubles comme on fait du logiciel, nous habiterions
tous dans des cabanes en bois...
On 2009-02-05, Michael DOUBEZ wrote: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
C'est systémique:
2. Le niveau baisse: depuis que l'homme a inventé l'écriture, il a
écrit pour se plaindre du niveau des jeunes (babylone, grece, rome, etc).
3. Tout le monde (et les industriels avec) cherche le mouton a 5 pates:
le diplomé jeune, spécialiste mais polyvalent, avec 5 ans d'expérience
mais travaillant pour un salaire de débutant, excellent technicien
avec un profil de futur cadre.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.
Les enseignants font leur possible: mais avec des gens pas motivés,
c'est toujours plus dur.
Et puis les programmes enflent en informatique.
Au tout début, on apprenait
electronique / Algorithmique / ASM
et puis, sont arrivés le C et le LISP (et Pascal, etc.)
circuits logique / Algorithmique / ASM / C / LISP / Compilation / OS
et puis sont arrivées les langage 3G (C++, Java, Ada, POO)
circuits logique / Algorithmique / ASM / C / LISP / Compilation / OS / POO / LOO
et puis on a maintenant toutes les Weberies JSP, ASP, J2EEE, etc.
Je parle pas des BD, des réseaux, de la sécu...
Marc Boyer
On 2009-02-05, Michael DOUBEZ <michael.doubez@free.fr> wrote:
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
C'est systémique:
2. Le niveau baisse: depuis que l'homme a inventé l'écriture, il a
écrit pour se plaindre du niveau des jeunes (babylone, grece, rome, etc).
3. Tout le monde (et les industriels avec) cherche le mouton a 5 pates:
le diplomé jeune, spécialiste mais polyvalent, avec 5 ans d'expérience
mais travaillant pour un salaire de débutant, excellent technicien
avec un profil de futur cadre.
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.
Les enseignants font leur possible: mais avec des gens pas motivés,
c'est toujours plus dur.
Et puis les programmes enflent en informatique.
Au tout début, on apprenait
electronique / Algorithmique / ASM
et puis, sont arrivés le C et le LISP (et Pascal, etc.)
circuits logique / Algorithmique / ASM / C / LISP / Compilation / OS
et puis sont arrivées les langage 3G (C++, Java, Ada, POO)
circuits logique / Algorithmique / ASM / C / LISP / Compilation / OS / POO / LOO
et puis on a maintenant toutes les Weberies JSP, ASP, J2EEE, etc.
Je parle pas des BD, des réseaux, de la sécu...
Marc Boyer
On 2009-02-05, Michael DOUBEZ wrote: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
C'est systémique:
2. Le niveau baisse: depuis que l'homme a inventé l'écriture, il a
écrit pour se plaindre du niveau des jeunes (babylone, grece, rome, etc).
3. Tout le monde (et les industriels avec) cherche le mouton a 5 pates:
le diplomé jeune, spécialiste mais polyvalent, avec 5 ans d'expérience
mais travaillant pour un salaire de débutant, excellent technicien
avec un profil de futur cadre.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.
Les enseignants font leur possible: mais avec des gens pas motivés,
c'est toujours plus dur.
Et puis les programmes enflent en informatique.
Au tout début, on apprenait
electronique / Algorithmique / ASM
et puis, sont arrivés le C et le LISP (et Pascal, etc.)
circuits logique / Algorithmique / ASM / C / LISP / Compilation / OS
et puis sont arrivées les langage 3G (C++, Java, Ada, POO)
circuits logique / Algorithmique / ASM / C / LISP / Compilation / OS / POO / LOO
et puis on a maintenant toutes les Weberies JSP, ASP, J2EEE, etc.
Je parle pas des BD, des réseaux, de la sécu...
Marc Boyer
Je suis d'accord qu'il n'y a plus le côté "passionné" car
l'informatique n'est plus quelque chose de "nouveau" pour la
génération actuelle. Elle est "née avec" alors que pour nous ce
n'était pas le cas.
D'ailleurs lors d'une évaluation d'un de mes cours (j'ai fait des
formations d'adultes en entreprise : conception objet, C, C++, Java,
Ada, JavaScript, etc.), un (jeune) participant avait mis en remarque :
"trop passionné". Ceci m'avait choqué car pour moi c'était une
qualité...
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.
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si
on fait un logiciel de facturation... (ce sont les fameux "cost
drivers" du modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes,
ce sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
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.
Oui mais si ça sert l'objectif qualité ou l'objectif de "c'est comme
ça qu'on doit faire dans ce cas précis" ?
Je suis d'accord qu'il n'y a plus le côté "passionné" car
l'informatique n'est plus quelque chose de "nouveau" pour la
génération actuelle. Elle est "née avec" alors que pour nous ce
n'était pas le cas.
D'ailleurs lors d'une évaluation d'un de mes cours (j'ai fait des
formations d'adultes en entreprise : conception objet, C, C++, Java,
Ada, JavaScript, etc.), un (jeune) participant avait mis en remarque :
"trop passionné". Ceci m'avait choqué car pour moi c'était une
qualité...
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.
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si
on fait un logiciel de facturation... (ce sont les fameux "cost
drivers" du modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes,
ce sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
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.
Oui mais si ça sert l'objectif qualité ou l'objectif de "c'est comme
ça qu'on doit faire dans ce cas précis" ?
Je suis d'accord qu'il n'y a plus le côté "passionné" car
l'informatique n'est plus quelque chose de "nouveau" pour la
génération actuelle. Elle est "née avec" alors que pour nous ce
n'était pas le cas.
D'ailleurs lors d'une évaluation d'un de mes cours (j'ai fait des
formations d'adultes en entreprise : conception objet, C, C++, Java,
Ada, JavaScript, etc.), un (jeune) participant avait mis en remarque :
"trop passionné". Ceci m'avait choqué car pour moi c'était une
qualité...
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.
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si
on fait un logiciel de facturation... (ce sont les fameux "cost
drivers" du modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes,
ce sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
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.
Oui mais si ça sert l'objectif qualité ou l'objectif de "c'est comme
ça qu'on doit faire dans ce cas précis" ?
In article <498ab645$0$18363$,
Wykaaa wrote:On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
Microsoft n'a pas du tout aide dans l'histoire: windows a totalement habitue
les gens a avoir des applis qui, parfois fonctionnent, et tres souvent
finissent en ecran bleu. Le tres fameux "c'est la faute a l'ordinateur", alors
que derriere il y a un debile leger a qui on a file une tache de programmation
qui outrepassait ses competences.
Si on fabriquait les immeubles comme on fait du logiciel, nous habiterions
tous dans des cabanes en bois...
In article <498ab645$0$18363$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
Microsoft n'a pas du tout aide dans l'histoire: windows a totalement habitue
les gens a avoir des applis qui, parfois fonctionnent, et tres souvent
finissent en ecran bleu. Le tres fameux "c'est la faute a l'ordinateur", alors
que derriere il y a un debile leger a qui on a file une tache de programmation
qui outrepassait ses competences.
Si on fabriquait les immeubles comme on fait du logiciel, nous habiterions
tous dans des cabanes en bois...
In article <498ab645$0$18363$,
Wykaaa wrote:On ne peut pas raisonner en disant "les attentes des pros sont trop
hautes". Leurs attentes, on s'en fiche. C'est chaque application qui a
ses exigences. Si on fait un logiciel pour le pilotage d'une centrale
nucléaire, le niveau d'exigence qualité ne va pas être le même que si on
fait un logiciel de facturation... (ce sont les fameux "cost drivers" du
modèle d'estimation de coût des logiciels de Barry Boehm).
En résumé, ce ne sont pas les pros qui ont des exigences trop hautes, ce
sont les applications, en fonction de leur caractéristiques, qui
requièrent certains types d'exigences.
Moi je trouve au contraire que les attentes de l'industrie sont trop basses.
C'est pour ca qu'on se retrouve avec plein de logiciels qui ne marchent pas
bien, plein de problemes de securite, et des maitrise d'ouvrages debordees
sur des "evolutions" qui ne devraient pas avoir lieu d'etre.
A l'exception de quelques domaines specifiques (nucleaire, militaire), les
applications sont programmees comme des gorets par des non passionnes. On
se retrouve avec des trucs lourds qui plombent la vie de la secretaire, ou
des applications de gestion de stock ou de telephone qui plantouillent (ce qui
peut etre dommage si celles-ci sont utilisees pour gerer les stocks d'un
hopital, ou un centre d'appel pompiers/samu...)
Microsoft n'a pas du tout aide dans l'histoire: windows a totalement habitue
les gens a avoir des applis qui, parfois fonctionnent, et tres souvent
finissent en ecran bleu. Le tres fameux "c'est la faute a l'ordinateur", alors
que derriere il y a un debile leger a qui on a file une tache de programmation
qui outrepassait ses competences.
Si on fabriquait les immeubles comme on fait du logiciel, nous habiterions
tous dans des cabanes en bois...