... et ils ont viré le C

Charlie Gordon

30/09/2004 à 10:21

"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 !
Le mot byte est une altération de "bite" qui signifie bout, morceau,
bouchée, morsure, du verbe homographe "to bite" : mordre.
On a changé l'orthographe pour éviter la confusion avec bit.
L'usage en informatique pour désigner une quantité élémentaire de données
remonte à 1956 (Werner Buchholz, IBM), et représentait à l'origine un mot de
6 bits. Avant la fin de 1956, cette quantité était passée à 8 bits.
Le fait est qu'un byte de 8 bits est appelé octet en anglais aussi, en
particulier dans le jargon formel des organismes de normalisation.
Il existe effectivement des architectures informatiques où le mot
élémentaire a une taille étrange, voire délirante.
Par exemple, de nombreux processeurs RISC sont incapables d'adresser la
mémoire par octet. Or même sur ces architectures, le type C "char" est un
octet, et le compilateur génère du code pour en adresser plusieurs par mot.
Porter des programmes C sur des architectures où les bytes ne font pas 8
bits pose des problèmes bien souvent très difficiles à résoudre, en
particulier dès que des manipulations de bits sont faites.
Prétendre que le code C est portable dès lors qu'il respecte le standard C99
est une escroquerie.
L'objectif du C99 et des précédents dans ce domaine est de définir ce qu'une
implémentation conforme peut faire sur différentes architectures en gardant
au language sa proximité avec le matériel et son efficacité.

Le K&R s'adresse aux débutants, il les met en garde contre la variabilité de
l'implémentation des types de base, mais gardons en perspective que par les
temps qui courent, les débutants n'ont pratiquement aucune chance de le
faire sur une machine où le byte n'est pas un octet, donc évitons de
rajouter de la complexité inutilement. Le C est déjà bien assez subtil et
piégeux comme cela.
Exemple:

int fillbuffer(int fd, char buffer[4096])
{
return read(fd, buffer, sizeof(buffer));
}

pourquoi cette routine ne fait-elle pas son office ?

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... Je trouve quand même
plus grave la confusion généralisée entre les puissances de 1000 et de 1024
pour les quantités de mémoire vive et les capacités de disques durs !

"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 !
Le mot byte est une altération de "bite" qui signifie bout, morceau,
bouchée, morsure, du verbe homographe "to bite" : mordre.
On a changé l'orthographe pour éviter la confusion avec bit.
L'usage en informatique pour désigner une quantité élémentaire de données
remonte à 1956 (Werner Buchholz, IBM), et représentait à l'origine un mot de
6 bits. Avant la fin de 1956, cette quantité était passée à 8 bits.
Le fait est qu'un byte de 8 bits est appelé octet en anglais aussi, en
particulier dans le jargon formel des organismes de normalisation.
Il existe effectivement des architectures informatiques où le mot
élémentaire a une taille étrange, voire délirante.
Par exemple, de nombreux processeurs RISC sont incapables d'adresser la
mémoire par octet. Or même sur ces architectures, le type C "char" est un
octet, et le compilateur génère du code pour en adresser plusieurs par mot.
Porter des programmes C sur des architectures où les bytes ne font pas 8
bits pose des problèmes bien souvent très difficiles à résoudre, en
particulier dès que des manipulations de bits sont faites.
Prétendre que le code C est portable dès lors qu'il respecte le standard C99
est une escroquerie.
L'objectif du C99 et des précédents dans ce domaine est de définir ce qu'une
implémentation conforme peut faire sur différentes architectures en gardant
au language sa proximité avec le matériel et son efficacité.

Le K&R s'adresse aux débutants, il les met en garde contre la variabilité de
l'implémentation des types de base, mais gardons en perspective que par les
temps qui courent, les débutants n'ont pratiquement aucune chance de le
faire sur une machine où le byte n'est pas un octet, donc évitons de
rajouter de la complexité inutilement. Le C est déjà bien assez subtil et
piégeux comme cela.
Exemple:

int fillbuffer(int fd, char buffer[4096])
{
return read(fd, buffer, sizeof(buffer));
}

