Chercher un livre sur le C avec certains critères.

candide

12/03/2008 à 10:44

Ne te contente pas de voir, regarde un peu plus en detail et tu as
l'explication que tu cherches...

Tu ne sembles pas avoir compris que c'est moins le C que l'enseignement
du C qui m'intéresse.

Jean-Marc Bourguet

12/03/2008 à 11:14

candide writes:

Ne te contente pas de voir, regarde un peu plus en detail et tu as
l'explication que tu cherches...

Tu ne sembles pas avoir compris que c'est moins le C que l'enseignement du
C qui m'intéresse.

Tu ne sembles pas avoir compris mon point.

Tu as declare quelque chose comme "C'est surprenant de voir un discours
contre les variables globales quand on voit la masse de variables globales
qu'il y a dans le code industriel."

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

En passant, ce discours n'est pas (uniquement) d'origine academique.

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet

12/03/2008 à 11:14

Marc Boyer writes:

Mais bon, je préfère expliquer aux étudiants "qu'on ne fait pas de
variable globale quand on est débutant" que de devoir expliquer ce
qu'est un singleton.

Avant d'expliquer ce qu'est un singleton, fait une recherche sur "singleton
anti-pattern".

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

candide

12/03/2008 à 12:47

candide writes:

Ne te contente pas de voir, regarde un peu plus en detail et tu as
l'explication que tu cherches...

Tu ne sembles pas avoir compris que c'est moins le C que l'enseignement du
C qui m'intéresse.

Tu ne sembles pas avoir compris mon point.

En effet, souvent on ne comprend pas que quelqu'un ne comprenne pas
l'évidence.

Tu as declare quelque chose comme "C'est surprenant de voir un discours
contre les variables globales quand on voit la masse de variables globales
qu'il y a dans le code industriel."

Oui, c'est en effet ce que je dis.

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?
Moi, ce qui m'intéresse c'est ce hiatus. Je pense qu'il y a certainement
de bonnes raisons pour ne pas utiliser de variables globales, qu'il est
préférable de ne pas prendre l'habitude d'en utiliser, moi-même bien que
ne faisant pas de programmation au long cours, j'aurais tendance à
appliquer ces règles. Il n'en demeure pas moins que les ouvrages de C en
général ne sont pas CONVAINCANTS quant à la non-utilisation des
variables globales, K&R2 le premier puisqu'il en utilise abondamment
comme chacun le sait et que ses arguments sont très peu convaincants, je
vais les citer (§1.10):

----------------------------8<-------------------------------------------
By the way, there is a tendency to make everything in sight an extern
variable because it appears to simplify communications - argument lists
are short and variables are always there when you want them. But
external variables are always there even when you don't want them.
Relying too heavily on external variables is fraught with peril since it
leads to programs whose data connections are not all obvious - variables
can be changed in unexpected and even inadvertent ways, and the program
is hard to modify.
---------------------------->8-------------------------------------------

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE et et qui NE CONVAINC PAS de ne pas utiliser de variable globale
(même si ce qui est dit ne dépasse pas l'entendement et est probablement
vrai). Les autres livres de C tiennent à peu près le même discours que
je sous-titrerais en : "pas de variable globale, c'est pas bien pa'ce
que K&R l'ont dit".

En réalité, plutôt que d'avoir cette attitude, il vaudrait mieux tenir
un discours plus argumenté où au lieu de diaboliser les variables
globales ce qui a sans doute l'effet inverse de celui recherché, on
dirait dans quelles circonstances restreintes on peut les utiliser.

Je crois ne jamais avoir vu d'exemple de code étant censé illustrer le
danger des variables globales. Le seul que j'ai vu est celui d'un
collègue qui enseigne le C et qui fait une aversion.

Par ailleurs, il faut aussi se poser la question de savoir si
l'utilisation de variables globales n'est pas une facilité que l'on
s'accorde parce qu'on a mal compris d'autres notions qui permettraient
de s'en dispenser. D'où à nouveau mes interrogations sur la façon dont
le C est enseigné.

En passant, ce discours n'est pas (uniquement) d'origine academique.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

candide <c-candide@wanadoo.fr> writes:

Ne te contente pas de voir, regarde un peu plus en detail et tu as
l'explication que tu cherches...

Tu ne sembles pas avoir compris que c'est moins le C que l'enseignement du
C qui m'intéresse.

Tu ne sembles pas avoir compris mon point.

En effet, souvent on ne comprend pas que quelqu'un ne comprenne pas
l'évidence.

Tu as declare quelque chose comme "C'est surprenant de voir un discours
contre les variables globales quand on voit la masse de variables globales
qu'il y a dans le code industriel."

Oui, c'est en effet ce que je dis.

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?
Moi, ce qui m'intéresse c'est ce hiatus. Je pense qu'il y a certainement
de bonnes raisons pour ne pas utiliser de variables globales, qu'il est
préférable de ne pas prendre l'habitude d'en utiliser, moi-même bien que
ne faisant pas de programmation au long cours, j'aurais tendance à
appliquer ces règles. Il n'en demeure pas moins que les ouvrages de C en
général ne sont pas CONVAINCANTS quant à la non-utilisation des
variables globales, K&R2 le premier puisqu'il en utilise abondamment
comme chacun le sait et que ses arguments sont très peu convaincants, je
vais les citer (§1.10):

