Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage. C'est encore plus marque en shell, mais les constructions du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) { return CA_N_A_PAS_MARCHE; }
c'est extremement frequent et naturel comme logique.
Bof, l'evaluation paresseuse des && et des || en C et en shell est
idiomatique. Quelqu'un qui trebuche sur une ligne de code comme
celle donnee en exergue ne connait tout simplement pas bien le
langage. C'est encore plus marque en shell, mais les constructions
du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) {
return CA_N_A_PAS_MARCHE;
}
c'est extremement frequent et naturel comme logique.
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage. C'est encore plus marque en shell, mais les constructions du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) { return CA_N_A_PAS_MARCHE; }
c'est extremement frequent et naturel comme logique.
Tiens un elitiste :)
mips
mips
On 24 Apr 2004 12:19:32 GMT Cyrille Szymanski wrote:
On 2004-04-24, Michel Talon wrote:
Michel Talon wrote:
Ca ne fait pas exactement la même chose que le machin initial. Le machin initial avait un &&, avec l'évaluation paresseuse le premier échec suffisait. Le tien a un || ce qui nécessite dans tous les> cas les deux évaluations.
Non, je ferais mieux de ne pas poster le matin! !A && !B est vrai dés que A==NULL, sinon il faut évaluer B et c'est vrai si B==NULL
(A==NULL)||(B==NULL) est vrai dans les mêmes conditions. Donc les deux formes sont bien équivalentes sous l'évaluation paresseuse.
Oui c'est la loi de de Morgan : !(a&&b) == (!a)||(!b) !(a||b) == (!a)&&(!b)
Comme quoi manipuler ce genre d'expression en faisant attention aux effets de bord est loin d'être trivial.
Ce qui tombe pile poil dans mon discours.
mips
On 24 Apr 2004 12:19:32 GMT
Cyrille Szymanski <cns2@cns.invalid> wrote:
On 2004-04-24, Michel Talon <talon@lpthe.jussieu.fr> wrote:
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Ca ne fait pas exactement la même chose que le machin initial.
Le machin initial avait un &&, avec l'évaluation paresseuse le
premier échec suffisait. Le tien a un || ce qui nécessite dans
tous les> cas les deux évaluations.
Non, je ferais mieux de ne pas poster le matin!
!A && !B est vrai dés que A==NULL, sinon il faut évaluer B et
c'est vrai si B==NULL
(A==NULL)||(B==NULL) est vrai dans les mêmes conditions. Donc les
deux formes sont bien équivalentes sous l'évaluation paresseuse.
Oui c'est la loi de de Morgan :
!(a&&b) == (!a)||(!b)
!(a||b) == (!a)&&(!b)
Comme quoi manipuler ce genre d'expression en faisant attention aux
effets de bord est loin d'être trivial.
On 24 Apr 2004 12:19:32 GMT Cyrille Szymanski wrote:
On 2004-04-24, Michel Talon wrote:
Michel Talon wrote:
Ca ne fait pas exactement la même chose que le machin initial. Le machin initial avait un &&, avec l'évaluation paresseuse le premier échec suffisait. Le tien a un || ce qui nécessite dans tous les> cas les deux évaluations.
Non, je ferais mieux de ne pas poster le matin! !A && !B est vrai dés que A==NULL, sinon il faut évaluer B et c'est vrai si B==NULL
(A==NULL)||(B==NULL) est vrai dans les mêmes conditions. Donc les deux formes sont bien équivalentes sous l'évaluation paresseuse.
Oui c'est la loi de de Morgan : !(a&&b) == (!a)||(!b) !(a||b) == (!a)&&(!b)
Comme quoi manipuler ce genre d'expression en faisant attention aux effets de bord est loin d'être trivial.
Ce qui tombe pile poil dans mon discours.
mips
Miod Vallat
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pour être honnête.
c'est sûr que sur un terminal vt100, ça prend du coup plus de 10% de l'espace d'affichage vertical T.T
Exactement. C'est une vérité générale : plus le code occupe d'espace verticalement, plus il est bogué.
C'est pourtant chose manifeste : la réécriture en deux tests occupe au
moins une ligne de plus, sauf à l'écrire dans un style trop dense pour
être honnête.
c'est sûr que sur un terminal vt100, ça prend du coup plus de 10% de
l'espace d'affichage vertical T.T
Exactement. C'est une vérité générale : plus le code occupe d'espace
verticalement, plus il est bogué.
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pour être honnête.
c'est sûr que sur un terminal vt100, ça prend du coup plus de 10% de l'espace d'affichage vertical T.T
Exactement. C'est une vérité générale : plus le code occupe d'espace verticalement, plus il est bogué.
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage. C'est encore plus marque en shell, mais les constructions du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) { return CA_N_A_PAS_MARCHE; }
c'est extremement frequent et naturel comme logique.
Tiens un elitiste :)
Non, je maintiens ce que je dis. C'est juste une semantique `goal-directed' des tests logiques. C'est une aberration de ne pas l'avoir dans les langages imperatifs et meme ailleurs.
Faisons un tour d'horizon: - Pascal ne l'a pas. C'est *hyper-chiant*. Ca empeche de s'en servir dans son role naturel de garde: if (i < borne_sup && tab[i] != 0) plante en Pascal. - C'est le moteur d'un langage comme Icon, ou comme Prolog. Dans Icon, on a des expressions qui peuvent renvoyer plusieurs resultats, avec un & et un | qui sont naturellement goal-directed. J'aime beaucoup pouvoir y ecrire: if (i|j) = 0 then. Ce qui est helas complique dans d'autres langages. L'analogie avec: PourFaireCa :- FaireCeci, FaireCela. PourFaireCa :- OuBienFaireCetAutreTruc. du prolog est totalement evidente. - en shell, c'est super frequent de passer par plusieurs alternatives, modele, if !cmd_vachement_importante; then ecrire_sur_la_console_de_root || { envoyer_un_mail_a_root && ecrire_sur_la_console_de_tous_les_gens_loggues; }
Suffit d'avoir suivi un cours d'introduction a la semantique, ou de logique un peu raisonnable (je dirais qu'en gros, si vous avez entendu parler de bases de Herbrand, vous verrez de quoi je veux parler) pour que la semantique des connecteurs logiques du C paraisse naturelle.
Vouloir la remplacer par quelque chose de plus simple et plus `mathematique' est une erreur. Ca n'a rien de plus mathematique, on sait parfaitement lui donner un sens. Et en plus, on nie completement la structure imperative du langage.
In article <20040424182408.5e253e93.anti@spam.gov>,
mips <mips@cyberspace.org> wrote:
Bof, l'evaluation paresseuse des && et des || en C et en shell est
idiomatique. Quelqu'un qui trebuche sur une ligne de code comme
celle donnee en exergue ne connait tout simplement pas bien le
langage. C'est encore plus marque en shell, mais les constructions
du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) {
return CA_N_A_PAS_MARCHE;
}
c'est extremement frequent et naturel comme logique.
Tiens un elitiste :)
Non, je maintiens ce que je dis. C'est juste une semantique
`goal-directed' des tests logiques. C'est une aberration de ne
pas l'avoir dans les langages imperatifs et meme ailleurs.
Faisons un tour d'horizon:
- Pascal ne l'a pas. C'est *hyper-chiant*. Ca empeche de s'en servir
dans son role naturel de garde: if (i < borne_sup && tab[i] != 0)
plante en Pascal.
- C'est le moteur d'un langage comme Icon, ou comme Prolog.
Dans Icon, on a des expressions qui peuvent renvoyer plusieurs resultats,
avec un & et un | qui sont naturellement goal-directed. J'aime beaucoup
pouvoir y ecrire: if (i|j) = 0 then.
Ce qui est helas complique dans d'autres langages.
L'analogie avec:
PourFaireCa :- FaireCeci, FaireCela.
PourFaireCa :- OuBienFaireCetAutreTruc.
du prolog est totalement evidente.
- en shell, c'est super frequent de passer par plusieurs alternatives,
modele,
if !cmd_vachement_importante; then
ecrire_sur_la_console_de_root || { envoyer_un_mail_a_root &&
ecrire_sur_la_console_de_tous_les_gens_loggues; }
Suffit d'avoir suivi un cours d'introduction a la semantique, ou de logique
un peu raisonnable (je dirais qu'en gros, si vous avez entendu parler de
bases de Herbrand, vous verrez de quoi je veux parler) pour que la
semantique des connecteurs logiques du C paraisse naturelle.
Vouloir la remplacer par quelque chose de plus simple et plus
`mathematique' est une erreur. Ca n'a rien de plus mathematique, on
sait parfaitement lui donner un sens. Et en plus, on nie completement
la structure imperative du langage.
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage. C'est encore plus marque en shell, mais les constructions du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) { return CA_N_A_PAS_MARCHE; }
c'est extremement frequent et naturel comme logique.
Tiens un elitiste :)
Non, je maintiens ce que je dis. C'est juste une semantique `goal-directed' des tests logiques. C'est une aberration de ne pas l'avoir dans les langages imperatifs et meme ailleurs.
Faisons un tour d'horizon: - Pascal ne l'a pas. C'est *hyper-chiant*. Ca empeche de s'en servir dans son role naturel de garde: if (i < borne_sup && tab[i] != 0) plante en Pascal. - C'est le moteur d'un langage comme Icon, ou comme Prolog. Dans Icon, on a des expressions qui peuvent renvoyer plusieurs resultats, avec un & et un | qui sont naturellement goal-directed. J'aime beaucoup pouvoir y ecrire: if (i|j) = 0 then. Ce qui est helas complique dans d'autres langages. L'analogie avec: PourFaireCa :- FaireCeci, FaireCela. PourFaireCa :- OuBienFaireCetAutreTruc. du prolog est totalement evidente. - en shell, c'est super frequent de passer par plusieurs alternatives, modele, if !cmd_vachement_importante; then ecrire_sur_la_console_de_root || { envoyer_un_mail_a_root && ecrire_sur_la_console_de_tous_les_gens_loggues; }
Suffit d'avoir suivi un cours d'introduction a la semantique, ou de logique un peu raisonnable (je dirais qu'en gros, si vous avez entendu parler de bases de Herbrand, vous verrez de quoi je veux parler) pour que la semantique des connecteurs logiques du C paraisse naturelle.
Vouloir la remplacer par quelque chose de plus simple et plus `mathematique' est une erreur. Ca n'a rien de plus mathematique, on sait parfaitement lui donner un sens. Et en plus, on nie completement la structure imperative du langage.
Non, je maintiens ce que je dis. C'est juste une semantique `goal-directed' des tests logiques. C'est une aberration de ne pas l'avoir dans les langages imperatifs et meme ailleurs.
Faisons un tour d'horizon: [COUIC]
Suffit d'avoir suivi un cours d'introduction a la semantique, ou de logique un peu raisonnable (je dirais qu'en gros, si vous avez entendu parler de bases de Herbrand, vous verrez de quoi je veux parler) pour que la semantique des connecteurs logiques du C paraisse naturelle.
Vouloir la remplacer par quelque chose de plus simple et plus `mathematique' est une erreur. Ca n'a rien de plus mathematique, on sait parfaitement lui donner un sens. Et en plus, on nie completement la structure imperative du langage.
Et moi je maintiens que c'est illisible. Je maintiens aussi que c'est reserver la lecture des sources a une pseudo elite, cad des gens qui, par exemple, ont entendu parler de Herbrand.
Pour moi un source lisible est un source qui se comprend du premier coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se meprendre.
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne peux pas avoir mon point de vue.
Non, je maintiens ce que je dis. C'est juste une semantique
`goal-directed' des tests logiques. C'est une aberration de ne
pas l'avoir dans les langages imperatifs et meme ailleurs.
Faisons un tour d'horizon:
[COUIC]
Suffit d'avoir suivi un cours d'introduction a la semantique, ou de
logique un peu raisonnable (je dirais qu'en gros, si vous avez
entendu parler de bases de Herbrand, vous verrez de quoi je veux
parler) pour que la semantique des connecteurs logiques du C
paraisse naturelle.
Vouloir la remplacer par quelque chose de plus simple et plus
`mathematique' est une erreur. Ca n'a rien de plus mathematique, on
sait parfaitement lui donner un sens. Et en plus, on nie
completement la structure imperative du langage.
Et moi je maintiens que c'est illisible. Je maintiens aussi que c'est
reserver la lecture des sources a une pseudo elite, cad des gens qui,
par exemple, ont entendu parler de Herbrand.
Pour moi un source lisible est un source qui se comprend du premier
coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter
qu'un coup d'oeil vu qu'il est si facile de se meprendre.
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne
peux pas avoir mon point de vue.
Non, je maintiens ce que je dis. C'est juste une semantique `goal-directed' des tests logiques. C'est une aberration de ne pas l'avoir dans les langages imperatifs et meme ailleurs.
Faisons un tour d'horizon: [COUIC]
Suffit d'avoir suivi un cours d'introduction a la semantique, ou de logique un peu raisonnable (je dirais qu'en gros, si vous avez entendu parler de bases de Herbrand, vous verrez de quoi je veux parler) pour que la semantique des connecteurs logiques du C paraisse naturelle.
Vouloir la remplacer par quelque chose de plus simple et plus `mathematique' est une erreur. Ca n'a rien de plus mathematique, on sait parfaitement lui donner un sens. Et en plus, on nie completement la structure imperative du langage.
Et moi je maintiens que c'est illisible. Je maintiens aussi que c'est reserver la lecture des sources a une pseudo elite, cad des gens qui, par exemple, ont entendu parler de Herbrand.
Pour moi un source lisible est un source qui se comprend du premier coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se meprendre.
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne peux pas avoir mon point de vue.
mips
espie
In article , mips wrote:
Et moi je maintiens que c'est illisible. Je maintiens aussi que c'est reserver la lecture des sources a une pseudo elite, cad des gens qui, par exemple, ont entendu parler de Herbrand.
Pour moi un source lisible est un source qui se comprend du premier coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se meprendre.
La oui, je vais etre elitiste. Je trouve absurde, aberrant, et dangereux de prendre des etudiants et de pretendre les transformer en programmeurs sans leur donner quelques bases de mathematiques. Pas forcement des trucs hyper-avances, hein, juste un feeling raisonnable de ce qui se passe. Un minimum de formalismes exotiques, histoire de pouvoir ecrire autre chose que pisser du bete code imperatif, et une intuition raisonnable sur les ordres de grandeur et le cout de la recursivite, histoire de savoir quoi et quand optimiser. Ah oui, et des bases de theorie logique, ca sert toujours a eviter de confondre API et implementation. Et un peu de semantique. C'est bien pour faire du code robuste et pas trop troue.
Evidemment, ca supposerait de revoir un peu les programmes d'enseignement pour rendre un minimum ca attractif.
Mais bon, en attendant, on dit aux gens `vous etes pas bon en maths, venez faire de l'informatique'. Et ca pond des programmeurs limités à la pelle...
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne peux pas avoir mon point de vue. Heureusement encore.
In article <20040426142311.6d553509.anti@spam.gov>,
mips <mips@cyberspace.org> wrote:
Et moi je maintiens que c'est illisible. Je maintiens aussi que c'est
reserver la lecture des sources a une pseudo elite, cad des gens qui,
par exemple, ont entendu parler de Herbrand.
Pour moi un source lisible est un source qui se comprend du premier
coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter
qu'un coup d'oeil vu qu'il est si facile de se meprendre.
La oui, je vais etre elitiste. Je trouve absurde, aberrant, et dangereux
de prendre des etudiants et de pretendre les transformer en programmeurs
sans leur donner quelques bases de mathematiques. Pas forcement des trucs
hyper-avances, hein, juste un feeling raisonnable de ce qui se passe.
Un minimum de formalismes exotiques, histoire de pouvoir ecrire autre
chose que pisser du bete code imperatif, et une intuition raisonnable sur
les ordres de grandeur et le cout de la recursivite, histoire de savoir
quoi et quand optimiser. Ah oui, et des bases de theorie logique, ca
sert toujours a eviter de confondre API et implementation. Et un peu de
semantique. C'est bien pour faire du code robuste et pas trop troue.
Evidemment, ca supposerait de revoir un peu les programmes d'enseignement
pour rendre un minimum ca attractif.
Mais bon, en attendant, on dit aux gens `vous etes pas bon en maths, venez
faire de l'informatique'. Et ca pond des programmeurs limités à la
pelle...
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne
peux pas avoir mon point de vue.
Heureusement encore.
Et moi je maintiens que c'est illisible. Je maintiens aussi que c'est reserver la lecture des sources a une pseudo elite, cad des gens qui, par exemple, ont entendu parler de Herbrand.
Pour moi un source lisible est un source qui se comprend du premier coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se meprendre.
La oui, je vais etre elitiste. Je trouve absurde, aberrant, et dangereux de prendre des etudiants et de pretendre les transformer en programmeurs sans leur donner quelques bases de mathematiques. Pas forcement des trucs hyper-avances, hein, juste un feeling raisonnable de ce qui se passe. Un minimum de formalismes exotiques, histoire de pouvoir ecrire autre chose que pisser du bete code imperatif, et une intuition raisonnable sur les ordres de grandeur et le cout de la recursivite, histoire de savoir quoi et quand optimiser. Ah oui, et des bases de theorie logique, ca sert toujours a eviter de confondre API et implementation. Et un peu de semantique. C'est bien pour faire du code robuste et pas trop troue.
Evidemment, ca supposerait de revoir un peu les programmes d'enseignement pour rendre un minimum ca attractif.
Mais bon, en attendant, on dit aux gens `vous etes pas bon en maths, venez faire de l'informatique'. Et ca pond des programmeurs limités à la pelle...
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne peux pas avoir mon point de vue. Heureusement encore.
espie
In article , Erwan David wrote:
Cyrille Szymanski écrivait :
Oui c'est la loi de de Morgan : !(a&&b) == (!a)||(!b) !(a||b) == (!a)&&(!b)
Ça c'est en logique, ça ne tient pas compte des évaluations paresseusses...
Donne-moi un exemple de transformation logique qui ne fonctionne pas en tenant compte des evaluations paresseuses.
Pour autant que je sache, la seule transformation qui ne fonctionne pas, c'est evidemment la commutativite.
In article <87brlhtv19.fsf@bretagne.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Cyrille Szymanski <cns2@cns.invalid> écrivait :
Oui c'est la loi de de Morgan :
!(a&&b) == (!a)||(!b)
!(a||b) == (!a)&&(!b)
Ça c'est en logique, ça ne tient pas compte des évaluations
paresseusses...
Donne-moi un exemple de transformation logique qui ne fonctionne
pas en tenant compte des evaluations paresseuses.
Pour autant que je sache, la seule transformation qui ne fonctionne pas,
c'est evidemment la commutativite.
Oui c'est la loi de de Morgan : !(a&&b) == (!a)||(!b) !(a||b) == (!a)&&(!b)
Ça c'est en logique, ça ne tient pas compte des évaluations paresseusses...
Donne-moi un exemple de transformation logique qui ne fonctionne pas en tenant compte des evaluations paresseuses.
Pour autant que je sache, la seule transformation qui ne fonctionne pas, c'est evidemment la commutativite.
Olivier Brisson
mips schrieb:
Pour moi un source lisible est un source qui se comprend du premier coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se meprendre.
Tu peux avoir du code très bien écrit et ne pas le comprendre car l'algo te dépasse...
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne peux pas avoir mon point de vue.
mips
Olivier --
mips <anti@spam.gov> schrieb:
Pour moi un source lisible est un source qui se comprend du premier
coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter
qu'un coup d'oeil vu qu'il est si facile de se meprendre.
Tu peux avoir du code très bien écrit et ne pas le comprendre car l'algo
te dépasse...
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne
peux pas avoir mon point de vue.
Pour moi un source lisible est un source qui se comprend du premier coup d'oeil. Or ce genre de construction je ne fais pas qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se meprendre.
Tu peux avoir du code très bien écrit et ne pas le comprendre car l'algo te dépasse...
M'enfin bon a priori je bataille pour rien car de toutes facons tu ne peux pas avoir mon point de vue.
La oui, je vais etre elitiste. Je trouve absurde, aberrant, et dangereux de prendre des etudiants et de pretendre les transformer en programmeurs sans leur donner quelques bases de mathematiques. Pas forcement des trucs hyper-avances, hein, juste un feeling raisonnable de ce qui se passe. Un minimum de formalismes exotiques, histoire de pouvoir ecrire autre chose que pisser du bete code imperatif, et une intuition raisonnable sur les ordres de grandeur et le cout de la recursivite, histoire de savoir quoi et quand optimiser. Ah oui, et des bases de theorie logique, ca sert toujours a eviter de confondre API et implementation. Et un peu de semantique. C'est bien pour faire du code robuste et pas trop troue.
Evidemment, ca supposerait de revoir un peu les programmes d'enseignement pour rendre un minimum ca attractif.
La oui tu est clairement elitiste. Tu fermes carrement la porte au nez aux personnes qui n'ont pas fait d'etudes.
Pourtant en pratique je vois des autodidactes qui se demerdent beaucoup mieux que certains diplomes.
La oui, je vais etre elitiste. Je trouve absurde, aberrant, et
dangereux de prendre des etudiants et de pretendre les transformer
en programmeurs sans leur donner quelques bases de mathematiques.
Pas forcement des trucs hyper-avances, hein, juste un feeling
raisonnable de ce qui se passe. Un minimum de formalismes exotiques,
histoire de pouvoir ecrire autre chose que pisser du bete code
imperatif, et une intuition raisonnable sur les ordres de grandeur
et le cout de la recursivite, histoire de savoir quoi et quand
optimiser. Ah oui, et des bases de theorie logique, ca sert toujours
a eviter de confondre API et implementation. Et un peu de
semantique. C'est bien pour faire du code robuste et pas trop troue.
Evidemment, ca supposerait de revoir un peu les programmes
d'enseignement pour rendre un minimum ca attractif.
La oui tu est clairement elitiste. Tu fermes carrement la porte au nez
aux personnes qui n'ont pas fait d'etudes.
Pourtant en pratique je vois des autodidactes qui se demerdent
beaucoup mieux que certains diplomes.
La oui, je vais etre elitiste. Je trouve absurde, aberrant, et dangereux de prendre des etudiants et de pretendre les transformer en programmeurs sans leur donner quelques bases de mathematiques. Pas forcement des trucs hyper-avances, hein, juste un feeling raisonnable de ce qui se passe. Un minimum de formalismes exotiques, histoire de pouvoir ecrire autre chose que pisser du bete code imperatif, et une intuition raisonnable sur les ordres de grandeur et le cout de la recursivite, histoire de savoir quoi et quand optimiser. Ah oui, et des bases de theorie logique, ca sert toujours a eviter de confondre API et implementation. Et un peu de semantique. C'est bien pour faire du code robuste et pas trop troue.
Evidemment, ca supposerait de revoir un peu les programmes d'enseignement pour rendre un minimum ca attractif.
La oui tu est clairement elitiste. Tu fermes carrement la porte au nez aux personnes qui n'ont pas fait d'etudes.
Pourtant en pratique je vois des autodidactes qui se demerdent beaucoup mieux que certains diplomes.
Enfin bref ...
mips
Miod Vallat
La oui tu est clairement elitiste. Tu fermes carrement la porte au nez aux personnes qui n'ont pas fait d'etudes.
Bah, faudrait voir à ne pas éxagérer non plus. J'ai appris, grâce à Marc, l'existence de monsieur Herbrand cet après-midi, et je ne suis pas sûr de comprendre ses travaux; mais connaître la priorité des opérateurs et l'ordre des évaluations, ça me semble un b.a.ba de programmation, quel que soit le langage.
Et quoi que tu dises, sur ce point, le langage C ne se classe pas la catégorie des langages fournis avec planche savonnée au savon noir.
La oui tu est clairement elitiste. Tu fermes carrement la porte au nez
aux personnes qui n'ont pas fait d'etudes.
Bah, faudrait voir à ne pas éxagérer non plus. J'ai appris, grâce à
Marc, l'existence de monsieur Herbrand cet après-midi, et je ne suis pas
sûr de comprendre ses travaux; mais connaître la priorité des opérateurs
et l'ordre des évaluations, ça me semble un b.a.ba de programmation,
quel que soit le langage.
Et quoi que tu dises, sur ce point, le langage C ne se classe pas la
catégorie des langages fournis avec planche savonnée au savon noir.
La oui tu est clairement elitiste. Tu fermes carrement la porte au nez aux personnes qui n'ont pas fait d'etudes.
Bah, faudrait voir à ne pas éxagérer non plus. J'ai appris, grâce à Marc, l'existence de monsieur Herbrand cet après-midi, et je ne suis pas sûr de comprendre ses travaux; mais connaître la priorité des opérateurs et l'ordre des évaluations, ça me semble un b.a.ba de programmation, quel que soit le langage.
Et quoi que tu dises, sur ce point, le langage C ne se classe pas la catégorie des langages fournis avec planche savonnée au savon noir.