pourquoi cette routine ne fait-elle pas son office ?

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... Je trouve quand même
plus grave la confusion généralisée entre les puissances de 1000 et de 1024
pour les quantités de mémoire vive et les capacités de disques durs !

Vous avez filtré cet utilisateur ! Consultez son message

"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 !
Le mot byte est une altération de "bite" qui signifie bout, morceau,
bouchée, morsure, du verbe homographe "to bite" : mordre.
On a changé l'orthographe pour éviter la confusion avec bit.
L'usage en informatique pour désigner une quantité élémentaire de données
remonte à 1956 (Werner Buchholz, IBM), et représentait à l'origine un mot de
6 bits. Avant la fin de 1956, cette quantité était passée à 8 bits.
Le fait est qu'un byte de 8 bits est appelé octet en anglais aussi, en
particulier dans le jargon formel des organismes de normalisation.
Il existe effectivement des architectures informatiques où le mot
élémentaire a une taille étrange, voire délirante.
Par exemple, de nombreux processeurs RISC sont incapables d'adresser la
mémoire par octet. Or même sur ces architectures, le type C "char" est un
octet, et le compilateur génère du code pour en adresser plusieurs par mot.
Porter des programmes C sur des architectures où les bytes ne font pas 8
bits pose des problèmes bien souvent très difficiles à résoudre, en
particulier dès que des manipulations de bits sont faites.
Prétendre que le code C est portable dès lors qu'il respecte le standard C99
est une escroquerie.
L'objectif du C99 et des précédents dans ce domaine est de définir ce qu'une
implémentation conforme peut faire sur différentes architectures en gardant
au language sa proximité avec le matériel et son efficacité.

Le K&R s'adresse aux débutants, il les met en garde contre la variabilité de
l'implémentation des types de base, mais gardons en perspective que par les
temps qui courent, les débutants n'ont pratiquement aucune chance de le
faire sur une machine où le byte n'est pas un octet, donc évitons de
rajouter de la complexité inutilement. Le C est déjà bien assez subtil et
piégeux comme cela.
Exemple:

int fillbuffer(int fd, char buffer[4096])
{
return read(fd, buffer, sizeof(buffer));
}

pourquoi cette routine ne fait-elle pas son office ?

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... Je trouve quand même
plus grave la confusion généralisée entre les puissances de 1000 et de 1024
pour les quantités de mémoire vive et les capacités de disques durs !

Marc Boyer

30/09/2004 à 10:25

Johann Dantant wrote:

"Marc Boyer" a écrit dans le message
de news:cjemh6$7gs$
Johann Dantant wrote:
(...)

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 ?

Pourquoi verser immédiatement dans la caricature ?

Pour montrer que l'argument "bottom-up" n'est pas
suffisant.

Sérieusement, quand on
voit débarquer des stagiaires qui n'ont aucune, mais absolument aucune idée
de ce que le nombre de bits du type int a comme impact sur leur code, on
croit rêver ! Quand après 3 ans de formation Java il faut leur expliquer
pourquoi la valeur 0x1234 qu'ils envoient au gars en face est interprétée
par lui comme étant 0x3412, on ne rêve plus, on pleure... Par contre, on
leur a bien appris à mettre 1234 en UTF-8 dans un fichier XML, c'est vrai...

J'ai milité contre l'enseignement du C et de l'architecture ?
Je pense que le C comme premier langage est une erreur, c'est
un peu différent.

Parmi tous les
collègues et stagiaires que j'ai eu et que j'ai encore, seuls ceux qui
ont

suivi cette logique ont de réelles compétences utilisables pour faire
autre

chose que des camemberts ou des histogrammes.

Sérieux ? T'es sur qu'ils ont tous commencé la prog par l'ASM ?

Pas forcément l'assembleur. Mais au minimum par de bonnes notions d'algèbre
booléenne, par des notions fondamentales d'architecture, par des TPs de
maths ou de physique bien ciblés (récursivité, calculs matriciels, tri...).

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Le langage importe peu, personnellement j'ai commencé par le Pascal puis le
C puis enfin l'assembleur, mais cela ne me semble vraiment pas
déterminant...