----------------------------8<-------------------------------------------
By the way, there is a tendency to make everything in sight an extern
variable because it appears to simplify communications - argument lists
are short and variables are always there when you want them. But
external variables are always there even when you don't want them.
Relying too heavily on external variables is fraught with peril since it
leads to programs whose data connections are not all obvious - variables
can be changed in unexpected and even inadvertent ways, and the program
is hard to modify.
---------------------------->8-------------------------------------------

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE et et qui NE CONVAINC PAS de ne pas utiliser de variable globale
(même si ce qui est dit ne dépasse pas l'entendement et est probablement
vrai). Les autres livres de C tiennent à peu près le même discours que
je sous-titrerais en : "pas de variable globale, c'est pas bien pa'ce
que K&R l'ont dit".

En réalité, plutôt que d'avoir cette attitude, il vaudrait mieux tenir
un discours plus argumenté où au lieu de diaboliser les variables
globales ce qui a sans doute l'effet inverse de celui recherché, on
dirait dans quelles circonstances restreintes on peut les utiliser.

Je crois ne jamais avoir vu d'exemple de code étant censé illustrer le
danger des variables globales. Le seul que j'ai vu est celui d'un
collègue qui enseigne le C et qui fait une aversion.

Par ailleurs, il faut aussi se poser la question de savoir si
l'utilisation de variables globales n'est pas une facilité que l'on
s'accorde parce qu'on a mal compris d'autres notions qui permettraient
de s'en dispenser. D'où à nouveau mes interrogations sur la façon dont
le C est enseigné.

En passant, ce discours n'est pas (uniquement) d'origine academique.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

Vous avez filtré cet utilisateur ! Consultez son message

candide writes:

Ne te contente pas de voir, regarde un peu plus en detail et tu as
l'explication que tu cherches...

Tu ne sembles pas avoir compris que c'est moins le C que l'enseignement du
C qui m'intéresse.

Tu ne sembles pas avoir compris mon point.

En effet, souvent on ne comprend pas que quelqu'un ne comprenne pas
l'évidence.

Tu as declare quelque chose comme "C'est surprenant de voir un discours
contre les variables globales quand on voit la masse de variables globales
qu'il y a dans le code industriel."

Oui, c'est en effet ce que je dis.

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?
Moi, ce qui m'intéresse c'est ce hiatus. Je pense qu'il y a certainement
de bonnes raisons pour ne pas utiliser de variables globales, qu'il est
préférable de ne pas prendre l'habitude d'en utiliser, moi-même bien que
ne faisant pas de programmation au long cours, j'aurais tendance à
appliquer ces règles. Il n'en demeure pas moins que les ouvrages de C en
général ne sont pas CONVAINCANTS quant à la non-utilisation des
variables globales, K&R2 le premier puisqu'il en utilise abondamment
comme chacun le sait et que ses arguments sont très peu convaincants, je
vais les citer (§1.10):

----------------------------8<-------------------------------------------
By the way, there is a tendency to make everything in sight an extern
variable because it appears to simplify communications - argument lists
are short and variables are always there when you want them. But
external variables are always there even when you don't want them.
Relying too heavily on external variables is fraught with peril since it
leads to programs whose data connections are not all obvious - variables
can be changed in unexpected and even inadvertent ways, and the program
is hard to modify.
---------------------------->8-------------------------------------------

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE et et qui NE CONVAINC PAS de ne pas utiliser de variable globale
(même si ce qui est dit ne dépasse pas l'entendement et est probablement
vrai). Les autres livres de C tiennent à peu près le même discours que
je sous-titrerais en : "pas de variable globale, c'est pas bien pa'ce
que K&R l'ont dit".

En réalité, plutôt que d'avoir cette attitude, il vaudrait mieux tenir
un discours plus argumenté où au lieu de diaboliser les variables
globales ce qui a sans doute l'effet inverse de celui recherché, on
dirait dans quelles circonstances restreintes on peut les utiliser.

Je crois ne jamais avoir vu d'exemple de code étant censé illustrer le
danger des variables globales. Le seul que j'ai vu est celui d'un
collègue qui enseigne le C et qui fait une aversion.

Par ailleurs, il faut aussi se poser la question de savoir si
l'utilisation de variables globales n'est pas une facilité que l'on
s'accorde parce qu'on a mal compris d'autres notions qui permettraient
de s'en dispenser. D'où à nouveau mes interrogations sur la façon dont
le C est enseigné.

En passant, ce discours n'est pas (uniquement) d'origine academique.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

Marc Boyer

12/03/2008 à 13:14

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?
Moi, ce qui m'intéresse c'est ce hiatus.

???
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?

Je pense qu'il y a certainement
de bonnes raisons pour ne pas utiliser de variables globales, qu'il est
préférable de ne pas prendre l'habitude d'en utiliser, moi-même bien que
ne faisant pas de programmation au long cours, j'aurais tendance à
appliquer ces règles. Il n'en demeure pas moins que les ouvrages de C en
général ne sont pas CONVAINCANTS quant à la non-utilisation des
variables globales,

Comme quoi, un prof en vrai, c'est pas plus mal ;-)

----------------------------8<-------------------------------------------
By the way, there is a tendency to make everything in sight an extern
variable because it appears to simplify communications - argument lists
are short and variables are always there when you want them. But
external variables are always there even when you don't want them.
Relying too heavily on external variables is fraught with peril since it
leads to programs whose data connections are not all obvious - variables
can be changed in unexpected and even inadvertent ways, and the program
is hard to modify.
---------------------------->8-------------------------------------------

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE et et qui NE CONVAINC PAS de ne pas utiliser de variable globale
(même si ce qui est dit ne dépasse pas l'entendement et est probablement
vrai).

Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".

Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.

En réalité, plutôt que d'avoir cette attitude, il vaudrait mieux tenir
un discours plus argumenté où au lieu de diaboliser les variables
globales ce qui a sans doute l'effet inverse de celui recherché, on
dirait dans quelles circonstances restreintes on peut les utiliser.

Je crois ne jamais avoir vu d'exemple de code étant censé illustrer le
danger des variables globales.

Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify

