C'est incroyable, la Fac d'orleans vient de passer au LMD et ils ont viré
le C des programmes.
Ils ont conservé le Caml pour les 2eme années
Et ont remplacé Pascal (1ere année) et C (2eme année) par je Java sur
les deux années.
En troisieme on aura directement droit au C++.
Je trouve ca injuste. Et dire que j'etais vraiment content de faire du C,
d'autant plus que je tourne uniquement sous Linux et que sous Linux le C
est tres abondant ... je devrais donc apprendre le C a coté : une masse
de travail supplémentaire ... Quel desastre ... vous voyez un bon coté
des choses dans cette histoire, moi je suis un tantinet deprimé la ...
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
| | > Un octet c'est 8 bits. | | > [snip]. Au fait la traduction AFNOR de byte est multiplet. En | > pratique il existe ou a existe des machines/systemes avec des bytes | > de 6,7,8,9,16 et 32 bits. | | Et 4 bits aussi, sur les calculatrices HP48 par exemple (et il existe | un compilateur C, hp48cc). Sinon, je suis totalement d'accord, il faut | faire attention avec "byte" et "octet", la taille d'un "byte" varie. | | Par contre, la norme du C dit que "char" doit faire au moins | 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char" | faiut plusiuers "byte"...
Non.
-- Gaby
kilobug@freesurf.fr (Gaël Le Mignot) writes:
|
| > Un octet c'est 8 bits.
|
| > [snip]. Au fait la traduction AFNOR de byte est multiplet. En
| > pratique il existe ou a existe des machines/systemes avec des bytes
| > de 6,7,8,9,16 et 32 bits.
|
| Et 4 bits aussi, sur les calculatrices HP48 par exemple (et il existe
| un compilateur C, hp48cc). Sinon, je suis totalement d'accord, il faut
| faire attention avec "byte" et "octet", la taille d'un "byte" varie.
|
| Par contre, la norme du C dit que "char" doit faire au moins
| 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char"
| faiut plusiuers "byte"...
| | > Un octet c'est 8 bits. | | > [snip]. Au fait la traduction AFNOR de byte est multiplet. En | > pratique il existe ou a existe des machines/systemes avec des bytes | > de 6,7,8,9,16 et 32 bits. | | Et 4 bits aussi, sur les calculatrices HP48 par exemple (et il existe | un compilateur C, hp48cc). Sinon, je suis totalement d'accord, il faut | faire attention avec "byte" et "octet", la taille d'un "byte" varie. | | Par contre, la norme du C dit que "char" doit faire au moins | 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char" | faiut plusiuers "byte"...
Non.
-- Gaby
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| (Gaël Le Mignot) writes: | | > | > > Un octet c'est 8 bits. | > | > > [snip]. Au fait la traduction AFNOR de byte est multiplet. En | > > pratique il existe ou a existe des machines/systemes avec des | > > bytes de 6,7,8,9,16 et 32 bits. | > | > Et 4 bits aussi, sur les calculatrices HP48 par exemple (et il | > existe un compilateur C, hp48cc). Sinon, je suis totalement | > d'accord, il faut faire attention avec "byte" et "octet", la taille | > d'un "byte" varie. | | La on tombe sur un cas ou les deux definitions de bytes sont | conflictuelles (si j'ai bonne memoire le jeu de caractere de l'HP48 | est une extension proprietaire de l'ASCII, dont a 8 bits). | | > Par contre, la norme du C dit que "char" doit faire au moins | > 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char" | > faiut plusiuers "byte"... | | J'avais voulu l'ecrire mais l'ai oublie. Merci de l'avoir signale.
Le C dit que 1 char fait exactement 1 byte.
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| kilobug@freesurf.fr (Gaël Le Mignot) writes:
|
| >
| > > Un octet c'est 8 bits.
| >
| > > [snip]. Au fait la traduction AFNOR de byte est multiplet. En
| > > pratique il existe ou a existe des machines/systemes avec des
| > > bytes de 6,7,8,9,16 et 32 bits.
| >
| > Et 4 bits aussi, sur les calculatrices HP48 par exemple (et il
| > existe un compilateur C, hp48cc). Sinon, je suis totalement
| > d'accord, il faut faire attention avec "byte" et "octet", la taille
| > d'un "byte" varie.
|
| La on tombe sur un cas ou les deux definitions de bytes sont
| conflictuelles (si j'ai bonne memoire le jeu de caractere de l'HP48
| est une extension proprietaire de l'ASCII, dont a 8 bits).
|
| > Par contre, la norme du C dit que "char" doit faire au moins
| > 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char"
| > faiut plusiuers "byte"...
|
| J'avais voulu l'ecrire mais l'ai oublie. Merci de l'avoir signale.
| (Gaël Le Mignot) writes: | | > | > > Un octet c'est 8 bits. | > | > > [snip]. Au fait la traduction AFNOR de byte est multiplet. En | > > pratique il existe ou a existe des machines/systemes avec des | > > bytes de 6,7,8,9,16 et 32 bits. | > | > Et 4 bits aussi, sur les calculatrices HP48 par exemple (et il | > existe un compilateur C, hp48cc). Sinon, je suis totalement | > d'accord, il faut faire attention avec "byte" et "octet", la taille | > d'un "byte" varie. | | La on tombe sur un cas ou les deux definitions de bytes sont | conflictuelles (si j'ai bonne memoire le jeu de caractere de l'HP48 | est une extension proprietaire de l'ASCII, dont a 8 bits). | | > Par contre, la norme du C dit que "char" doit faire au moins | > 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char" | > faiut plusiuers "byte"... | | J'avais voulu l'ecrire mais l'ai oublie. Merci de l'avoir signale.
Le C dit que 1 char fait exactement 1 byte.
-- Gaby
Gabriel Dos Reis
"Charlie Gordon" writes:
| "Jean-Marc Bourguet" wrote in message | news: | > "Charlie Gordon" writes: | > | > > "Vincent Lefevre" <vincent+ wrote in message | > > news:20040929134001$ | > > > | > > > Je conseillerais plutôt la VO, car dans la VF, il y a des erreurs de | > > > traduction gênantes (genre byte -> octet). | > > > | > > En quoi est-ce une erreur ? | > | > Un octet c'est 8 bits. | > | > Un byte isole n'a pas de sens, c'est comme "mot" une unite dont la | > taille est determinee par une architecture ou un systeme. Plus encore | > que pour un "mot" la definition est imprecise (un mot correspond a ce | > qui est stockable dans les registres d'usage general). Un byte est | > generalement le groupe de bits le plus petit manipulable aisement. | > C'est alternativement la taille du jeux de caractere employe -- les | > deux correspondent souvent mais certaines architectures peuvent | > manipuler des bytes de n'importe quelle taille. Au fait la traduction | > AFNOR de byte est multiplet. En pratique il existe ou a existe des | > machines/systemes avec des bytes de 6,7,8,9,16 et 32 bits. | | C'est de l'intégrisme contre-productif !
Bah non.
[...]
| donc évitons de rajouter de la complexité inutilement.
Donc, évitons de créer de la confusion gratuite en soutenant que byte veut dire octet.
[...]
| Chqrlie. | | PS: multiplet est utilisé depuis longtemps en physique atomique. La | recommandation comme traduction de byte date de 2001, et l'usage est encore | rarissime, alors critiquer K&R qui remonte à 1978...
K+R est écrit en Anglais.
Ce qui est mis en cause ici n'est pas la version originale, mais une traduction peu désirable.
-- Gaby
"Charlie Gordon" <news@chqrlie.org> writes:
| "Jean-Marc Bourguet" <jm@bourguet.org> wrote in message
| news:pxb8yas9prv.fsf@news.bourguet.org...
| > "Charlie Gordon" <news@chqrlie.org> writes:
| >
| > > "Vincent Lefevre" <vincent+news@vinc17.org> wrote in message
| > > news:20040929134001$5890@vinc17.org...
| > > >
| > > > Je conseillerais plutôt la VO, car dans la VF, il y a des erreurs de
| > > > traduction gênantes (genre byte -> octet).
| > > >
| > > En quoi est-ce une erreur ?
| >
| > Un octet c'est 8 bits.
| >
| > Un byte isole n'a pas de sens, c'est comme "mot" une unite dont la
| > taille est determinee par une architecture ou un systeme. Plus encore
| > que pour un "mot" la definition est imprecise (un mot correspond a ce
| > qui est stockable dans les registres d'usage general). Un byte est
| > generalement le groupe de bits le plus petit manipulable aisement.
| > C'est alternativement la taille du jeux de caractere employe -- les
| > deux correspondent souvent mais certaines architectures peuvent
| > manipuler des bytes de n'importe quelle taille. Au fait la traduction
| > AFNOR de byte est multiplet. En pratique il existe ou a existe des
| > machines/systemes avec des bytes de 6,7,8,9,16 et 32 bits.
|
| C'est de l'intégrisme contre-productif !
Bah non.
[...]
| donc évitons de rajouter de la complexité inutilement.
Donc, évitons de créer de la confusion gratuite en soutenant que byte
veut dire octet.
[...]
| Chqrlie.
|
| PS: multiplet est utilisé depuis longtemps en physique atomique. La
| recommandation comme traduction de byte date de 2001, et l'usage est encore
| rarissime, alors critiquer K&R qui remonte à 1978...
K+R est écrit en Anglais.
Ce qui est mis en cause ici n'est pas la version originale, mais une
traduction peu désirable.
| "Jean-Marc Bourguet" wrote in message | news: | > "Charlie Gordon" writes: | > | > > "Vincent Lefevre" <vincent+ wrote in message | > > news:20040929134001$ | > > > | > > > Je conseillerais plutôt la VO, car dans la VF, il y a des erreurs de | > > > traduction gênantes (genre byte -> octet). | > > > | > > En quoi est-ce une erreur ? | > | > Un octet c'est 8 bits. | > | > Un byte isole n'a pas de sens, c'est comme "mot" une unite dont la | > taille est determinee par une architecture ou un systeme. Plus encore | > que pour un "mot" la definition est imprecise (un mot correspond a ce | > qui est stockable dans les registres d'usage general). Un byte est | > generalement le groupe de bits le plus petit manipulable aisement. | > C'est alternativement la taille du jeux de caractere employe -- les | > deux correspondent souvent mais certaines architectures peuvent | > manipuler des bytes de n'importe quelle taille. Au fait la traduction | > AFNOR de byte est multiplet. En pratique il existe ou a existe des | > machines/systemes avec des bytes de 6,7,8,9,16 et 32 bits. | | C'est de l'intégrisme contre-productif !
Bah non.
[...]
| donc évitons de rajouter de la complexité inutilement.
Donc, évitons de créer de la confusion gratuite en soutenant que byte veut dire octet.
[...]
| Chqrlie. | | PS: multiplet est utilisé depuis longtemps en physique atomique. La | recommandation comme traduction de byte date de 2001, et l'usage est encore | rarissime, alors critiquer K&R qui remonte à 1978...
K+R est écrit en Anglais.
Ce qui est mis en cause ici n'est pas la version originale, mais une traduction peu désirable.
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| Misterjack wrote: | >>>> Prendre des débutants complets et commencer avec le C ? | >>>>Bonne chance. | >>> | >>>C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain | >> | >> Le fait que certains en réchappent ne signifie pas que ce soit une | >> bonne méthode pédagogique. | > | > L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne | > pas travailler "en aveugle". | | scanf("%d",&i); | scanf("%s", prenom); | | C'est clair qu'une fois qu'on a compris tout ce que font ces | lignes, on a compris beaucoup de choses.
Vraiment ?
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Misterjack wrote:
| >>>> Prendre des débutants complets et commencer avec le C ?
| >>>>Bonne chance.
| >>>
| >>>C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain
| >>
| >> Le fait que certains en réchappent ne signifie pas que ce soit une
| >> bonne méthode pédagogique.
| >
| > L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne
| > pas travailler "en aveugle".
|
| scanf("%d",&i);
| scanf("%s", prenom);
|
| C'est clair qu'une fois qu'on a compris tout ce que font ces
| lignes, on a compris beaucoup de choses.
| Misterjack wrote: | >>>> Prendre des débutants complets et commencer avec le C ? | >>>>Bonne chance. | >>> | >>>C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain | >> | >> Le fait que certains en réchappent ne signifie pas que ce soit une | >> bonne méthode pédagogique. | > | > L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne | > pas travailler "en aveugle". | | scanf("%d",&i); | scanf("%s", prenom); | | C'est clair qu'une fois qu'on a compris tout ce que font ces | lignes, on a compris beaucoup de choses.
Vraiment ?
-- Gaby
Stephane Zuckerman
Bonjour,
On Wed, 29 Sep 2004, Johann Dantant wrote:
Prendre des débutants complets et commencer avec le C ? Bonne chance.
Je suis d'accord (même si c'est ce qui m'est arrivé en IUT). Ou plutôt, tout dépend de la façon dont on l'enseigne. Nous avions commencé par faire de l'algorithmique, puis des applications en C en même temps. En fin d'année nous avons abordés deux langages très différents (VB et C++), afin d'aborder la programmation événementielle d'une part (Visual Basic), et la programmation orientée objet d'autre part. Ceci après "seulement" six mois de C.
En fin de compte, ce qui a été déterminant, c'était la pédagogie. Les enseignants étaient excellents, et ont artificiellement caché les difficultés du C au départ pour nous permettre de nous concentrer sur l'algorithmique .
Par ex :
/* création d'un type pour une chaîne de 19 caractères */ typedef char CH20;
Bref, les pointeurs, nous les avons vu au bout du deuxième ou troisième mois de formation. Avant, des artifices (du même ordre que ceux utilisés par Java par exemple, en plus limitants) nous permettaient de faire notre boulot, sans vraiment comprendre pourquoi taper "CH20 machaine" me forçait à 19 caractères uniquement.
Par contre, nous avions des cours d'architecture (en gros de l'électronique numérique, des cours de logique formelle, de la prog de micro-code, etc.) en parallèle. Au bout de trois mois, nous en savions assez sur les machines pour pouvoir utiliser les pointeurs sans trop de bourdes.
Maintenant, tu as certainement raison de considérer que c'est une mauvaise méthode pédagogique, mais personnellement je préfères une mauvaise méthode pédagogique qui forme des gens compétents et efficaces qu'une bonne méthode pédagogique qui m'amène des brouettes de débutants inemployables en l'état.
Si l'enseignement est pédagogiquement bon, les gens sauront se débrouiller plus tard. Un ami ingénieur (et codant uniquement en Java) a fait un peu de C et de C++ dans son école, et beaucoup de Java, mais ça ne l'empêche pas d'être totalement au courant de la façon dont fonctionne un ordinateur. Et il n'a pas fait 2 ans de C (il a à peine fait 20h de C++).
Il suffit de repenser à la méthode actuelle d'apprentissage de la lecture qui donne de si bon résultats dans les écoles primaires. Une amie qui se destine à être institutrice (enfin, ex-amie, forcément on est fâché maintenant...) me soutient que c'est une bonne méthode pédagogique. D'accord. Mais une autre amie prof en 6ème me confirme que c'est une mauvaise méthode d'apprentissage, puisqu'ils sont nuls en arrivant... Alors ?
Là, il y a une différence notable : la méthode a été mise en oeuvre il y a une dizaine d'année, et ce n'est que maintenant qu'on peut en voir les résultats. Ton (ex-) amie a simplement refusé de se remettre en question sur la validité de la méthode qu'on lui a apprise. Je connais beaucoup d'ingénieurs et de techniciens en informatique qui font de même (pour les langages, les systèmes à utiliser, et parfois même la façon de coder...)
Quand à la beauté, je ne trouve pas ça un argument: on forme des développeurs, pas des artistes.
Non non, franchement, sincèrement, il ne faut surtout pas dire ça... J'ai aussi assuré (oh, pas longtemps, j'en ai eu vite marre) quelques cours en école d'ingénieur. Une fois passé de l'autre côté de la barrière, j'ai pu confronter (un peu) mes points de vue avec mes anciens professeurs, et effectivement eux comme toi ne voient que les arguments techniques et pédagogiques. C'est à mon sens une erreur fatale. Un développeur c'est avant tout un créateur, au même titre qu'un designer de voiture ou un modiste.
Mmmmh. Non. D'abord ça marche, ensuite on fignole. Si en plus on peut faire ça "bien" (à définir, parce que bon, pour ne donner que l'exemple des GNU coding standards, même si l'intention est louable, je déteste leur façon de présenter le code). Evidemment, j'aurais tendance à attendre d'un ingénieur de bien savoir présenter son code, parce qu'il est payé pour être "meilleur" et mieux formé qu'un "simple" technicient (et ce n'est pas forcément vérifié dans la pratique, loin de là).
Stéphane.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Bonjour,
On Wed, 29 Sep 2004, Johann Dantant wrote:
Prendre des débutants complets et commencer avec le C ?
Bonne chance.
Je suis d'accord (même si c'est ce qui m'est arrivé en IUT). Ou
plutôt, tout dépend de la façon dont on l'enseigne. Nous avions commencé
par faire de l'algorithmique, puis des applications en C en même temps. En
fin d'année nous avons abordés deux langages très différents (VB et C++),
afin d'aborder la programmation événementielle d'une part (Visual Basic),
et la programmation orientée objet d'autre part. Ceci après "seulement"
six mois de C.
En fin de compte, ce qui a été déterminant, c'était la pédagogie.
Les enseignants étaient excellents, et ont artificiellement caché les
difficultés du C au départ pour nous permettre de nous concentrer sur
l'algorithmique .
Par ex :
/* création d'un type pour une chaîne de 19 caractères */
typedef char CH20;
Bref, les pointeurs, nous les avons vu au bout du deuxième ou
troisième mois de formation. Avant, des artifices (du même ordre que ceux
utilisés par Java par exemple, en plus limitants) nous permettaient de
faire notre boulot, sans vraiment comprendre pourquoi taper "CH20
machaine" me forçait à 19 caractères uniquement.
Par contre, nous avions des cours d'architecture (en gros de
l'électronique numérique, des cours de logique formelle, de la prog de
micro-code, etc.) en parallèle. Au bout de trois mois, nous en savions
assez sur les machines pour pouvoir utiliser les pointeurs sans trop de
bourdes.
Maintenant, tu as certainement raison de considérer que c'est une mauvaise
méthode pédagogique, mais personnellement je préfères une mauvaise méthode
pédagogique qui forme des gens compétents et efficaces qu'une bonne méthode
pédagogique qui m'amène des brouettes de débutants inemployables en l'état.
Si l'enseignement est pédagogiquement bon, les gens sauront se débrouiller
plus tard. Un ami ingénieur (et codant uniquement en Java) a fait un peu
de C et de C++ dans son école, et beaucoup de Java, mais ça ne l'empêche
pas d'être totalement au courant de la façon dont fonctionne un
ordinateur. Et il n'a pas fait 2 ans de C (il a à peine fait 20h de C++).
Il suffit de repenser à la méthode actuelle d'apprentissage de la lecture
qui donne de si bon résultats dans les écoles primaires. Une amie qui se
destine à être institutrice (enfin, ex-amie, forcément on est fâché
maintenant...) me soutient que c'est une bonne méthode pédagogique.
D'accord. Mais une autre amie prof en 6ème me confirme que c'est une
mauvaise méthode d'apprentissage, puisqu'ils sont nuls en arrivant... Alors
?
Là, il y a une différence notable : la méthode a été mise en oeuvre il y a
une dizaine d'année, et ce n'est que maintenant qu'on peut en voir les
résultats. Ton (ex-) amie a simplement refusé de se remettre en question
sur la validité de la méthode qu'on lui a apprise. Je connais beaucoup
d'ingénieurs et de techniciens en informatique qui font de même (pour les
langages, les systèmes à utiliser, et parfois même la façon de coder...)
Quand à la beauté, je ne trouve pas ça un argument: on forme
des développeurs, pas des artistes.
Non non, franchement, sincèrement, il ne faut surtout pas dire ça... J'ai
aussi assuré (oh, pas longtemps, j'en ai eu vite marre) quelques cours en
école d'ingénieur. Une fois passé de l'autre côté de la barrière, j'ai pu
confronter (un peu) mes points de vue avec mes anciens professeurs, et
effectivement eux comme toi ne voient que les arguments techniques et
pédagogiques. C'est à mon sens une erreur fatale. Un développeur c'est avant
tout un créateur, au même titre qu'un designer de voiture ou un modiste.
Mmmmh. Non. D'abord ça marche, ensuite on fignole. Si en plus on peut
faire ça "bien" (à définir, parce que bon, pour ne donner que l'exemple
des GNU coding standards, même si l'intention est louable, je déteste leur
façon de présenter le code). Evidemment, j'aurais tendance à attendre d'un
ingénieur de bien savoir présenter son code, parce qu'il est payé pour
être "meilleur" et mieux formé qu'un "simple" technicient (et ce n'est pas
forcément vérifié dans la pratique, loin de là).
Stéphane.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Prendre des débutants complets et commencer avec le C ? Bonne chance.
Je suis d'accord (même si c'est ce qui m'est arrivé en IUT). Ou plutôt, tout dépend de la façon dont on l'enseigne. Nous avions commencé par faire de l'algorithmique, puis des applications en C en même temps. En fin d'année nous avons abordés deux langages très différents (VB et C++), afin d'aborder la programmation événementielle d'une part (Visual Basic), et la programmation orientée objet d'autre part. Ceci après "seulement" six mois de C.
En fin de compte, ce qui a été déterminant, c'était la pédagogie. Les enseignants étaient excellents, et ont artificiellement caché les difficultés du C au départ pour nous permettre de nous concentrer sur l'algorithmique .
Par ex :
/* création d'un type pour une chaîne de 19 caractères */ typedef char CH20;
Bref, les pointeurs, nous les avons vu au bout du deuxième ou troisième mois de formation. Avant, des artifices (du même ordre que ceux utilisés par Java par exemple, en plus limitants) nous permettaient de faire notre boulot, sans vraiment comprendre pourquoi taper "CH20 machaine" me forçait à 19 caractères uniquement.
Par contre, nous avions des cours d'architecture (en gros de l'électronique numérique, des cours de logique formelle, de la prog de micro-code, etc.) en parallèle. Au bout de trois mois, nous en savions assez sur les machines pour pouvoir utiliser les pointeurs sans trop de bourdes.
Maintenant, tu as certainement raison de considérer que c'est une mauvaise méthode pédagogique, mais personnellement je préfères une mauvaise méthode pédagogique qui forme des gens compétents et efficaces qu'une bonne méthode pédagogique qui m'amène des brouettes de débutants inemployables en l'état.
Si l'enseignement est pédagogiquement bon, les gens sauront se débrouiller plus tard. Un ami ingénieur (et codant uniquement en Java) a fait un peu de C et de C++ dans son école, et beaucoup de Java, mais ça ne l'empêche pas d'être totalement au courant de la façon dont fonctionne un ordinateur. Et il n'a pas fait 2 ans de C (il a à peine fait 20h de C++).
Il suffit de repenser à la méthode actuelle d'apprentissage de la lecture qui donne de si bon résultats dans les écoles primaires. Une amie qui se destine à être institutrice (enfin, ex-amie, forcément on est fâché maintenant...) me soutient que c'est une bonne méthode pédagogique. D'accord. Mais une autre amie prof en 6ème me confirme que c'est une mauvaise méthode d'apprentissage, puisqu'ils sont nuls en arrivant... Alors ?
Là, il y a une différence notable : la méthode a été mise en oeuvre il y a une dizaine d'année, et ce n'est que maintenant qu'on peut en voir les résultats. Ton (ex-) amie a simplement refusé de se remettre en question sur la validité de la méthode qu'on lui a apprise. Je connais beaucoup d'ingénieurs et de techniciens en informatique qui font de même (pour les langages, les systèmes à utiliser, et parfois même la façon de coder...)
Quand à la beauté, je ne trouve pas ça un argument: on forme des développeurs, pas des artistes.
Non non, franchement, sincèrement, il ne faut surtout pas dire ça... J'ai aussi assuré (oh, pas longtemps, j'en ai eu vite marre) quelques cours en école d'ingénieur. Une fois passé de l'autre côté de la barrière, j'ai pu confronter (un peu) mes points de vue avec mes anciens professeurs, et effectivement eux comme toi ne voient que les arguments techniques et pédagogiques. C'est à mon sens une erreur fatale. Un développeur c'est avant tout un créateur, au même titre qu'un designer de voiture ou un modiste.
Mmmmh. Non. D'abord ça marche, ensuite on fignole. Si en plus on peut faire ça "bien" (à définir, parce que bon, pour ne donner que l'exemple des GNU coding standards, même si l'intention est louable, je déteste leur façon de présenter le code). Evidemment, j'aurais tendance à attendre d'un ingénieur de bien savoir présenter son code, parce qu'il est payé pour être "meilleur" et mieux formé qu'un "simple" technicient (et ce n'est pas forcément vérifié dans la pratique, loin de là).
Stéphane.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Marc Boyer
In article , Gabriel Dos Reis wrote:
Marc Boyer writes: | Misterjack wrote: | > L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne | > pas travailler "en aveugle". | | scanf("%d",&i); | scanf("%s", prenom); | | C'est clair qu'une fois qu'on a compris tout ce que font ces | lignes, on a compris beaucoup de choses.
Vraiment ?
Pour un débutant, oui, il me semble. Pas toi ?
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
In article <m3mzz7j3ai.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Misterjack wrote:
| > L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne
| > pas travailler "en aveugle".
|
| scanf("%d",&i);
| scanf("%s", prenom);
|
| C'est clair qu'une fois qu'on a compris tout ce que font ces
| lignes, on a compris beaucoup de choses.
Vraiment ?
Pour un débutant, oui, il me semble.
Pas toi ?
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Marc Boyer writes: | Misterjack wrote: | > L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne | > pas travailler "en aveugle". | | scanf("%d",&i); | scanf("%s", prenom); | | C'est clair qu'une fois qu'on a compris tout ce que font ces | lignes, on a compris beaucoup de choses.
Vraiment ?
Pour un débutant, oui, il me semble. Pas toi ?
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Gabriel Dos Reis
Marc Boyer writes:
| Johann Dantant wrote: | > "Marc Boyer" a écrit dans le message | > de news:cjdvnk$2ht$ | >> In article , Max M wrote: | >> >> Prendre des débutants complets et commencer avec le C ? | >> >>Bonne chance. | >> > | >> > C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain | >> | >> Le fait que certains en réchappent ne signifie pas que ce soit une | >> bonne méthode pédagogique. | > | > Le premier but d'une école devrait être d'enseigner un savoir faire. De mon | > expérience un savoir faire en programmation ça passe par une progression | > logique, depuis la machine vers le haut niveau, point barre. | | Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul | typé (équivalence de Church au passage si on a 2mn), puis le | reste n'est que mise en pratique ?
Le lambda-calcul est trop haut niveau. <G>
De plus, il utilise une convention d'appel (passage par nom) peu utilisé dans la pratique -- le C utilise passage par valeur.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Johann Dantant wrote:
| > "Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
| > de news:cjdvnk$2ht$1@news.cict.fr...
| >> In article <415A7DDC.8000705@yahoo.NoSpam.fr>, Max M wrote:
| >> >> Prendre des débutants complets et commencer avec le C ?
| >> >>Bonne chance.
| >> >
| >> > C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain
| >>
| >> Le fait que certains en réchappent ne signifie pas que ce soit une
| >> bonne méthode pédagogique.
| >
| > Le premier but d'une école devrait être d'enseigner un savoir faire. De mon
| > expérience un savoir faire en programmation ça passe par une progression
| > logique, depuis la machine vers le haut niveau, point barre.
|
| Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul
| typé (équivalence de Church au passage si on a 2mn), puis le
| reste n'est que mise en pratique ?
Le lambda-calcul est trop haut niveau. <G>
De plus, il utilise une convention d'appel (passage par nom) peu
utilisé dans la pratique -- le C utilise passage par valeur.
| Johann Dantant wrote: | > "Marc Boyer" a écrit dans le message | > de news:cjdvnk$2ht$ | >> In article , Max M wrote: | >> >> Prendre des débutants complets et commencer avec le C ? | >> >>Bonne chance. | >> > | >> > C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain | >> | >> Le fait que certains en réchappent ne signifie pas que ce soit une | >> bonne méthode pédagogique. | > | > Le premier but d'une école devrait être d'enseigner un savoir faire. De mon | > expérience un savoir faire en programmation ça passe par une progression | > logique, depuis la machine vers le haut niveau, point barre. | | Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul | typé (équivalence de Church au passage si on a 2mn), puis le | reste n'est que mise en pratique ?
Le lambda-calcul est trop haut niveau. <G>
De plus, il utilise une convention d'appel (passage par nom) peu utilisé dans la pratique -- le C utilise passage par valeur.
-- Gaby
Gabriel Dos Reis
Jean-Marc Bourguet writes:
[...]
| Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux | inferieurs (c'est malheureusement une tendance certaine parmis les | universitaires).
Yep, il faut d'abord commencer par la théorie des catégories :-)
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux
| inferieurs (c'est malheureusement une tendance certaine parmis les
| universitaires).
Yep, il faut d'abord commencer par la théorie des catégories :-)
| Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux | inferieurs (c'est malheureusement une tendance certaine parmis les | universitaires).
Yep, il faut d'abord commencer par la théorie des catégories :-)
-- Gaby
Gabriel Dos Reis
cedric writes:
| Jean-Marc Bourguet wrote: | > Mais l'assembleur ce n'est jamais qu'une abstraction aussi, (...) | > equations de Maxwell et la physique quantique (...) abstraction plus faible. | | Elle est bien bonne. | | Personne ici avant cela n'était entré dans la discussion de savoir | quel niveau d'abstraction rendait le mieux compte de "ce qui se passe | vraiment" ; la réponse étant bien évidente : aucun, par définition. | | La question qui était posé, c'est de choisir un langage d'enseignement | parmi les langages qui permettent de controler un | ordinateur. L'assembleur (doublé d'un rapide coup d'oeil sur le format | de codage des instructions par le CPU) est le plus bas niveau que l'on | puisse concevoir.
Bah non. C'était le point de Jeann-Marc.
-- Gaby
cedric <rixed@happyleptic.NOSPAM.org> writes:
| Jean-Marc Bourguet wrote:
| > Mais l'assembleur ce n'est jamais qu'une abstraction aussi, (...)
| > equations de Maxwell et la physique quantique (...) abstraction plus faible.
|
| Elle est bien bonne.
|
| Personne ici avant cela n'était entré dans la discussion de savoir
| quel niveau d'abstraction rendait le mieux compte de "ce qui se passe
| vraiment" ; la réponse étant bien évidente : aucun, par définition.
|
| La question qui était posé, c'est de choisir un langage d'enseignement
| parmi les langages qui permettent de controler un
| ordinateur. L'assembleur (doublé d'un rapide coup d'oeil sur le format
| de codage des instructions par le CPU) est le plus bas niveau que l'on
| puisse concevoir.
| Jean-Marc Bourguet wrote: | > Mais l'assembleur ce n'est jamais qu'une abstraction aussi, (...) | > equations de Maxwell et la physique quantique (...) abstraction plus faible. | | Elle est bien bonne. | | Personne ici avant cela n'était entré dans la discussion de savoir | quel niveau d'abstraction rendait le mieux compte de "ce qui se passe | vraiment" ; la réponse étant bien évidente : aucun, par définition. | | La question qui était posé, c'est de choisir un langage d'enseignement | parmi les langages qui permettent de controler un | ordinateur. L'assembleur (doublé d'un rapide coup d'oeil sur le format | de codage des instructions par le CPU) est le plus bas niveau que l'on | puisse concevoir.
Bah non. C'était le point de Jeann-Marc.
-- Gaby
Marc Boyer
Stephane Zuckerman wrote:
On Wed, 29 Sep 2004, Johann Dantant wrote: En fin de compte, ce qui a été déterminant, c'était la pédagogie. Les enseignants étaient excellents, et ont artificiellement caché les difficultés du C au départ pour nous permettre de nous concentrer sur l'algorithmique .
Par ex :
/* création d'un type pour une chaîne de 19 caractères */ typedef char CH20;
Bref, les pointeurs, nous les avons vu au bout du deuxième ou troisième mois de formation. Avant, des artifices (du même ordre que ceux utilisés par Java par exemple, en plus limitants) nous permettaient de faire notre boulot, sans vraiment comprendre pourquoi taper "CH20 machaine" me forçait à 19 caractères uniquement.
J'ai pensé un temps faire un sous-ensemble de C avec un include qui va bien pour utiliser C dès le début... J'ai trouvé le ratio investissement/gain pas du tout interressant. Tiens, comment lire un entier et une chaine de caractère de manière homogène ?
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman wrote:
On Wed, 29 Sep 2004, Johann Dantant wrote:
En fin de compte, ce qui a été déterminant, c'était la pédagogie.
Les enseignants étaient excellents, et ont artificiellement caché les
difficultés du C au départ pour nous permettre de nous concentrer sur
l'algorithmique .
Par ex :
/* création d'un type pour une chaîne de 19 caractères */
typedef char CH20;
Bref, les pointeurs, nous les avons vu au bout du deuxième ou
troisième mois de formation. Avant, des artifices (du même ordre que ceux
utilisés par Java par exemple, en plus limitants) nous permettaient de
faire notre boulot, sans vraiment comprendre pourquoi taper "CH20
machaine" me forçait à 19 caractères uniquement.
J'ai pensé un temps faire un sous-ensemble de C avec un include
qui va bien pour utiliser C dès le début... J'ai trouvé le ratio
investissement/gain pas du tout interressant.
Tiens, comment lire un entier et une chaine de caractère
de manière homogène ?
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
On Wed, 29 Sep 2004, Johann Dantant wrote: En fin de compte, ce qui a été déterminant, c'était la pédagogie. Les enseignants étaient excellents, et ont artificiellement caché les difficultés du C au départ pour nous permettre de nous concentrer sur l'algorithmique .
Par ex :
/* création d'un type pour une chaîne de 19 caractères */ typedef char CH20;
Bref, les pointeurs, nous les avons vu au bout du deuxième ou troisième mois de formation. Avant, des artifices (du même ordre que ceux utilisés par Java par exemple, en plus limitants) nous permettaient de faire notre boulot, sans vraiment comprendre pourquoi taper "CH20 machaine" me forçait à 19 caractères uniquement.
J'ai pensé un temps faire un sous-ensemble de C avec un include qui va bien pour utiliser C dès le début... J'ai trouvé le ratio investissement/gain pas du tout interressant. Tiens, comment lire un entier et une chaine de caractère de manière homogène ?
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