Dans notre formation, c'est Pascal puis C et ASM en //.

Le point important à mon avis est que l'étudiant touche du
doigt se qui se passe physiquement dans la machine quand il écrit telle
ligne de code plutôt que telle autre.

Oui.

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.
Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses connaissances
sont réduites, à un gars qui a survolé tous les domaines dans sa formation
mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et un juste milieu ?

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux qui
réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

C'est certain que ça peut
prendre du temps, ce n'est peut-être pas accessible à tout le monde, mais ce
n'est pas en allant au plus vite qu'on travaille sur le long terme.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

Plus sérieusement, il y a des choses qui sont *jolies* dans
un code et qu'on laisse tomber parce que non maintenables (genre
un i |= ~1 vu récemment ici).

Ca c'est pas joli, pas beau, je suis d'accord.

Non, moi je trouve ça joli et beau.
Mais pas maintenable.

Naivement j'espérais que la contractualisation de la recherche c'était
de

donner de l'argent sur des résultats et non sur des objectifs...
Qu'est-ce

que je suis naïf...

Disons que la meilleure idée peut donner la pire mise en pratique
si on ne fait pas attention à ce qu'on fait.

J'imagine que tu sais ce que tu dis...

Je caricature un peu, mais il y a un fond de vérité...

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...

Johann Dantant wrote:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjemh6$7gs$1@news.cict.fr...

Johann Dantant wrote:
(...)

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 ?

Pourquoi verser immédiatement dans la caricature ?

Pour montrer que l'argument "bottom-up" n'est pas
suffisant.

Sérieusement, quand on
voit débarquer des stagiaires qui n'ont aucune, mais absolument aucune idée
de ce que le nombre de bits du type int a comme impact sur leur code, on
croit rêver ! Quand après 3 ans de formation Java il faut leur expliquer
pourquoi la valeur 0x1234 qu'ils envoient au gars en face est interprétée
par lui comme étant 0x3412, on ne rêve plus, on pleure... Par contre, on
leur a bien appris à mettre 1234 en UTF-8 dans un fichier XML, c'est vrai...

J'ai milité contre l'enseignement du C et de l'architecture ?
Je pense que le C comme premier langage est une erreur, c'est
un peu différent.

Parmi tous les
collègues et stagiaires que j'ai eu et que j'ai encore, seuls ceux qui
ont

suivi cette logique ont de réelles compétences utilisables pour faire
autre

chose que des camemberts ou des histogrammes.

Sérieux ? T'es sur qu'ils ont tous commencé la prog par l'ASM ?

Pas forcément l'assembleur. Mais au minimum par de bonnes notions d'algèbre
booléenne, par des notions fondamentales d'architecture, par des TPs de
maths ou de physique bien ciblés (récursivité, calculs matriciels, tri...).

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Le langage importe peu, personnellement j'ai commencé par le Pascal puis le
C puis enfin l'assembleur, mais cela ne me semble vraiment pas
déterminant...

Dans notre formation, c'est Pascal puis C et ASM en //.

Le point important à mon avis est que l'étudiant touche du
doigt se qui se passe physiquement dans la machine quand il écrit telle
ligne de code plutôt que telle autre.

Oui.

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.
Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses connaissances
sont réduites, à un gars qui a survolé tous les domaines dans sa formation
mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et un juste milieu ?

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux qui
réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

C'est certain que ça peut
prendre du temps, ce n'est peut-être pas accessible à tout le monde, mais ce
n'est pas en allant au plus vite qu'on travaille sur le long terme.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

Plus sérieusement, il y a des choses qui sont *jolies* dans
un code et qu'on laisse tomber parce que non maintenables (genre
un i |= ~1 vu récemment ici).

Ca c'est pas joli, pas beau, je suis d'accord.

Non, moi je trouve ça joli et beau.
Mais pas maintenable.

Naivement j'espérais que la contractualisation de la recherche c'était
de