Par ailleurs, il faut aussi se poser la question de savoir si
l'utilisation de variables globales n'est pas une facilité que l'on
s'accorde parce qu'on a mal compris d'autres notions qui permettraient
de s'en dispenser.

Ben, souvent, c'est par pure flemme (ça évite d'ajouter un paramètre
dans les interfaces des sous-programmes). Non ? En tout cas, c'est
mon expérience.

D'où à nouveau mes interrogations sur la façon dont le C est enseigné.

Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

Ben oui. "errno" par exemple.
Et ben, des erreurs ont été commises il y a 25 ans de cela. Par souci
de compatibilité ascendante, on les a pas corrigé. De la à refaire les
mêmes...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?
Moi, ce qui m'intéresse c'est ce hiatus.

???
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?

Je pense qu'il y a certainement
de bonnes raisons pour ne pas utiliser de variables globales, qu'il est
préférable de ne pas prendre l'habitude d'en utiliser, moi-même bien que
ne faisant pas de programmation au long cours, j'aurais tendance à
appliquer ces règles. Il n'en demeure pas moins que les ouvrages de C en
général ne sont pas CONVAINCANTS quant à la non-utilisation des
variables globales,

Comme quoi, un prof en vrai, c'est pas plus mal ;-)

----------------------------8<-------------------------------------------
By the way, there is a tendency to make everything in sight an extern
variable because it appears to simplify communications - argument lists
are short and variables are always there when you want them. But
external variables are always there even when you don't want them.
Relying too heavily on external variables is fraught with peril since it
leads to programs whose data connections are not all obvious - variables
can be changed in unexpected and even inadvertent ways, and the program
is hard to modify.
---------------------------->8-------------------------------------------

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE et et qui NE CONVAINC PAS de ne pas utiliser de variable globale
(même si ce qui est dit ne dépasse pas l'entendement et est probablement
vrai).

Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".

Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.

En réalité, plutôt que d'avoir cette attitude, il vaudrait mieux tenir
un discours plus argumenté où au lieu de diaboliser les variables
globales ce qui a sans doute l'effet inverse de celui recherché, on
dirait dans quelles circonstances restreintes on peut les utiliser.

Je crois ne jamais avoir vu d'exemple de code étant censé illustrer le
danger des variables globales.

Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify

Par ailleurs, il faut aussi se poser la question de savoir si
l'utilisation de variables globales n'est pas une facilité que l'on
s'accorde parce qu'on a mal compris d'autres notions qui permettraient
de s'en dispenser.

Ben, souvent, c'est par pure flemme (ça évite d'ajouter un paramètre
dans les interfaces des sous-programmes). Non ? En tout cas, c'est
mon expérience.

D'où à nouveau mes interrogations sur la façon dont le C est enseigné.

Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

Ben oui. "errno" par exemple.
Et ben, des erreurs ont été commises il y a 25 ans de cela. Par souci
de compatibilité ascendante, on les a pas corrigé. De la à refaire les
mêmes...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Vous avez filtré cet utilisateur ! Consultez son message

Je te declare: "Ne regarde pas simplement le nombre de variables globales
qu'il y a mais aussi les problemes qu'elles posent, tu seras moins surpris
du discours contre les variables globales."

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?
Moi, ce qui m'intéresse c'est ce hiatus.

???
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?

Je pense qu'il y a certainement
de bonnes raisons pour ne pas utiliser de variables globales, qu'il est
préférable de ne pas prendre l'habitude d'en utiliser, moi-même bien que
ne faisant pas de programmation au long cours, j'aurais tendance à
appliquer ces règles. Il n'en demeure pas moins que les ouvrages de C en
général ne sont pas CONVAINCANTS quant à la non-utilisation des
variables globales,

Comme quoi, un prof en vrai, c'est pas plus mal ;-)

----------------------------8<-------------------------------------------
By the way, there is a tendency to make everything in sight an extern
variable because it appears to simplify communications - argument lists
are short and variables are always there when you want them. But
external variables are always there even when you don't want them.
Relying too heavily on external variables is fraught with peril since it
leads to programs whose data connections are not all obvious - variables
can be changed in unexpected and even inadvertent ways, and the program
is hard to modify.
---------------------------->8-------------------------------------------

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE et et qui NE CONVAINC PAS de ne pas utiliser de variable globale
(même si ce qui est dit ne dépasse pas l'entendement et est probablement
vrai).

Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".

Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.

En réalité, plutôt que d'avoir cette attitude, il vaudrait mieux tenir
un discours plus argumenté où au lieu de diaboliser les variables
globales ce qui a sans doute l'effet inverse de celui recherché, on
dirait dans quelles circonstances restreintes on peut les utiliser.

Je crois ne jamais avoir vu d'exemple de code étant censé illustrer le
danger des variables globales.

Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify

Par ailleurs, il faut aussi se poser la question de savoir si
l'utilisation de variables globales n'est pas une facilité que l'on
s'accorde parce qu'on a mal compris d'autres notions qui permettraient
de s'en dispenser.

Ben, souvent, c'est par pure flemme (ça évite d'ajouter un paramètre
dans les interfaces des sous-programmes). Non ? En tout cas, c'est
mon expérience.

D'où à nouveau mes interrogations sur la façon dont le C est enseigné.

Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

Ben oui. "errno" par exemple.
Et ben, des erreurs ont été commises il y a 25 ans de cela. Par souci
de compatibilité ascendante, on les a pas corrigé. De la à refaire les
mêmes...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Jean-Marc Bourguet

12/03/2008 à 14:08

candide writes:

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?

Mon point de vue n'est ni celui de celui qui apprend, ni de celui qui
enseigne. Je suis celui qui fait passer les interviews d'embauche et qui
accompagne les stagiaires et les nouveaux employes.

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE

