Le 27/05/2010 14:11, Marc Boyer a fait rien qu'à écrire :C'est un des pb que je rencontre en discutant avec des pros du dev
qui donnent leur avis sur l'enseignement de la programmation: comme
ils ont fait partie des 20% qui s'en sont sorti, ils trouvent que c'est
une bonne voie.
Oui, et c'est bien normal. Si tu t'en sort, alors tu penses que ta
Voie était bonne. Les 80 autres % pensent certainement l'inverse =)
Subjectif, tout ça, non..
(Note. 80-20, c'est pas une mesure, c'est un chiffre 'à l'arrache'
mais qui va bien, on le trouve un peu partout)
Bon, c'est dommage que l'OP donne pas son point de vue - des tas de
gens lui ont posé des tas de questions, sans réponse - mais je suis
tenté de dire que si au bout d'1 an, on en est toujours à tester des
malloc( 1 ) dans une boucle, c'est peut-être qu'on a visé un peu haut..
Ou que ce n'est pas la bonne voie.
Oui, si tu veux, mais je suis tenté de dire que si la /Bonne Voie/(c)(tm)
existait, alors on s'y engouffrerait tous, débutants comme pro's,
et tout serait bonheur de joie.
> J'aime bien le concept dela courbe d'apprentissage, qui trace la productivité par rapport
à l'effort d'apprentissage.
(Pinaise, heureusement que t'es pas mon chef =)
Bon, comment tu traces les 2 courbes: 'productivité' et 'effort
apprentissage' ? En x, on peut mettre le temps, je suppose ; et en y ?
Avec le C comme premier langage, la première marche est très haute.
Je pense qu'on peut aller aussi loin avec des démarches plus douces
en entrée de jeu.
Ah mais oui, si une méthode douce existe, pourquoi se faire inutilement
de mal, tout à fait..
Mais à l'inverse, le fait d'avoir pratiqué d'autres languages n'implique
pas que le C va rentrer comme dans du beurre. La marche est haute de
toutes façons, mais la pente est rose waf waf waf dès le matin..
Et puis bon, en 2010, devoir se taper la gestion de la mémoire à
la main, n'est-ce pas un pb qu'on peut éviter dans 95% des cas ?
Euh. Qu'est-ce que tu entends, précisément, par 'à la main': au malloc(3) ?..
Parce que dans ce cas, en 2010 comme chaque année depuis 70 (au moins),
la mémoire se gère à la main, dans 95 ? 99 ? 100-O(1) % ? des cas,
le C n'ayant pas de mécanisme de ramassage des poubelles..
Du reste, c'est complètement dépendant de ce que tu implémentes.
Le 27/05/2010 14:11, Marc Boyer a fait rien qu'à écrire :
C'est un des pb que je rencontre en discutant avec des pros du dev
qui donnent leur avis sur l'enseignement de la programmation: comme
ils ont fait partie des 20% qui s'en sont sorti, ils trouvent que c'est
une bonne voie.
Oui, et c'est bien normal. Si tu t'en sort, alors tu penses que ta
Voie était bonne. Les 80 autres % pensent certainement l'inverse =)
Subjectif, tout ça, non..
(Note. 80-20, c'est pas une mesure, c'est un chiffre 'à l'arrache'
mais qui va bien, on le trouve un peu partout)
Bon, c'est dommage que l'OP donne pas son point de vue - des tas de
gens lui ont posé des tas de questions, sans réponse - mais je suis
tenté de dire que si au bout d'1 an, on en est toujours à tester des
malloc( 1 ) dans une boucle, c'est peut-être qu'on a visé un peu haut..
Ou que ce n'est pas la bonne voie.
Oui, si tu veux, mais je suis tenté de dire que si la /Bonne Voie/(c)(tm)
existait, alors on s'y engouffrerait tous, débutants comme pro's,
et tout serait bonheur de joie.
> J'aime bien le concept de
la courbe d'apprentissage, qui trace la productivité par rapport
à l'effort d'apprentissage.
(Pinaise, heureusement que t'es pas mon chef =)
Bon, comment tu traces les 2 courbes: 'productivité' et 'effort
apprentissage' ? En x, on peut mettre le temps, je suppose ; et en y ?
Avec le C comme premier langage, la première marche est très haute.
Je pense qu'on peut aller aussi loin avec des démarches plus douces
en entrée de jeu.
Ah mais oui, si une méthode douce existe, pourquoi se faire inutilement
de mal, tout à fait..
Mais à l'inverse, le fait d'avoir pratiqué d'autres languages n'implique
pas que le C va rentrer comme dans du beurre. La marche est haute de
toutes façons, mais la pente est rose waf waf waf dès le matin..
Et puis bon, en 2010, devoir se taper la gestion de la mémoire à
la main, n'est-ce pas un pb qu'on peut éviter dans 95% des cas ?
Euh. Qu'est-ce que tu entends, précisément, par 'à la main': au malloc(3) ?..
Parce que dans ce cas, en 2010 comme chaque année depuis 70 (au moins),
la mémoire se gère à la main, dans 95 ? 99 ? 100-O(1) % ? des cas,
le C n'ayant pas de mécanisme de ramassage des poubelles..
Du reste, c'est complètement dépendant de ce que tu implémentes.
Le 27/05/2010 14:11, Marc Boyer a fait rien qu'à écrire :C'est un des pb que je rencontre en discutant avec des pros du dev
qui donnent leur avis sur l'enseignement de la programmation: comme
ils ont fait partie des 20% qui s'en sont sorti, ils trouvent que c'est
une bonne voie.
Oui, et c'est bien normal. Si tu t'en sort, alors tu penses que ta
Voie était bonne. Les 80 autres % pensent certainement l'inverse =)
Subjectif, tout ça, non..
(Note. 80-20, c'est pas une mesure, c'est un chiffre 'à l'arrache'
mais qui va bien, on le trouve un peu partout)
Bon, c'est dommage que l'OP donne pas son point de vue - des tas de
gens lui ont posé des tas de questions, sans réponse - mais je suis
tenté de dire que si au bout d'1 an, on en est toujours à tester des
malloc( 1 ) dans une boucle, c'est peut-être qu'on a visé un peu haut..
Ou que ce n'est pas la bonne voie.
Oui, si tu veux, mais je suis tenté de dire que si la /Bonne Voie/(c)(tm)
existait, alors on s'y engouffrerait tous, débutants comme pro's,
et tout serait bonheur de joie.
> J'aime bien le concept dela courbe d'apprentissage, qui trace la productivité par rapport
à l'effort d'apprentissage.
(Pinaise, heureusement que t'es pas mon chef =)
Bon, comment tu traces les 2 courbes: 'productivité' et 'effort
apprentissage' ? En x, on peut mettre le temps, je suppose ; et en y ?
Avec le C comme premier langage, la première marche est très haute.
Je pense qu'on peut aller aussi loin avec des démarches plus douces
en entrée de jeu.
Ah mais oui, si une méthode douce existe, pourquoi se faire inutilement
de mal, tout à fait..
Mais à l'inverse, le fait d'avoir pratiqué d'autres languages n'implique
pas que le C va rentrer comme dans du beurre. La marche est haute de
toutes façons, mais la pente est rose waf waf waf dès le matin..
Et puis bon, en 2010, devoir se taper la gestion de la mémoire à
la main, n'est-ce pas un pb qu'on peut éviter dans 95% des cas ?
Euh. Qu'est-ce que tu entends, précisément, par 'à la main': au malloc(3) ?..
Parce que dans ce cas, en 2010 comme chaque année depuis 70 (au moins),
la mémoire se gère à la main, dans 95 ? 99 ? 100-O(1) % ? des cas,
le C n'ayant pas de mécanisme de ramassage des poubelles..
Du reste, c'est complètement dépendant de ce que tu implémentes.
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Antoine Leca ?crivait dans fr.comp.lang.c :JKB a écrit :Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
Soit je n'ai pas vraiment compris
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Antoine Leca ?crivait dans fr.comp.lang.c :
JKB a écrit :
Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
Soit je n'ai pas vraiment compris
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Antoine Leca ?crivait dans fr.comp.lang.c :JKB a écrit :Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
Soit je n'ai pas vraiment compris
Non: tu as plusieurs pb. L'algorithmique, les E/S, la gestion mémoire.
En 2010, on devrait pouvoir entrer un ÿ dans une chaine sans se soucier
des conversions char / unsigned char / int qui font que ton code s'arrête.
Un language ou tu peux faire x = y, puis avoir le test x == y qui renvoie
faux, c'est piégeant...
Non: tu as plusieurs pb. L'algorithmique, les E/S, la gestion mémoire.
En 2010, on devrait pouvoir entrer un ÿ dans une chaine sans se soucier
des conversions char / unsigned char / int qui font que ton code s'arrête.
Un language ou tu peux faire x = y, puis avoir le test x == y qui renvoie
faux, c'est piégeant...
Non: tu as plusieurs pb. L'algorithmique, les E/S, la gestion mémoire.
En 2010, on devrait pouvoir entrer un ÿ dans une chaine sans se soucier
des conversions char / unsigned char / int qui font que ton code s'arrête.
Un language ou tu peux faire x = y, puis avoir le test x == y qui renvoie
faux, c'est piégeant...
JKB écrivit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Antoine Leca ?crivait dans fr.comp.lang.c :JKB a écrit :Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
Soit je n'ai pas vraiment compris
Euh, vu ta réponse et celle de Marc E., j'ai bien l'impression que la
plaisanterie était incompréhensible. Désolé.
JKB écrivit :
Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Antoine Leca ?crivait dans fr.comp.lang.c :
JKB a écrit :
Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
Soit je n'ai pas vraiment compris
Euh, vu ta réponse et celle de Marc E., j'ai bien l'impression que la
plaisanterie était incompréhensible. Désolé.
JKB écrivit :Le 27-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Antoine Leca ?crivait dans fr.comp.lang.c :JKB a écrit :Vi + gcc + gdb pour tout le monde ;-)
Heu.... C'est soit vi + sdb ou équivalent, soit emacs + gdb/dbx, sinon
tu mélanges les torchons et les serviettes...
Ok, hors charte, je sors :-)
Soit je n'ai pas vraiment compris
Euh, vu ta réponse et celle de Marc E., j'ai bien l'impression que la
plaisanterie était incompréhensible. Désolé.
Non. Tu ne peux pas écrire en fortran un truc aussi imbitable pour
un débutant que :
inline char *
strcpy(char *out, char *int) {
char *r;
for(*out=*in; *++in==0; *++out=*in);
(pas taper, pas testé...).
Non. Tu ne peux pas écrire en fortran un truc aussi imbitable pour
un débutant que :
inline char *
strcpy(char *out, char *int) {
char *r;
for(*out=*in; *++in==0; *++out=*in);
(pas taper, pas testé...).
Non. Tu ne peux pas écrire en fortran un truc aussi imbitable pour
un débutant que :
inline char *
strcpy(char *out, char *int) {
char *r;
for(*out=*in; *++in==0; *++out=*in);
(pas taper, pas testé...).
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
xtof.pernod ?crivait dans fr.comp.lang.c :[ramassage des poubelles..;]
En même temps, l'ultime et terminal ramasseur de poubelles, pour moi,
c'est exit(2). Robuste, efficace, économe, portable: incontournable !
Pourquoi ne mets-tu pas l'adresse de chaque bloc alloué dans une
liste chaînée avec un at_exit() qui balance un free() sur chaque
bloc encore alloué à la fin du programme ? ;-)
Ne rigolez pas, j'ai déjà dû utiliser de genre de chose... :-(
JKB
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
xtof.pernod ?crivait dans fr.comp.lang.c :
[ramassage des poubelles..;]
En même temps, l'ultime et terminal ramasseur de poubelles, pour moi,
c'est exit(2). Robuste, efficace, économe, portable: incontournable !
Pourquoi ne mets-tu pas l'adresse de chaque bloc alloué dans une
liste chaînée avec un at_exit() qui balance un free() sur chaque
bloc encore alloué à la fin du programme ? ;-)
Ne rigolez pas, j'ai déjà dû utiliser de genre de chose... :-(
JKB
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
xtof.pernod ?crivait dans fr.comp.lang.c :[ramassage des poubelles..;]
En même temps, l'ultime et terminal ramasseur de poubelles, pour moi,
c'est exit(2). Robuste, efficace, économe, portable: incontournable !
Pourquoi ne mets-tu pas l'adresse de chaque bloc alloué dans une
liste chaînée avec un at_exit() qui balance un free() sur chaque
bloc encore alloué à la fin du programme ? ;-)
Ne rigolez pas, j'ai déjà dû utiliser de genre de chose... :-(
JKB
JKB écrivit :Non. Tu ne peux pas écrire en fortran un truc aussi imbitable pour
un débutant que :
inline char *
strcpy(char *out, char *int) {
char *r;
for(*out=*in; *++in==0; *++out=*in);
Mouais. C'est vrai que c'est impossible (à ma connaissance), mais pas
parce que c'est incompréhensible, seulement parce que cela fait appel à
une notion absente du Fortran, en l'occurrence l'utilisation du
caractère NUL pour représenter la fin d'une chaîne en mémoire.
Pour autant, il est très facile d'écrire du code Fortran bien
incompréhensible, que ce soit avec COMMON ou avec des trucs comme
DO2i=1,10
2 a(i,i)=1
(pas taper, pas testé...).
Moi non plus :-)
JKB écrivit :
Non. Tu ne peux pas écrire en fortran un truc aussi imbitable pour
un débutant que :
inline char *
strcpy(char *out, char *int) {
char *r;
for(*out=*in; *++in==0; *++out=*in);
Mouais. C'est vrai que c'est impossible (à ma connaissance), mais pas
parce que c'est incompréhensible, seulement parce que cela fait appel à
une notion absente du Fortran, en l'occurrence l'utilisation du
caractère NUL pour représenter la fin d'une chaîne en mémoire.
Pour autant, il est très facile d'écrire du code Fortran bien
incompréhensible, que ce soit avec COMMON ou avec des trucs comme
DO2i=1,10
2 a(i,i)=1
(pas taper, pas testé...).
Moi non plus :-)
JKB écrivit :Non. Tu ne peux pas écrire en fortran un truc aussi imbitable pour
un débutant que :
inline char *
strcpy(char *out, char *int) {
char *r;
for(*out=*in; *++in==0; *++out=*in);
Mouais. C'est vrai que c'est impossible (à ma connaissance), mais pas
parce que c'est incompréhensible, seulement parce que cela fait appel à
une notion absente du Fortran, en l'occurrence l'utilisation du
caractère NUL pour représenter la fin d'une chaîne en mémoire.
Pour autant, il est très facile d'écrire du code Fortran bien
incompréhensible, que ce soit avec COMMON ou avec des trucs comme
DO2i=1,10
2 a(i,i)=1
(pas taper, pas testé...).
Moi non plus :-)
Le 28/05/2010 09:29, JKB a fait rien qu'à écrire :Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
xtof.pernod ?crivait dans fr.comp.lang.c :[ramassage des poubelles..;]
En même temps, l'ultime et terminal ramasseur de poubelles, pour moi,
c'est exit(2). Robuste, efficace, économe, portable: incontournable !
Pourquoi ne mets-tu pas l'adresse de chaque bloc alloué dans une
liste chaînée avec un at_exit() qui balance un free() sur chaque
bloc encore alloué à la fin du programme ? ;-)
oooh, ben:
Pasque 1/ j'ai pas utilisé de liste chainée depuis ma lecture du K&R,
ou alors à mon insu
2/ le 1er & dernier coup que j'ai utilisé atexit(3), sizof(int)
retournait 2 et malloc(3) permettait d'allouer 65528 max.
3/ comme d'hab, je vois pas ta motivation, pour ton cas &
d'après ce que tu en dis, pour moi exit() s'en chargera =)
Le 28/05/2010 09:29, JKB a fait rien qu'à écrire :
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
xtof.pernod ?crivait dans fr.comp.lang.c :
[ramassage des poubelles..;]
En même temps, l'ultime et terminal ramasseur de poubelles, pour moi,
c'est exit(2). Robuste, efficace, économe, portable: incontournable !
Pourquoi ne mets-tu pas l'adresse de chaque bloc alloué dans une
liste chaînée avec un at_exit() qui balance un free() sur chaque
bloc encore alloué à la fin du programme ? ;-)
oooh, ben:
Pasque 1/ j'ai pas utilisé de liste chainée depuis ma lecture du K&R,
ou alors à mon insu
2/ le 1er & dernier coup que j'ai utilisé atexit(3), sizof(int)
retournait 2 et malloc(3) permettait d'allouer 65528 max.
3/ comme d'hab, je vois pas ta motivation, pour ton cas &
d'après ce que tu en dis, pour moi exit() s'en chargera =)
Le 28/05/2010 09:29, JKB a fait rien qu'à écrire :Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
xtof.pernod ?crivait dans fr.comp.lang.c :[ramassage des poubelles..;]
En même temps, l'ultime et terminal ramasseur de poubelles, pour moi,
c'est exit(2). Robuste, efficace, économe, portable: incontournable !
Pourquoi ne mets-tu pas l'adresse de chaque bloc alloué dans une
liste chaînée avec un at_exit() qui balance un free() sur chaque
bloc encore alloué à la fin du programme ? ;-)
oooh, ben:
Pasque 1/ j'ai pas utilisé de liste chainée depuis ma lecture du K&R,
ou alors à mon insu
2/ le 1er & dernier coup que j'ai utilisé atexit(3), sizof(int)
retournait 2 et malloc(3) permettait d'allouer 65528 max.
3/ comme d'hab, je vois pas ta motivation, pour ton cas &
d'après ce que tu en dis, pour moi exit() s'en chargera =)
Le 28-05-2010, xtof.pernod a écrit :Le 27/05/2010 14:11, Marc Boyer a fait rien qu'à écrire :(...)
D'avoir enseigné à divers public (mais tous en formation initiale)
m'a permis d'expériementer sur les autres ;-) de ne pas m'en remettre
qu'à mes souvenirs personels.
(...)Oui, si tu veux, mais je suis tenté de dire que si la /Bonne Voie/(c)(tm)
existait, alors on s'y engouffrerait tous, débutants comme pro's,
et tout serait bonheur de joie.
Sauf que le "bonne voie", elle est relative à une population de départ,
un objectif, et des moyens.
On ne fait pas la même chose avec des matheux en M1 qui découvrent
un clavier, des bacheliers qui entre en IUT Info Indus et un comptable
autodidacte seul devant son clavier. Et dans ces trois situations, on
ne fait pas non plus la même chose en 1980, en 1995 et en 2010.
Bon, comment tu traces les 2 courbes: 'productivité' et 'effort
apprentissage' ? En x, on peut mettre le temps, je suppose ; et en y ?
Non, en y, productivité, en x, l'effort d'apprentissage.
En gros, avec une IHM souris (clickodrome), tu as une courbe qui ressemble
à un logarithme: avec très peu d'effort, tu fais déjà des trus, mais ça plafonne
vite.
Avec vi, tu as un truc du genre y = x + b, avec b assez gros.
[plusieurs pb.] L'algorithmique, les E/S, la gestion mémoire.
En 2010, on devrait pouvoir entrer un ÿ dans une chaine sans se soucier
des conversions char / unsigned char / int qui font que ton code s'arrête.
Un language ou tu peux faire x = y, puis avoir le test x == y qui renvoie
faux, c'est piégeant...Et puis bon, en 2010, devoir se taper la gestion de la mémoire à
la main, n'est-ce pas un pb qu'on peut éviter dans 95% des cas ?
Euh. Qu'est-ce que tu entends, précisément, par 'à la main': au malloc(3) ?..
Parce que dans ce cas, en 2010 comme chaque année depuis 70 (au moins),
la mémoire se gère à la main, dans 95 ? 99 ? 100-O(1) % ? des cas,
le C n'ayant pas de mécanisme de ramassage des poubelles..
J'ai longtemps cru que C n'avait pas de gestion automatisée de la mémoire.
J'ai apris depuis qu'il existait des env de dev qui le font.
Et puis justement, je pensais à des langages plus évolués qui te permettent
d'écrire
String s = "toto";
s= s + " va à la mer";
sans avoir à te soucier de la gestion mémoire.
Du reste, c'est complètement dépendant de ce que tu implémentes.
Tout à fait. Le sujet de base, c'était "apprendre à programmer".
Si ça deviens "apprendre à programmer un système de plugin pour routeur
Cisco", on a plus les mêmes outils...
Marc Boyer
Le 28-05-2010, xtof.pernod<xtof.pernod@NOSPAM.free.fr> a écrit :
Le 27/05/2010 14:11, Marc Boyer a fait rien qu'à écrire :
(...)
D'avoir enseigné à divers public (mais tous en formation initiale)
m'a permis d'expériementer sur les autres ;-) de ne pas m'en remettre
qu'à mes souvenirs personels.
(...)
Oui, si tu veux, mais je suis tenté de dire que si la /Bonne Voie/(c)(tm)
existait, alors on s'y engouffrerait tous, débutants comme pro's,
et tout serait bonheur de joie.
Sauf que le "bonne voie", elle est relative à une population de départ,
un objectif, et des moyens.
On ne fait pas la même chose avec des matheux en M1 qui découvrent
un clavier, des bacheliers qui entre en IUT Info Indus et un comptable
autodidacte seul devant son clavier. Et dans ces trois situations, on
ne fait pas non plus la même chose en 1980, en 1995 et en 2010.
Bon, comment tu traces les 2 courbes: 'productivité' et 'effort
apprentissage' ? En x, on peut mettre le temps, je suppose ; et en y ?
Non, en y, productivité, en x, l'effort d'apprentissage.
En gros, avec une IHM souris (clickodrome), tu as une courbe qui ressemble
à un logarithme: avec très peu d'effort, tu fais déjà des trus, mais ça plafonne
vite.
Avec vi, tu as un truc du genre y = x + b, avec b assez gros.
[plusieurs pb.] L'algorithmique, les E/S, la gestion mémoire.
En 2010, on devrait pouvoir entrer un ÿ dans une chaine sans se soucier
des conversions char / unsigned char / int qui font que ton code s'arrête.
Un language ou tu peux faire x = y, puis avoir le test x == y qui renvoie
faux, c'est piégeant...
Et puis bon, en 2010, devoir se taper la gestion de la mémoire à
la main, n'est-ce pas un pb qu'on peut éviter dans 95% des cas ?
Euh. Qu'est-ce que tu entends, précisément, par 'à la main': au malloc(3) ?..
Parce que dans ce cas, en 2010 comme chaque année depuis 70 (au moins),
la mémoire se gère à la main, dans 95 ? 99 ? 100-O(1) % ? des cas,
le C n'ayant pas de mécanisme de ramassage des poubelles..
J'ai longtemps cru que C n'avait pas de gestion automatisée de la mémoire.
J'ai apris depuis qu'il existait des env de dev qui le font.
Et puis justement, je pensais à des langages plus évolués qui te permettent
d'écrire
String s = "toto";
s= s + " va à la mer";
sans avoir à te soucier de la gestion mémoire.
Du reste, c'est complètement dépendant de ce que tu implémentes.
Tout à fait. Le sujet de base, c'était "apprendre à programmer".
Si ça deviens "apprendre à programmer un système de plugin pour routeur
Cisco", on a plus les mêmes outils...
Marc Boyer
Le 28-05-2010, xtof.pernod a écrit :Le 27/05/2010 14:11, Marc Boyer a fait rien qu'à écrire :(...)
D'avoir enseigné à divers public (mais tous en formation initiale)
m'a permis d'expériementer sur les autres ;-) de ne pas m'en remettre
qu'à mes souvenirs personels.
(...)Oui, si tu veux, mais je suis tenté de dire que si la /Bonne Voie/(c)(tm)
existait, alors on s'y engouffrerait tous, débutants comme pro's,
et tout serait bonheur de joie.
Sauf que le "bonne voie", elle est relative à une population de départ,
un objectif, et des moyens.
On ne fait pas la même chose avec des matheux en M1 qui découvrent
un clavier, des bacheliers qui entre en IUT Info Indus et un comptable
autodidacte seul devant son clavier. Et dans ces trois situations, on
ne fait pas non plus la même chose en 1980, en 1995 et en 2010.
Bon, comment tu traces les 2 courbes: 'productivité' et 'effort
apprentissage' ? En x, on peut mettre le temps, je suppose ; et en y ?
Non, en y, productivité, en x, l'effort d'apprentissage.
En gros, avec une IHM souris (clickodrome), tu as une courbe qui ressemble
à un logarithme: avec très peu d'effort, tu fais déjà des trus, mais ça plafonne
vite.
Avec vi, tu as un truc du genre y = x + b, avec b assez gros.
[plusieurs pb.] L'algorithmique, les E/S, la gestion mémoire.
En 2010, on devrait pouvoir entrer un ÿ dans une chaine sans se soucier
des conversions char / unsigned char / int qui font que ton code s'arrête.
Un language ou tu peux faire x = y, puis avoir le test x == y qui renvoie
faux, c'est piégeant...Et puis bon, en 2010, devoir se taper la gestion de la mémoire à
la main, n'est-ce pas un pb qu'on peut éviter dans 95% des cas ?
Euh. Qu'est-ce que tu entends, précisément, par 'à la main': au malloc(3) ?..
Parce que dans ce cas, en 2010 comme chaque année depuis 70 (au moins),
la mémoire se gère à la main, dans 95 ? 99 ? 100-O(1) % ? des cas,
le C n'ayant pas de mécanisme de ramassage des poubelles..
J'ai longtemps cru que C n'avait pas de gestion automatisée de la mémoire.
J'ai apris depuis qu'il existait des env de dev qui le font.
Et puis justement, je pensais à des langages plus évolués qui te permettent
d'écrire
String s = "toto";
s= s + " va à la mer";
sans avoir à te soucier de la gestion mémoire.
Du reste, c'est complètement dépendant de ce que tu implémentes.
Tout à fait. Le sujet de base, c'était "apprendre à programmer".
Si ça deviens "apprendre à programmer un système de plugin pour routeur
Cisco", on a plus les mêmes outils...
Marc Boyer
En même temps, le besoin d'informaticien est un besoin de masse. Il y a
2-3 ans, je me souviens d'une présentation d'un resp. de l'association
des indutriels informatique français, qui disait (je n'ai plus le chiffre
exact en tête) qu'entre les recrutements et l'ensemble des diplomés
"informatique", il y avait un manque de 20%.
De mon côté utilisateur, je trouve que les ordis plantent moins
de nos jours qu'il y a disons 15 ans. A l'époque, on pouvait pas
accuser Java.
En même temps, le besoin d'informaticien est un besoin de masse. Il y a
2-3 ans, je me souviens d'une présentation d'un resp. de l'association
des indutriels informatique français, qui disait (je n'ai plus le chiffre
exact en tête) qu'entre les recrutements et l'ensemble des diplomés
"informatique", il y avait un manque de 20%.
De mon côté utilisateur, je trouve que les ordis plantent moins
de nos jours qu'il y a disons 15 ans. A l'époque, on pouvait pas
accuser Java.
En même temps, le besoin d'informaticien est un besoin de masse. Il y a
2-3 ans, je me souviens d'une présentation d'un resp. de l'association
des indutriels informatique français, qui disait (je n'ai plus le chiffre
exact en tête) qu'entre les recrutements et l'ensemble des diplomés
"informatique", il y avait un manque de 20%.
De mon côté utilisateur, je trouve que les ordis plantent moins
de nos jours qu'il y a disons 15 ans. A l'époque, on pouvait pas
accuser Java.