donner de l'argent sur des résultats et non sur des objectifs...
Qu'est-ce

que je suis naïf...

Disons que la meilleure idée peut donner la pire mise en pratique
si on ne fait pas attention à ce qu'on fait.

J'imagine que tu sais ce que tu dis...

Je caricature un peu, mais il y a un fond de vérité...

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...

Vous avez filtré cet utilisateur ! Consultez son message

Johann Dantant wrote:

"Marc Boyer" a écrit dans le message
de news:cjemh6$7gs$
Johann Dantant wrote:
(...)

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 ?

Pourquoi verser immédiatement dans la caricature ?

Pour montrer que l'argument "bottom-up" n'est pas
suffisant.

Sérieusement, quand on
voit débarquer des stagiaires qui n'ont aucune, mais absolument aucune idée
de ce que le nombre de bits du type int a comme impact sur leur code, on
croit rêver ! Quand après 3 ans de formation Java il faut leur expliquer
pourquoi la valeur 0x1234 qu'ils envoient au gars en face est interprétée
par lui comme étant 0x3412, on ne rêve plus, on pleure... Par contre, on
leur a bien appris à mettre 1234 en UTF-8 dans un fichier XML, c'est vrai...

J'ai milité contre l'enseignement du C et de l'architecture ?
Je pense que le C comme premier langage est une erreur, c'est
un peu différent.

Parmi tous les
collègues et stagiaires que j'ai eu et que j'ai encore, seuls ceux qui
ont

suivi cette logique ont de réelles compétences utilisables pour faire
autre

chose que des camemberts ou des histogrammes.

Sérieux ? T'es sur qu'ils ont tous commencé la prog par l'ASM ?

Pas forcément l'assembleur. Mais au minimum par de bonnes notions d'algèbre
booléenne, par des notions fondamentales d'architecture, par des TPs de
maths ou de physique bien ciblés (récursivité, calculs matriciels, tri...).

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Le langage importe peu, personnellement j'ai commencé par le Pascal puis le
C puis enfin l'assembleur, mais cela ne me semble vraiment pas
déterminant...

Dans notre formation, c'est Pascal puis C et ASM en //.

Le point important à mon avis est que l'étudiant touche du
doigt se qui se passe physiquement dans la machine quand il écrit telle
ligne de code plutôt que telle autre.

Oui.

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.
Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses connaissances
sont réduites, à un gars qui a survolé tous les domaines dans sa formation
mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et un juste milieu ?

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux qui
réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

C'est certain que ça peut
prendre du temps, ce n'est peut-être pas accessible à tout le monde, mais ce
n'est pas en allant au plus vite qu'on travaille sur le long terme.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

Plus sérieusement, il y a des choses qui sont *jolies* dans
un code et qu'on laisse tomber parce que non maintenables (genre
un i |= ~1 vu récemment ici).

Ca c'est pas joli, pas beau, je suis d'accord.

Non, moi je trouve ça joli et beau.
Mais pas maintenable.

Naivement j'espérais que la contractualisation de la recherche c'était
de

donner de l'argent sur des résultats et non sur des objectifs...
Qu'est-ce

que je suis naïf...

Disons que la meilleure idée peut donner la pire mise en pratique
si on ne fait pas attention à ce qu'on fait.

J'imagine que tu sais ce que tu dis...

Je caricature un peu, mais il y a un fond de vérité...

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

30/09/2004 à 10:30

cedric wrote:

Marc Boyer wrote:
Je t'invite si tu as du temps à fréquenter le forum c++,
à lire les "Design Pattern" ou "Rumination in C++".

Lire également "practical reusable unix software", par le labo d'AT&T
auquel on doit entre autre le programme dotty.

Il est en effet sur ma liste des choses à lire.

Ce livre relate leur
expérience (dans les années 80) pour développer des softs utiles et
réutilisables. Ils ont atteint la proportion de 50% de réutilisation
dans leur distribution d'outils. Comme quoi le problème peut être pensé
sans en faire une question de langage (ils codent tout en C, utilisent
le Shell comme "langage d'action" et utilisent des ordonnanceurs entre
les deux).