Les exemples convainquants, c'est difficile a mettre dans un livre. Le
probleme n'apparait pas dans les petits programmes jouets qui servent dans
les livres. Le probleme n'apparait pas dans les projets qu'on peut donner
raisonnablement dans un cadre d'enseignement. Il apparait dans les
programmes qui ont vecus, dont les concepteurs initiaux ne sont plus la --
en fait, il n'y a plus personne dans la boite qui a connu les concepteurs
initiaux -- a moins que -- peut-etre pire -- ils aient ete "promus dans le
management" ce qui veut dire qu'ils sont en position d'imposer des choix en
fonction de souvenirs (deformes) de faits qui ont ete vrais (mais le ne
sont plus). Qui ont ete detournes de leur utilisation originale. Qui ont
ete fusionnes avec des programmes ecrits dans une autre boite quand les
deux ont ete rachetees par une troisieme qui a decide de sortir quelque
chose en deux mois apres les rachats. A ce moment-la, tu vois les
problemes.

Il y a plus d'un milieu dans ce metier. Il y a la boite internationale de
taille moyenne ayant une longue experience, quelques dizaines de programmes
certain datant de plusieurs decenies, ayant chacun plusieurs dizaines de
millions de lignes de code plus ou moins bien partages entre les
programmes, le tout resultant de fusion de dizaines de boites differentes
et appliquant des principes de genie logiciel plus ou moins ad hoc parce
que personne n'a de formation sur ce sujet, tout le monde etant plutot des
specialistes du metier... Il y a la start-up cherchant a avoir au plus
vite en prenant tous les raccourcis possible quelque chose de demoable qui
finira dans les programmes decrits ci-dessus. Il y a la societe faisant du
soft pour de l'embarque ou si une erreur a lieu, c'est 300 morts au
minimum. J'arrete et j'ai pas parle des ecoles, des chapelles et des
sectes.

Il ne faut pas non plus se leurer sur d'autres choses: il y a plus d'un
aspect dans le metier tel que je le vois pratiquer autour de moi. Il y a
au moins l'aspect algorithmique, l'aspect langage, l'aspect conception,
l'aspect genie logiciel...

Il ne faut pas se leurer, ces deux derniers aspects sont toujours dans
l'enfance. C'est pas encore une science, c'est toujours un artisanat ou il
faut admettre les lecons de l'experience des aines tout en la remettant en
cause parce que certaines ne sont pas aussi universelles ou meme simplement
aussi vraies que ca...

Ce n'est pas pour rien que des MBA se font apres quelques annees
d'experience. Il faudrait le meme genre de choses pour la conception et le
genie logiciel.

Mais le probleme, c'est que ca a des effets dans la pratique quotidienne de
tout le monde.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

* Je ne pense pas que le C soit un bon langage pour debuter en general.
Sans meme parler de debuter seul, ce qui est encore plus difficile.

* Je ne pense pas que le K&R soit un bon livre pour apprendre le C si on
n'a pas deja une experience en programmation.

* Je ne pense pas que le C soit particulierement bien concu si on applique
les criteres d'aujourd'hui. Une bonne partie de ces criteres resultent
de l'experience qu'on a avec le C et les choses qui datent d'avant et
d'apres.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

candide <c-candide@wanadoo.fr> writes:

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?

Mon point de vue n'est ni celui de celui qui apprend, ni de celui qui
enseigne. Je suis celui qui fait passer les interviews d'embauche et qui
accompagne les stagiaires et les nouveaux employes.

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE

Les exemples convainquants, c'est difficile a mettre dans un livre. Le
probleme n'apparait pas dans les petits programmes jouets qui servent dans
les livres. Le probleme n'apparait pas dans les projets qu'on peut donner
raisonnablement dans un cadre d'enseignement. Il apparait dans les
programmes qui ont vecus, dont les concepteurs initiaux ne sont plus la --
en fait, il n'y a plus personne dans la boite qui a connu les concepteurs
initiaux -- a moins que -- peut-etre pire -- ils aient ete "promus dans le
management" ce qui veut dire qu'ils sont en position d'imposer des choix en
fonction de souvenirs (deformes) de faits qui ont ete vrais (mais le ne
sont plus). Qui ont ete detournes de leur utilisation originale. Qui ont
ete fusionnes avec des programmes ecrits dans une autre boite quand les
deux ont ete rachetees par une troisieme qui a decide de sortir quelque
chose en deux mois apres les rachats. A ce moment-la, tu vois les
problemes.

Il y a plus d'un milieu dans ce metier. Il y a la boite internationale de
taille moyenne ayant une longue experience, quelques dizaines de programmes
certain datant de plusieurs decenies, ayant chacun plusieurs dizaines de
millions de lignes de code plus ou moins bien partages entre les
programmes, le tout resultant de fusion de dizaines de boites differentes
et appliquant des principes de genie logiciel plus ou moins ad hoc parce
que personne n'a de formation sur ce sujet, tout le monde etant plutot des
specialistes du metier... Il y a la start-up cherchant a avoir au plus
vite en prenant tous les raccourcis possible quelque chose de demoable qui
finira dans les programmes decrits ci-dessus. Il y a la societe faisant du
soft pour de l'embarque ou si une erreur a lieu, c'est 300 morts au
minimum. J'arrete et j'ai pas parle des ecoles, des chapelles et des
sectes.

Il ne faut pas non plus se leurer sur d'autres choses: il y a plus d'un
aspect dans le metier tel que je le vois pratiquer autour de moi. Il y a
au moins l'aspect algorithmique, l'aspect langage, l'aspect conception,
l'aspect genie logiciel...