Une lecture qui repose du brouhaha des objets et des patterns.

Je ferais la comparaison quand j'aurais lu les deux.

Par exemple, il faut pas coder longtemps pour réaliser
que les exceptions sont la meilleure solution à ce jour à la
gestion d'erreur. Et que l'OO est la meilleure pour
lier libération des ressources et gestion d'erreur.

Exception ? On reparle de l'assembleur ?? :-D

Non, car l'assembleur ne permet pas de libérer les
ressources en ordre inverse d'aquisition lors d'une
exception.

Taquineries à part, ces mécanismes - objets, exceptions, patterns,
tolérence aux pannes, gestion des ressources... - sont à enseigner
quelque soit le langage.

Mais avec un langage qui offre un support, c'est plus facile.

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

30/09/2004 à 10:33

Jean-Marc Bourguet wrote:

Quel relativisme? Je défends simplement la thèse qu'il vaut
mieux commencer l'enseignement par le niveau d'abstraction
le plus élevé utilisé et descendre que l'inverse. Parce que
ce niveau est plus simple et qu'il sera plus utilisé que les
autres.

Tiens, juste pour compliquer un peu les choses, moi je
suis pour un niveau d'abstraction moyen pour commencer:
variables, conditions, boucles, fonctions, récursivité,
puis on part ensuite dans les deux directions.

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

30/09/2004 à 10:49

cedric wrote:

Eric Deveaud wrote:
L'assembleur peur aussi sembler un mauvais investissement du fait qu'il
change de machine en machine. Pourtant, les principes de bases restent
toujours plus ou moins les mêmes

dans ce cas pourquoi ne pas utiliser une machine de turing pour
apprendre la programation ??

Et pourquoi ne pas en concevoir une petite (en pensée!) avec les
étudiants lors du premier cours ? Un peut comme Knuth dans son cours ?

On pourrait réaliser quelques algorithmes avec, résoudre quelques
problèmes. Et une fois qu'ils auraient compris, avec les doigts, les
"principes" d'un algorithme, vous pourriez embrayer sur une vrai machine
et un vrai langage (au hasard, le C) ?

Et comment saisir les données en entrée de l'algorithme en C ?
Comment gérer les conversions implicites ?

int moyenne(int data[], size_t nbEchantillon){
int somme=0;
for(int i=0; i < nbEchantillon ; ++i){
somme+= data[i];
}
return somme/nbEchantillon;
}

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...

Johann Dantant

30/09/2004 à 10:57

"Marc Boyer" a écrit dans le message
de news:cjgft8$19j$
(...)

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Je ne dis pas que ça en donne... Je pense par contre que ça impose de les
avoir avant... Et que c'est le bon sens, le sens logique de progression.

(...)

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.

Ca c'est évident. Mais je reste persuadé qu'il est plus acceptable de
n'avoir que des bases dans chacun de ces langages mais d'avoir une acquis
une méthode et une rigueur, que de connaître par coeur la hiérarchie des
classes de haut niveau sans avoir intégré tous les mécanismes sous-jacents.

Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Qu'un technicien digère de la technique qu'il va pouvoir immédiatement
mettre en pratique, ça me paraît tout à fait normal... Mais un ingénieur,
fut-il d'une ENSI, ne doit pas s'arrêter à ça, il doit évidemment avoir de
la technique mais il doit surtout comprendre ce qu'il fait...

Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses
connaissances

sont réduites, à un gars qui a survolé tous les domaines dans sa
formation

mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et un juste milieu ?

Jamais vu. Ca doit être spécifique à notre microcosme...

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux
qui

réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

Oui. C'est pareil pour un stage, à la fin on met une note, il y a ceux qui
en réchappent et les autres. C'est pareil pour une pré-embauche, il y a ceux
qui restent et ceux qui ne restent pas.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne bien
rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

(...)

JD
--
J > Y sont pas normaux chez Teaser. Ils refusent les abonnements.
JRV> Mais si. Nous avons tous 5 bras, 2 tetes et 4 oreilles :-)
Manque juste les yeux et quelque autre outil fort utile.
-+- Wolf in GNU : À la queue comme tout le monde -+-

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjgft8$19j$1@news.cict.fr...
(...)

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Je ne dis pas que ça en donne... Je pense par contre que ça impose de les
avoir avant... Et que c'est le bon sens, le sens logique de progression.

(...)

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.

Ca c'est évident. Mais je reste persuadé qu'il est plus acceptable de
n'avoir que des bases dans chacun de ces langages mais d'avoir une acquis
une méthode et une rigueur, que de connaître par coeur la hiérarchie des
classes de haut niveau sans avoir intégré tous les mécanismes sous-jacents.

Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Qu'un technicien digère de la technique qu'il va pouvoir immédiatement
mettre en pratique, ça me paraît tout à fait normal... Mais un ingénieur,
fut-il d'une ENSI, ne doit pas s'arrêter à ça, il doit évidemment avoir de
la technique mais il doit surtout comprendre ce qu'il fait...

Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses
connaissances

sont réduites, à un gars qui a survolé tous les domaines dans sa
formation

mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et un juste milieu ?

Jamais vu. Ca doit être spécifique à notre microcosme...

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux
qui

réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

Oui. C'est pareil pour un stage, à la fin on met une note, il y a ceux qui
en réchappent et les autres. C'est pareil pour une pré-embauche, il y a ceux
qui restent et ceux qui ne restent pas.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne bien
rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

(...)

JD
--
J > Y sont pas normaux chez Teaser. Ils refusent les abonnements.
JRV> Mais si. Nous avons tous 5 bras, 2 tetes et 4 oreilles :-)
Manque juste les yeux et quelque autre outil fort utile.
-+- Wolf in GNU : À la queue comme tout le monde -+-

Vous avez filtré cet utilisateur ! Consultez son message

"Marc Boyer" a écrit dans le message
de news:cjgft8$19j$
(...)

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Je ne dis pas que ça en donne... Je pense par contre que ça impose de les
avoir avant... Et que c'est le bon sens, le sens logique de progression.

(...)

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.

Ca c'est évident. Mais je reste persuadé qu'il est plus acceptable de
n'avoir que des bases dans chacun de ces langages mais d'avoir une acquis
une méthode et une rigueur, que de connaître par coeur la hiérarchie des
classes de haut niveau sans avoir intégré tous les mécanismes sous-jacents.

Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Qu'un technicien digère de la technique qu'il va pouvoir immédiatement
mettre en pratique, ça me paraît tout à fait normal... Mais un ingénieur,
fut-il d'une ENSI, ne doit pas s'arrêter à ça, il doit évidemment avoir de
la technique mais il doit surtout comprendre ce qu'il fait...

Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses
connaissances

sont réduites, à un gars qui a survolé tous les domaines dans sa
formation

mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et un juste milieu ?

Jamais vu. Ca doit être spécifique à notre microcosme...

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux
qui

réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

Oui. C'est pareil pour un stage, à la fin on met une note, il y a ceux qui
en réchappent et les autres. C'est pareil pour une pré-embauche, il y a ceux
qui restent et ceux qui ne restent pas.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne bien
rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

(...)

JD
--
J > Y sont pas normaux chez Teaser. Ils refusent les abonnements.
JRV> Mais si. Nous avons tous 5 bras, 2 tetes et 4 oreilles :-)
Manque juste les yeux et quelque autre outil fort utile.
-+- Wolf in GNU : À la queue comme tout le monde -+-

Marc Boyer

30/09/2004 à 11:05

Johann Dantant wrote:

"Marc Boyer" a écrit dans le message
de news:cjgft8$19j$
(...)
En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Je ne dis pas que ça en donne... Je pense par contre que ça impose de les
avoir avant... Et que c'est le bon sens, le sens logique de progression.

Oui, d'accord, il faut avoir fait tout ça avant de faire du C.
Et bien je milite pour avoir aussi travailé avec un autre langage
de programmation avant de passer au C.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.