Il ne faut pas se leurer, ces deux derniers aspects sont toujours dans
l'enfance. C'est pas encore une science, c'est toujours un artisanat ou il
faut admettre les lecons de l'experience des aines tout en la remettant en
cause parce que certaines ne sont pas aussi universelles ou meme simplement
aussi vraies que ca...

Ce n'est pas pour rien que des MBA se font apres quelques annees
d'experience. Il faudrait le meme genre de choses pour la conception et le
genie logiciel.

Mais le probleme, c'est que ca a des effets dans la pratique quotidienne de
tout le monde.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

* Je ne pense pas que le C soit un bon langage pour debuter en general.
Sans meme parler de debuter seul, ce qui est encore plus difficile.

* Je ne pense pas que le K&R soit un bon livre pour apprendre le C si on
n'a pas deja une experience en programmation.

* Je ne pense pas que le C soit particulierement bien concu si on applique
les criteres d'aujourd'hui. Une bonne partie de ces criteres resultent
de l'experience qu'on a avec le C et les choses qui datent d'avant et
d'apres.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

candide writes:

C'est évident. Mais du point de vue de la personne qui apprend le C,
comment un tel discours contre les variables globales est-il CRÉDIBLE ?

Mon point de vue n'est ni celui de celui qui apprend, ni de celui qui
enseigne. Je suis celui qui fait passer les interviews d'embauche et qui
accompagne les stagiaires et les nouveaux employes.

Voilà typiquement un discours _abstrait_ et formel ne contenant AUCUN
EXEMPLE

Les exemples convainquants, c'est difficile a mettre dans un livre. Le
probleme n'apparait pas dans les petits programmes jouets qui servent dans
les livres. Le probleme n'apparait pas dans les projets qu'on peut donner
raisonnablement dans un cadre d'enseignement. Il apparait dans les
programmes qui ont vecus, dont les concepteurs initiaux ne sont plus la --
en fait, il n'y a plus personne dans la boite qui a connu les concepteurs
initiaux -- a moins que -- peut-etre pire -- ils aient ete "promus dans le
management" ce qui veut dire qu'ils sont en position d'imposer des choix en
fonction de souvenirs (deformes) de faits qui ont ete vrais (mais le ne
sont plus). Qui ont ete detournes de leur utilisation originale. Qui ont
ete fusionnes avec des programmes ecrits dans une autre boite quand les
deux ont ete rachetees par une troisieme qui a decide de sortir quelque
chose en deux mois apres les rachats. A ce moment-la, tu vois les
problemes.

Il y a plus d'un milieu dans ce metier. Il y a la boite internationale de
taille moyenne ayant une longue experience, quelques dizaines de programmes
certain datant de plusieurs decenies, ayant chacun plusieurs dizaines de
millions de lignes de code plus ou moins bien partages entre les
programmes, le tout resultant de fusion de dizaines de boites differentes
et appliquant des principes de genie logiciel plus ou moins ad hoc parce
que personne n'a de formation sur ce sujet, tout le monde etant plutot des
specialistes du metier... Il y a la start-up cherchant a avoir au plus
vite en prenant tous les raccourcis possible quelque chose de demoable qui
finira dans les programmes decrits ci-dessus. Il y a la societe faisant du
soft pour de l'embarque ou si une erreur a lieu, c'est 300 morts au
minimum. J'arrete et j'ai pas parle des ecoles, des chapelles et des
sectes.

Il ne faut pas non plus se leurer sur d'autres choses: il y a plus d'un
aspect dans le metier tel que je le vois pratiquer autour de moi. Il y a
au moins l'aspect algorithmique, l'aspect langage, l'aspect conception,
l'aspect genie logiciel...

Il ne faut pas se leurer, ces deux derniers aspects sont toujours dans
l'enfance. C'est pas encore une science, c'est toujours un artisanat ou il
faut admettre les lecons de l'experience des aines tout en la remettant en
cause parce que certaines ne sont pas aussi universelles ou meme simplement
aussi vraies que ca...

Ce n'est pas pour rien que des MBA se font apres quelques annees
d'experience. Il faudrait le meme genre de choses pour la conception et le
genie logiciel.

Mais le probleme, c'est que ca a des effets dans la pratique quotidienne de
tout le monde.

"Académique" dans son sens dérivé de "convenu" et "formel". La norme n'a
rien à dire là-dessus, d'ailleurs il me _semble_ me rappeler qu'elle
propose des variables globales dans son code là où elle pourrait s'en
passer, c'est dire !

* Je ne pense pas que le C soit un bon langage pour debuter en general.
Sans meme parler de debuter seul, ce qui est encore plus difficile.

* Je ne pense pas que le K&R soit un bon livre pour apprendre le C si on
n'a pas deja une experience en programmation.

* Je ne pense pas que le C soit particulierement bien concu si on applique
les criteres d'aujourd'hui. Une bonne partie de ces criteres resultent
de l'experience qu'on a avec le C et les choses qui datent d'avant et
d'apres.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Antoine Leca

12/03/2008 à 15:18

En news:47d6f710$0$22185$, candide va escriure:

À mon sens, c'est pour cela que le K&R a été divinisé :

Content d'observer que tu fais toi aussi ce constat.