Ca c'est évident. Mais je reste persuadé qu'il est plus acceptable de
n'avoir que des bases dans chacun de ces langages mais d'avoir une acquis
une méthode et une rigueur, que de connaître par coeur la hiérarchie des
classes de haut niveau sans avoir intégré tous les mécanismes sous-jacents.

Nous sommes d'accord.

Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Qu'un technicien digère de la technique qu'il va pouvoir immédiatement
mettre en pratique, ça me paraît tout à fait normal... Mais un ingénieur,
fut-il d'une ENSI, ne doit pas s'arrêter à ça, il doit évidemment avoir de
la technique mais il doit surtout comprendre ce qu'il fait...

Idem.

Et un juste milieu ?

Jamais vu. Ca doit être spécifique à notre microcosme...

Recrutez plus de nos élèves ;-)

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux
qui

réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

Oui. C'est pareil pour un stage, à la fin on met une note, il y a ceux qui
en réchappent et les autres. C'est pareil pour une pré-embauche, il y a ceux
qui restent et ceux qui ne restent pas.

Oui, mais moi je forme des étudiants /et/ j'évalue leur
niveau. Je ne mets pas des obstacles sur la route juste
pour voir.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne bien
rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

Oui, mais je pense avoir de bien meilleurs résultats avec le
C comme *deuxième* langage et pas comme *premier*.

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...

Johann Dantant wrote:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjgft8$19j$1@news.cict.fr...
(...)

En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Je ne dis pas que ça en donne... Je pense par contre que ça impose de les
avoir avant... Et que c'est le bon sens, le sens logique de progression.

Oui, d'accord, il faut avoir fait tout ça avant de faire du C.
Et bien je milite pour avoir aussi travailé avec un autre langage
de programmation avant de passer au C.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.

Ca c'est évident. Mais je reste persuadé qu'il est plus acceptable de
n'avoir que des bases dans chacun de ces langages mais d'avoir une acquis
une méthode et une rigueur, que de connaître par coeur la hiérarchie des
classes de haut niveau sans avoir intégré tous les mécanismes sous-jacents.

Nous sommes d'accord.

Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Qu'un technicien digère de la technique qu'il va pouvoir immédiatement
mettre en pratique, ça me paraît tout à fait normal... Mais un ingénieur,
fut-il d'une ENSI, ne doit pas s'arrêter à ça, il doit évidemment avoir de
la technique mais il doit surtout comprendre ce qu'il fait...

Idem.

Et un juste milieu ?

Jamais vu. Ca doit être spécifique à notre microcosme...

Recrutez plus de nos élèves ;-)

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux
qui

réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

Oui. C'est pareil pour un stage, à la fin on met une note, il y a ceux qui
en réchappent et les autres. C'est pareil pour une pré-embauche, il y a ceux
qui restent et ceux qui ne restent pas.

Oui, mais moi je forme des étudiants /et/ j'évalue leur
niveau. Je ne mets pas des obstacles sur la route juste
pour voir.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne bien
rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

Oui, mais je pense avoir de bien meilleurs résultats avec le
C comme *deuxième* langage et pas comme *premier*.

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...

Vous avez filtré cet utilisateur ! Consultez son message

Johann Dantant wrote:

"Marc Boyer" a écrit dans le message
de news:cjgft8$19j$
(...)
En quoi le C ou l'ASM comme premier langage donne-t-il des
notions d'algèbre booléene, de maths et de physiques ?

Je ne dis pas que ça en donne... Je pense par contre que ça impose de les
avoir avant... Et que c'est le bon sens, le sens logique de progression.

Oui, d'accord, il faut avoir fait tout ça avant de faire du C.
Et bien je milite pour avoir aussi travailé avec un autre langage
de programmation avant de passer au C.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information.

J'ai longtemps cru cela. Mais au final, quand on met sur le
marché un type qui n'a jamais touché à C, Java ou C++, ben,
il reste sur le carreau.

Ca c'est évident. Mais je reste persuadé qu'il est plus acceptable de
n'avoir que des bases dans chacun de ces langages mais d'avoir une acquis
une méthode et une rigueur, que de connaître par coeur la hiérarchie des
classes de haut niveau sans avoir intégré tous les mécanismes sous-jacents.