Le constat est de toi, je ne faisais que critiquer ton point de vue
(news:
et d'autres), et c'est par facilité pour la discussion que j'ai repris le
même style de formulation.
Par ailleurs, je ne considère pas que mon message d'hier valide ton point de
vue (comme pourrait le laisser penser ta citation).

Antoine
________
PS: Et non, je ne crois pas être le prof' mentionné par Stéphane, même si
parfois je peux lui ressembler sur l'horreur maladive de l'inexactitude.
Réf: : news:47d4626d$0$26750$

Jean-Marc Bourguet

12/03/2008 à 15:26

"Antoine Leca" writes:

PS: Et non, je ne crois pas être le prof' mentionné par Stéphane, même si
parfois je peux lui ressembler sur l'horreur maladive de l'inexactitude.

Ne pas aimer l'inexactitude, ca aide un peu dans le boulot.

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Antoine Leca

12/03/2008 à 15:58

En news:,
candide va escriure:

On 9 mar, 16:55, Michel <nospam> wrote:

Et il a combien d'années (ou décennies) d'expérience cet enfant pour

Argument d'autorité.

pouvoir proposer un tutorial ?!

On te demande de juger sur pièces, alors examine le texte et formule
tes critiques, en faisant des citations précises.

http://www.siteduzero.com/tuto-3-3828-1-a-l-assaut-des-pointeurs.html

[...] je vais vous poser un problème que vous _ne_pourrez_pas_
résoudre sans utiliser de pointeurs. Ce sera en quelque sorte
le fil rouge du chapitre. Nous en reparlerons à la fin de ce
chapitre et verrons quelle est la solution en utilisant ce que
vous aurez appris.

Voici le problème : je veux écrire une fonction qui renvoie 2 valeurs.

Évidemment c'est moi qui souligne. Pour dire que je ne suis pas tout-à-fait
d'accord.

struct horodatage { long h, m; };

struct horodatage decoupeMinutes(long heures, long minutes)
{
struct horodatage local = {0};

local.m = minutes % 60;
local.h = heures + minutes / 60;
return local;
}

Au passage, j'ai silencieusement corrigé l'imperfection qui consistait à
avoir «heures» en entrée (et préalablement initialisé), mais avec un code
qui n'utilisait heures que comme variable de sortie.

Évidemment, à la place de struct horodatage on peut #inclure <time.h> et
utiliser struct tm. Attention, le résultat est alors de type int, pas long.

struct tm splitMin(long heures, long minutes)
{
struct tm local = {0};

local.tm_min = minutes % 60;
local.tm_hour = heures + minutes / 60;
return local;
}

Problème, l'utilisation de la solution sans-pointeur nécessite une
adaptation : il faut soit écrire

printf("%d heures et %d minutesn",
splitMin(heures, minutes).tm_hour, splitMin(heures,
minutes).tm_min);

soit passer par une variable intermédiaire de type struct horodatage, et on
a alors

struct horodatage resultat;
/* ... */

resultat = decoupeMinutes(heures, minutes);
printf("%ld heures et %ld minutesn", resultat.h, resultat.m);

Le fait est que le code original #inclut <stdlib.h>, sans qu'à première vue
ce soit nécessaire. Ou plutôt, alors même que cela peut donner l'idée
d'utiliser une solution alternative (qui est dans les faits très peu
différente de celle ci-dessus, surtout en C99) :

ldiv_t result ={0};
/* ... */

result = ldiv(minutes, 60);
printf("%ld heures et %ld minutesn", result.quot, result.rem);
printf("soit environ %ld heuresn", ldiv(minutes+30, 60).quot);

[On peut améliorer le calcul de l'arrondi pour tenir compte du signe de
minutes, mais ce n'est pas le sujet ici.]

Antoine

En news:d2cdb966-9545-4d8c-bc33-2d13cb46909a@m36g2000hse.googlegroups.com,
candide va escriure:

On 9 mar, 16:55, Michel <nospam> wrote:

Et il a combien d'années (ou décennies) d'expérience cet enfant pour

Argument d'autorité.

pouvoir proposer un tutorial ?!

On te demande de juger sur pièces, alors examine le texte et formule
tes critiques, en faisant des citations précises.

http://www.siteduzero.com/tuto-3-3828-1-a-l-assaut-des-pointeurs.html

[...] je vais vous poser un problème que vous _ne_pourrez_pas_
résoudre sans utiliser de pointeurs. Ce sera en quelque sorte
le fil rouge du chapitre. Nous en reparlerons à la fin de ce
chapitre et verrons quelle est la solution en utilisant ce que
vous aurez appris.

Voici le problème : je veux écrire une fonction qui renvoie 2 valeurs.

Évidemment c'est moi qui souligne. Pour dire que je ne suis pas tout-à-fait
d'accord.

struct horodatage { long h, m; };

struct horodatage decoupeMinutes(long heures, long minutes)
{
struct horodatage local = {0};

local.m = minutes % 60;
local.h = heures + minutes / 60;
return local;
}

Au passage, j'ai silencieusement corrigé l'imperfection qui consistait à
avoir «heures» en entrée (et préalablement initialisé), mais avec un code
qui n'utilisait heures que comme variable de sortie.

Évidemment, à la place de struct horodatage on peut #inclure <time.h> et
utiliser struct tm. Attention, le résultat est alors de type int, pas long.

struct tm splitMin(long heures, long minutes)
{
struct tm local = {0};

local.tm_min = minutes % 60;
local.tm_hour = heures + minutes / 60;
return local;
}

Problème, l'utilisation de la solution sans-pointeur nécessite une
adaptation : il faut soit écrire

printf("%d heures et %d minutesn",
splitMin(heures, minutes).tm_hour, splitMin(heures,
minutes).tm_min);

soit passer par une variable intermédiaire de type struct horodatage, et on
a alors

struct horodatage resultat;
/* ... */

resultat = decoupeMinutes(heures, minutes);
printf("%ld heures et %ld minutesn", resultat.h, resultat.m);

Le fait est que le code original #inclut <stdlib.h>, sans qu'à première vue
ce soit nécessaire. Ou plutôt, alors même que cela peut donner l'idée
d'utiliser une solution alternative (qui est dans les faits très peu
différente de celle ci-dessus, surtout en C99) :

ldiv_t result ={0};
/* ... */

result = ldiv(minutes, 60);
printf("%ld heures et %ld minutesn", result.quot, result.rem);
printf("soit environ %ld heuresn", ldiv(minutes+30, 60).quot);

[On peut améliorer le calcul de l'arrondi pour tenir compte du signe de
minutes, mais ce n'est pas le sujet ici.]

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

En news:,
candide va escriure:

On 9 mar, 16:55, Michel <nospam> wrote:

Et il a combien d'années (ou décennies) d'expérience cet enfant pour

Argument d'autorité.

pouvoir proposer un tutorial ?!

On te demande de juger sur pièces, alors examine le texte et formule
tes critiques, en faisant des citations précises.

http://www.siteduzero.com/tuto-3-3828-1-a-l-assaut-des-pointeurs.html

[...] je vais vous poser un problème que vous _ne_pourrez_pas_
résoudre sans utiliser de pointeurs. Ce sera en quelque sorte
le fil rouge du chapitre. Nous en reparlerons à la fin de ce
chapitre et verrons quelle est la solution en utilisant ce que
vous aurez appris.

Voici le problème : je veux écrire une fonction qui renvoie 2 valeurs.

Évidemment c'est moi qui souligne. Pour dire que je ne suis pas tout-à-fait
d'accord.

struct horodatage { long h, m; };

struct horodatage decoupeMinutes(long heures, long minutes)
{
struct horodatage local = {0};

local.m = minutes % 60;
local.h = heures + minutes / 60;
return local;
}

Au passage, j'ai silencieusement corrigé l'imperfection qui consistait à
avoir «heures» en entrée (et préalablement initialisé), mais avec un code
qui n'utilisait heures que comme variable de sortie.

Évidemment, à la place de struct horodatage on peut #inclure <time.h> et
utiliser struct tm. Attention, le résultat est alors de type int, pas long.

struct tm splitMin(long heures, long minutes)
{
struct tm local = {0};

local.tm_min = minutes % 60;
local.tm_hour = heures + minutes / 60;
return local;
}

Problème, l'utilisation de la solution sans-pointeur nécessite une
adaptation : il faut soit écrire

printf("%d heures et %d minutesn",
splitMin(heures, minutes).tm_hour, splitMin(heures,
minutes).tm_min);

soit passer par une variable intermédiaire de type struct horodatage, et on
a alors

struct horodatage resultat;
/* ... */

resultat = decoupeMinutes(heures, minutes);
printf("%ld heures et %ld minutesn", resultat.h, resultat.m);

Le fait est que le code original #inclut <stdlib.h>, sans qu'à première vue
ce soit nécessaire. Ou plutôt, alors même que cela peut donner l'idée
d'utiliser une solution alternative (qui est dans les faits très peu
différente de celle ci-dessus, surtout en C99) :

ldiv_t result ={0};
/* ... */

result = ldiv(minutes, 60);
printf("%ld heures et %ld minutesn", result.quot, result.rem);
printf("soit environ %ld heuresn", ldiv(minutes+30, 60).quot);

[On peut améliorer le calcul de l'arrondi pour tenir compte du signe de
minutes, mais ce n'est pas le sujet ici.]

Antoine

Antoine Leca

12/03/2008 à 16:32

En news:, Francois va escriure:

Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
<...>

Lorsque l'on enseigne le C, même lorsque l'on enseigne les
pointeurs, on arrive à faire passer le message aux élèves même sans
leur cacher de chose, sans faire entrer un brin d'architecture.

Bien sûr, je suis sûr que l'apprentissage du C peut se faire
parfaitement sans faire d'architecture.

Je ne crois pas qu'Anthony ait écrit cela.
Moi, j'ai lu qu'il fallait d'abord apprendre à programmer « propre » en C,
en faisant abstraction de l'architecture (les bases quoi), et ensuite (avec
une séquencialité marquée) apprendre à dominer les problèmes d'architecture.

Et j'opposerais ce point de vue à celui que je t'attribue (peut-être à
tort), qui est de vouloir mélanger les deux sujets, et apprendre en même
temps à programmer en C et à maîtriser les problèmes liés à l'architecture.

Je dis juste que faire un brin
d'architecture pour montrer comment ça se passe dans un cas
particulier, m'apporterai une plus value. Mais c'est personnel.

L'expérience la plus couramment relatée ici est justement que cette manière
d'apprendre amène à avoir des programmeurs, et donc des programmes, « mal
foutus » parce que trop dépendant d'axiomes architecturaux, peut-être
(sûrement) valables au moment où le code fût comis, mais qui posent problème
(voire sont devenus faux) par la suite.

Maintenant, il est évident que personne ne détient la vérité.
Ainsi le point de vue d'Anthony vise à renforcer fortement la nécessité
d'avoir du recul par rapport aux dépendances axiomatiques vis-à-vis de
l'architecture (même problème qu'avec les axiomes d'Euclide) ; ÀMHA avec
toute cette conversation, à ce point-ci de l'exposé tu devrais avoir compris
cette nécessité ; et tu peux continuer si cela te plaît à te fixer sur
l'architecture PC07, quite à aller vérifier le cas échéant les limites
normalisées au moment de peaufiner le code, ou à tout le moins mentionner
les cas d'emploi par exemple au sein du code de test de tes routines :
beaucoup de gens ont procédé de cette manière, et pour une utilisation
restreinte du langage C typique il n'est pas démontré que cela soit si
pernicieux (ou plus exactement les « démonstrations » que j'ai vu à ce sujet
ne m'ont jamais convaincues, elles violaient trop souvent un des axiomes,
restreint et C typique) ;
de plus, tu comprendras sûrement que dans un projet plus ambitieux, des
programmeurs plus expérimentés décident de normes de programmation parfois
contraignantes, et dont certains points peuvent sembler sans objet lorsque
l'on se restreint à la dite architecture PC07.