Nous sommes d'accord.

Alors après, il y a diplome et diplome. On accepte peut-être
de recruter un normalien qui ne sait rien faire mais qui apprendra.
Sur des dipomes moins cote type IUP ou ENSI, un peu de technique,
c'est pas mal aussi.

Qu'un technicien digère de la technique qu'il va pouvoir immédiatement
mettre en pratique, ça me paraît tout à fait normal... Mais un ingénieur,
fut-il d'une ENSI, ne doit pas s'arrêter à ça, il doit évidemment avoir de
la technique mais il doit surtout comprendre ce qu'il fait...

Idem.

Et un juste milieu ?

Jamais vu. Ca doit être spécifique à notre microcosme...

Recrutez plus de nos élèves ;-)

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux
qui

réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations.

"ceux qui en réchappent"...

Oui. C'est pareil pour un stage, à la fin on met une note, il y a ceux qui
en réchappent et les autres. C'est pareil pour une pré-embauche, il y a ceux
qui restent et ceux qui ne restent pas.

Oui, mais moi je forme des étudiants /et/ j'évalue leur
niveau. Je ne mets pas des obstacles sur la route juste
pour voir.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne bien
rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

Oui, mais je pense avoir de bien meilleurs résultats avec le
C comme *deuxième* langage et pas comme *premier*.

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...

Johann Dantant

30/09/2004 à 11:08

Tiens, juste pour compliquer un peu les choses, moi je
suis pour un niveau d'abstraction moyen pour commencer:
variables, conditions, boucles, fonctions, récursivité,
puis on part ensuite dans les deux directions.

Marc Boyer

C'est à mon avis pas idiot du tout comme point de départ. C'est peut-être
même le seul moment où l'on peut encore expliquer que le langage n'est qu'un
outil, et qu'on peut travailler sur des variables, conditions, boucles...
aussi bien en C qu'en assembleur ou qu'en Java, mais aussi et surtout en
langage clair et en schémas... Après, c'est sans doute trop tard...

JD

Johann Dantant

30/09/2004 à 11:16

"Marc Boyer" a écrit dans le message
de news:cjgi8e$19j$

(...)

Oui, mais moi je forme des étudiants /et/ j'évalue leur
niveau. Je ne mets pas des obstacles sur la route juste
pour voir.

C'est mon côté obscur qui se voit un peu trop... Mais quand on a un timing
serré et des contraintes fortes, on n'est content d'avoir identifié ceux qui
sauront pas sauter les obstacles avant que le coup de bourre n'arrive.

Ben moi, si j'ai deux chemins qui mènent au même niveau, un
qui me permet d'y ammener 80% des élèves et une autre 40%, ben
je choisis celle à 80%.

La cause est noble, l'intention est louable. Mais la difficulté est ne
bien

rester au même niveau final, et non pas de viser un niveau plus bas sous
prétexte qu'on y a amène plus d'élèves...

Oui, mais je pense avoir de bien meilleurs résultats avec le
C comme *deuxième* langage et pas comme *premier*.

Eh bien j'espère que le résultat obtenu est ou sera en accord avec ta
théorie. Mais ce n'est qu'une fois les étudiants sortis de l'école avec le
diplôme en poche, qu'on peut commencer à évaluer ce résultat.

JD

Marc Boyer

30/09/2004 à 11:23

Johann Dantant wrote:

Oui, mais je pense avoir de bien meilleurs résultats avec le
C comme *deuxième* langage et pas comme *premier*.

Eh bien j'espère que le résultat obtenu est ou sera en accord avec ta
théorie. Mais ce n'est qu'une fois les étudiants sortis de l'école avec le
diplôme en poche, qu'on peut commencer à évaluer ce résultat.

Dès le deuxième année on voit comment ils se débrouillent avec
la famille des pthread_*, socket and co.

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...

... et ils ont viré le C

10 réponses

Veuillez sélectionner un problème