Antoine

En news:47D4143E.9020107@free.fr, Francois va escriure:

Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
<...>

Lorsque l'on enseigne le C, même lorsque l'on enseigne les
pointeurs, on arrive à faire passer le message aux élèves même sans
leur cacher de chose, sans faire entrer un brin d'architecture.

Bien sûr, je suis sûr que l'apprentissage du C peut se faire
parfaitement sans faire d'architecture.

Je ne crois pas qu'Anthony ait écrit cela.
Moi, j'ai lu qu'il fallait d'abord apprendre à programmer « propre » en C,
en faisant abstraction de l'architecture (les bases quoi), et ensuite (avec
une séquencialité marquée) apprendre à dominer les problèmes d'architecture.

Et j'opposerais ce point de vue à celui que je t'attribue (peut-être à
tort), qui est de vouloir mélanger les deux sujets, et apprendre en même
temps à programmer en C et à maîtriser les problèmes liés à l'architecture.

Je dis juste que faire un brin
d'architecture pour montrer comment ça se passe dans un cas
particulier, m'apporterai une plus value. Mais c'est personnel.

L'expérience la plus couramment relatée ici est justement que cette manière
d'apprendre amène à avoir des programmeurs, et donc des programmes, « mal
foutus » parce que trop dépendant d'axiomes architecturaux, peut-être
(sûrement) valables au moment où le code fût comis, mais qui posent problème
(voire sont devenus faux) par la suite.

Maintenant, il est évident que personne ne détient la vérité.
Ainsi le point de vue d'Anthony vise à renforcer fortement la nécessité
d'avoir du recul par rapport aux dépendances axiomatiques vis-à-vis de
l'architecture (même problème qu'avec les axiomes d'Euclide) ; ÀMHA avec
toute cette conversation, à ce point-ci de l'exposé tu devrais avoir compris
cette nécessité ; et tu peux continuer si cela te plaît à te fixer sur
l'architecture PC07, quite à aller vérifier le cas échéant les limites
normalisées au moment de peaufiner le code, ou à tout le moins mentionner
les cas d'emploi par exemple au sein du code de test de tes routines :
beaucoup de gens ont procédé de cette manière, et pour une utilisation
restreinte du langage C typique il n'est pas démontré que cela soit si
pernicieux (ou plus exactement les « démonstrations » que j'ai vu à ce sujet
ne m'ont jamais convaincues, elles violaient trop souvent un des axiomes,
restreint et C typique) ;
de plus, tu comprendras sûrement que dans un projet plus ambitieux, des
programmeurs plus expérimentés décident de normes de programmation parfois
contraignantes, et dont certains points peuvent sembler sans objet lorsque
l'on se restreint à la dite architecture PC07.

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

En news:, Francois va escriure:

Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
<...>

Lorsque l'on enseigne le C, même lorsque l'on enseigne les
pointeurs, on arrive à faire passer le message aux élèves même sans
leur cacher de chose, sans faire entrer un brin d'architecture.

Bien sûr, je suis sûr que l'apprentissage du C peut se faire
parfaitement sans faire d'architecture.

Je ne crois pas qu'Anthony ait écrit cela.
Moi, j'ai lu qu'il fallait d'abord apprendre à programmer « propre » en C,
en faisant abstraction de l'architecture (les bases quoi), et ensuite (avec
une séquencialité marquée) apprendre à dominer les problèmes d'architecture.

Et j'opposerais ce point de vue à celui que je t'attribue (peut-être à
tort), qui est de vouloir mélanger les deux sujets, et apprendre en même
temps à programmer en C et à maîtriser les problèmes liés à l'architecture.

Je dis juste que faire un brin
d'architecture pour montrer comment ça se passe dans un cas
particulier, m'apporterai une plus value. Mais c'est personnel.

L'expérience la plus couramment relatée ici est justement que cette manière
d'apprendre amène à avoir des programmeurs, et donc des programmes, « mal
foutus » parce que trop dépendant d'axiomes architecturaux, peut-être
(sûrement) valables au moment où le code fût comis, mais qui posent problème
(voire sont devenus faux) par la suite.

Maintenant, il est évident que personne ne détient la vérité.
Ainsi le point de vue d'Anthony vise à renforcer fortement la nécessité
d'avoir du recul par rapport aux dépendances axiomatiques vis-à-vis de
l'architecture (même problème qu'avec les axiomes d'Euclide) ; ÀMHA avec
toute cette conversation, à ce point-ci de l'exposé tu devrais avoir compris
cette nécessité ; et tu peux continuer si cela te plaît à te fixer sur
l'architecture PC07, quite à aller vérifier le cas échéant les limites
normalisées au moment de peaufiner le code, ou à tout le moins mentionner
les cas d'emploi par exemple au sein du code de test de tes routines :
beaucoup de gens ont procédé de cette manière, et pour une utilisation
restreinte du langage C typique il n'est pas démontré que cela soit si
pernicieux (ou plus exactement les « démonstrations » que j'ai vu à ce sujet
ne m'ont jamais convaincues, elles violaient trop souvent un des axiomes,
restreint et C typique) ;
de plus, tu comprendras sûrement que dans un projet plus ambitieux, des
programmeurs plus expérimentés décident de normes de programmation parfois
contraignantes, et dont certains points peuvent sembler sans objet lorsque
l'on se restreint à la dite architecture PC07.

Antoine

Chercher un livre sur le C avec certains critères.

10 réponses

Veuillez sélectionner un problème