Pascal06 a écrit :On 25 août, 04:31, Stephane Legras-Decussy wrote:Le 24/08/2012 22:19, Tonton Th a crit :Qui contient un certain nombre d'approximations assez douteuses...
c'est mieux que d' tre d gout et d'abandonner.
quand on est l'aise on cherche les erreurs en comparant
avec le K&R ...
Bonjour,
je suis entièrement d'accord avec toi. Je préfère m'y remettre
doucement, plutôt que d'être encore une fois rebuté. Je n'ai pas envie
d'être un puriste non plus !
Déjà qu'à la base je ne comprends l'utilité de ces satanés ";" en fin
de ligne ! On est plus en 1960 !
Justement, c'est ce qui permet de ne pas se prendre la tête avec des
ambiguïtés. Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
En C, on met un ; à la fin de chaque instruction (et non en fin de ligne
comme tu le dis. Ce n'est pas la même chose !) sans se poser de question
et c'est bien mieux ainsi. Il y a déjà assez de pièges dans le langage
comme cela (avec les if (a=b) au lieu de if (a==b), par exemple, ou la
fameuse équivalence pointeur/tableau qui a obligé à inventer le delete
[] en C++).
Le sommet c'est quand même les espaces autorisés dans les mots clés en
Fortran mais, à l'époque (en 1953-54), la théorie des automates et des
langages n'était pas encore bien développée.
Pascal06 a écrit :
On 25 août, 04:31, Stephane Legras-Decussy <ad...@facebook.com> wrote:
Le 24/08/2012 22:19, Tonton Th a crit :
Qui contient un certain nombre d'approximations assez douteuses...
c'est mieux que d' tre d gout et d'abandonner.
quand on est l'aise on cherche les erreurs en comparant
avec le K&R ...
Bonjour,
je suis entièrement d'accord avec toi. Je préfère m'y remettre
doucement, plutôt que d'être encore une fois rebuté. Je n'ai pas envie
d'être un puriste non plus !
Déjà qu'à la base je ne comprends l'utilité de ces satanés ";" en fin
de ligne ! On est plus en 1960 !
Justement, c'est ce qui permet de ne pas se prendre la tête avec des
ambiguïtés. Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
En C, on met un ; à la fin de chaque instruction (et non en fin de ligne
comme tu le dis. Ce n'est pas la même chose !) sans se poser de question
et c'est bien mieux ainsi. Il y a déjà assez de pièges dans le langage
comme cela (avec les if (a=b) au lieu de if (a==b), par exemple, ou la
fameuse équivalence pointeur/tableau qui a obligé à inventer le delete
[] en C++).
Le sommet c'est quand même les espaces autorisés dans les mots clés en
Fortran mais, à l'époque (en 1953-54), la théorie des automates et des
langages n'était pas encore bien développée.
Pascal06 a écrit :On 25 août, 04:31, Stephane Legras-Decussy wrote:Le 24/08/2012 22:19, Tonton Th a crit :Qui contient un certain nombre d'approximations assez douteuses...
c'est mieux que d' tre d gout et d'abandonner.
quand on est l'aise on cherche les erreurs en comparant
avec le K&R ...
Bonjour,
je suis entièrement d'accord avec toi. Je préfère m'y remettre
doucement, plutôt que d'être encore une fois rebuté. Je n'ai pas envie
d'être un puriste non plus !
Déjà qu'à la base je ne comprends l'utilité de ces satanés ";" en fin
de ligne ! On est plus en 1960 !
Justement, c'est ce qui permet de ne pas se prendre la tête avec des
ambiguïtés. Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
En C, on met un ; à la fin de chaque instruction (et non en fin de ligne
comme tu le dis. Ce n'est pas la même chose !) sans se poser de question
et c'est bien mieux ainsi. Il y a déjà assez de pièges dans le langage
comme cela (avec les if (a=b) au lieu de if (a==b), par exemple, ou la
fameuse équivalence pointeur/tableau qui a obligé à inventer le delete
[] en C++).
Le sommet c'est quand même les espaces autorisés dans les mots clés en
Fortran mais, à l'époque (en 1953-54), la théorie des automates et des
langages n'était pas encore bien développée.
On 08/24/2012 11:25 PM, Pascal06 wrote:On Aug 24, 8:56 pm, Stephane Legras-Decussy
wrote:Le 24/08/2012 09:31, a crit :
alors si d ja confront au C tu as t rebut , je ne conseille
pas le K&R qui est exact, rigoureux et ... rebutant.
Exact et rigoureux sont loin d'être des adjectifs... rebutants pour un
tel langage.il faut un bouquin d'approche sympathique pour ne pas tre
d gout et pour *s'amuser*
Il ne me semble pas que l'OP ait beaucoup envie de s'amuser. Ça tombe
bien d'ailleurs, les compilateurs C manquent cruellement d'humour.une fois qu'on a exp riment quelque chose et vu que a marchait, on
peut relire ce qu'en dit le K&R pour avoir les subtilit s.
en fait pas besoin de bouquin, ce cours en ligne est excellent et le
taux d'erreur est tr s bon ...
http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c...
en orient microcontroleur, ce qui est mon cr neau aussi, je te
conseille les controleurs Atmel et l'outil de dev fourni ...
Bonsoir,
Merci pour ce conseil...
Mouais, bon.J'ai effectivement regardé le site du "0", j'ai meme imprimé le
bouquin...
Diantre, au prix des cartouches d'encre !
Sinon, heu... un tutoriel, ce n'est pas un bouquin.Mais je me suis presque fait incendié (sur fr.sci.electronique) en
parlant de ça !
D'ou ma question ici...
Huhuhu ! J'ai vu le troll venir dès ton tout premier post, mais c'est
pas ta faute. Le sujet du "bouquin pour apprendre le C" est assez
fameux. Il revient à peu près... une fois par an. Et à chaque fois c'est
la même rengaine, à savoir :
1. L'indétrônable et incontournable K&R. Peu pédagogique et patati et
patata, c'est vrai. Mais une très bonne référence (autrement dit : pas
blindé d'erreurs). Cela tient en grande partie au fait que les auteurs
originaux sont aussi les auteurs du langage, et aussi que ce bouquin a
été pendant plus de 10 ans... la seule et unique référence (il précède
la première normalisation d'autant). Ces 2 arguments ne sont toutefois
pas une raison suffisante pour en faire un bon livre pédagogique. Créer
des langages, écrire des bouquins et enseigner sont 3 activités bien
différentes.
Un autre problème du K&R, c'est que malgré les ré-éditions, il n'est pas
très à jour avec les dernières normes et pas du tout avec la dernière en
date, à savoir celle de 2011 (C11, mais à ce niveau, je serais étonné
qu'il existe un bouquin quelconque). La précédente norme date de 1999
(C99) et même celle-là, il me semble que la dernière édition du K&R
français (2004) n'en parle pas (quant au K&R anglais, la dernière
édition date de... 1988 ! autrement dit, la dernière édition anglophone
date d'avant la première normalisation).
Est-ce que c'est si grave ? Pas vraiment en fait. La norme ne change
plus tellement au point de rendre le K&R obsolète. Le monde de C évolue
assez lentement (une révision de la norme tous les 10 ans ~). La norme
C11 est en fait un bébé tout beau tout neuf et encore assez peu
exploitée. Les programmeurs C ne sont pas du genre sur les
starting-blocks mais plutôt dans les gradins à regarder les plus
téméraires se casser la gueule avec un certain amusement (faut bien
qu'ils rigolent un peu parfois). Ils sont peu enclins à adopter les
nouveautés tant qu'elles n'ont pas vraiment fait leur preuves. Ce genre
de choses prend du temps.
Sinon, il y a aussi le "Harbison & Steele" assez souvent cité, mais je
ne le connais pas. Cependant, je ne me souviens pas avoir lu de
critiques négatives à son sujet, c'est sûrement qu'il doit valoir
quelque-chose. On dit qu'il est plus à jour que le K&R vis à vis des
dernières "nouveautés" de C (ce qui n'est pas un exploit vous me direz).
2. Le site du zéro (ou n'importe quel autre
"tuto-kikoo-lol-apprend-C-en-3-minutes").
Pour que tu comprennes bien la situation (rapport aux émeutes que tu
déclenches en en parlant). Chaque année on y a droit au site du zéro !
Oui, même ici sur les terres sacrées de f.c.l.c. Donc on ne peut pas y
échapper, quoiqu'on en dise, qu'on le descende, qu'on l'allume, qu'on
l'atomise, qu'on l'éjecte sur Mars à coup de pied au cul... il y a
toujours, *TOUJOURS* un martien qui débarque pour nous le revendre. Et
dans la foulée, un élu local intervient, en substance : "c'est très
mauvais et blablabla". Systématique.
Il suffit d'ailleurs de taper "language C" dans le moteur que tout le
monde connaît pour comprendre que c'est de toute évidence LA référence
francophone pour s'initier au C sur le réseau de réseaux.
L'explication des émeutes, c'est que s'il existe un langage qui n'est
pas fait pour les débutants, c'est bien C. Non pas qu'il soit si
difficile à aborder, mais il demande en principe des années pour être
maîtrisé. C'est un langage système, il t'ouvre toutes les portes y
compris celle de la pièce avec un gros bouton rouge.
D'autre part, le temps passant et les paradigmes de programmation ayant
quelque peu évolué, on peut dire que certaines pratiques courantes en C
sont assez passées de mode. Sa bibliothèque standard expose encore des
fonctions qui auraient dû être reléguées aux oubliettes depuis la nuit
des temps (voire n'auraient jamais dû exister, comme le machiavélique et
néanmoins si séduisant gets(), pour ne citer que lui). C a aussi une
fâcheuse tendance à donner de mauvaises habitudes un peu gênantes quand
on passe à d'autres langages (et pas que C++).
Tout ceci est totalement incompatible avec le concept de tutoriel qui
fait figure de chien dans un jeu de quilles. Voilà pour les rires,
quolibets, voire émeutes d'experts. Ici, comme les rares endroits où
l'on peut trouver des experts en C, tu auras à peu près le même genre de
réactions : "Hé ho ! On parle de l'illustre et infâme C bordel ! Faut
arrêter la déconne là hein !". Bon, ils seront moins grossiers, mais le
coeur y sera. C'est un sujet de choix pour des enfilades interminables
(et non-terminées). D'ailleurs, comme tu peux le constater, ça a déjà
commencé (mais c'est bien, ça met un peu d'ambiance dans ces lieux
poussiéreux).
Mon avis (tout à fait personnel), c'est qu'au fond, on a beau être un
vieux de la vieille du C pour qui les tutoriels sur ce langage ne sont
rien d'autre que des attrapes nigauds d'une médiocrité sans nom, ce
tutoriel là n'est pas aussi mauvais que ceux qui ne prennent pas
toujours la peine d'y jeter leur oeil averti veulent bien le faire
croire. Certes, un puriste y trouvera toujours quelque-chose à redire,
mais il ne s'y attardera guère non plus (étant à priori expert, il n'a
pas besoin de tutoriel, lui). Cependant il faut rester honnête : il y a
plusieurs tutoriels en français sur le net pour le C, aussi hérétique
que ce concept puisse paraître. Et celui-là est peut être bien le
meilleur d'entre tous. Car si les grands-sages-experts ici bas le
descendront avec une facilité déconcertante, dans les faits ils auront
beaucoup de difficultés à te proposer mieux.
Bref, plus on connaît le C, plus l'idée de tutoriel est contre-nature.
3. Le site d'Emmanuel (http://www.bien-programmer.fr/index.php). Ce
n'est pas un vulgaire tutoriel et on y apprend pas à faire des trucs
rigolos dès le premier programme, certes. Ça manque cruellement
d'empathie pour le pauvre débutant, certes (c'est pas dans la nature du
personnage ;)). Mais après tout on est pas là pour rigoler. C'est
surtout assez formel, précis et *correct* (ce qui est rare) et plein de
bon conseils pour éviter les mauvaises habitudes. Et il y a quand-même
une initiation. Et en français.
Petit message pour Emmanuel : tu devrais peut-être lancer un appel à
cotisations pour le référencement de ton site... enfin bon, vu les news,
peut-être que tu t'en fous et que tu préfères sévir sur developpez.com
jusqu'à nouvel ordre :)
4. f.c.l.c : le forum ici présent. C'est vrai qu'il a l'air mort le
bled, mais c'est un leurre pour tromper l'ennemi. Tous les grabataires
francophones experts du C sont là, tapis dans l'ombre, prêts à bondir
sur le premier semi-débutant qui aurait l'audace de répondre une
connerie à la moindre question (et même ceux qui répondent bien de toute
façons, ils trouvent toujours une bonne raison de contredire un truc,
aussi sûr qu'un bon vieux compilo qui te les brise pour un bête
point-virgule oublié). Ne *jamais* hésiter à poser des questions de
parfait débutant ici. Même souvent... ça risques pas de saouler, au
contraire, ça mettra un peu de vie dans cette pension de retraite !
5. Pour finir, les plus mauvais tutoriels qui soient pour s'initier au
C, les normes ISO (enfin les derniers drafts du pauvre plutôt) :
C99
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
C11
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Un bon moyen pour dégouter le petit frère qui te fait de l'ombre.
On 08/24/2012 11:25 PM, Pascal06 wrote:
On Aug 24, 8:56 pm, Stephane Legras-Decussy<ad...@facebook.com>
wrote:
Le 24/08/2012 09:31, pascal.pellizz...@gmail.com a crit :
alors si d ja confront au C tu as t rebut , je ne conseille
pas le K&R qui est exact, rigoureux et ... rebutant.
Exact et rigoureux sont loin d'être des adjectifs... rebutants pour un
tel langage.
il faut un bouquin d'approche sympathique pour ne pas tre
d gout et pour *s'amuser*
Il ne me semble pas que l'OP ait beaucoup envie de s'amuser. Ça tombe
bien d'ailleurs, les compilateurs C manquent cruellement d'humour.
une fois qu'on a exp riment quelque chose et vu que a marchait, on
peut relire ce qu'en dit le K&R pour avoir les subtilit s.
en fait pas besoin de bouquin, ce cours en ligne est excellent et le
taux d'erreur est tr s bon ...
http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c...
en orient microcontroleur, ce qui est mon cr neau aussi, je te
conseille les controleurs Atmel et l'outil de dev fourni ...
Bonsoir,
Merci pour ce conseil...
Mouais, bon.
J'ai effectivement regardé le site du "0", j'ai meme imprimé le
bouquin...
Diantre, au prix des cartouches d'encre !
Sinon, heu... un tutoriel, ce n'est pas un bouquin.
Mais je me suis presque fait incendié (sur fr.sci.electronique) en
parlant de ça !
D'ou ma question ici...
Huhuhu ! J'ai vu le troll venir dès ton tout premier post, mais c'est
pas ta faute. Le sujet du "bouquin pour apprendre le C" est assez
fameux. Il revient à peu près... une fois par an. Et à chaque fois c'est
la même rengaine, à savoir :
1. L'indétrônable et incontournable K&R. Peu pédagogique et patati et
patata, c'est vrai. Mais une très bonne référence (autrement dit : pas
blindé d'erreurs). Cela tient en grande partie au fait que les auteurs
originaux sont aussi les auteurs du langage, et aussi que ce bouquin a
été pendant plus de 10 ans... la seule et unique référence (il précède
la première normalisation d'autant). Ces 2 arguments ne sont toutefois
pas une raison suffisante pour en faire un bon livre pédagogique. Créer
des langages, écrire des bouquins et enseigner sont 3 activités bien
différentes.
Un autre problème du K&R, c'est que malgré les ré-éditions, il n'est pas
très à jour avec les dernières normes et pas du tout avec la dernière en
date, à savoir celle de 2011 (C11, mais à ce niveau, je serais étonné
qu'il existe un bouquin quelconque). La précédente norme date de 1999
(C99) et même celle-là, il me semble que la dernière édition du K&R
français (2004) n'en parle pas (quant au K&R anglais, la dernière
édition date de... 1988 ! autrement dit, la dernière édition anglophone
date d'avant la première normalisation).
Est-ce que c'est si grave ? Pas vraiment en fait. La norme ne change
plus tellement au point de rendre le K&R obsolète. Le monde de C évolue
assez lentement (une révision de la norme tous les 10 ans ~). La norme
C11 est en fait un bébé tout beau tout neuf et encore assez peu
exploitée. Les programmeurs C ne sont pas du genre sur les
starting-blocks mais plutôt dans les gradins à regarder les plus
téméraires se casser la gueule avec un certain amusement (faut bien
qu'ils rigolent un peu parfois). Ils sont peu enclins à adopter les
nouveautés tant qu'elles n'ont pas vraiment fait leur preuves. Ce genre
de choses prend du temps.
Sinon, il y a aussi le "Harbison & Steele" assez souvent cité, mais je
ne le connais pas. Cependant, je ne me souviens pas avoir lu de
critiques négatives à son sujet, c'est sûrement qu'il doit valoir
quelque-chose. On dit qu'il est plus à jour que le K&R vis à vis des
dernières "nouveautés" de C (ce qui n'est pas un exploit vous me direz).
2. Le site du zéro (ou n'importe quel autre
"tuto-kikoo-lol-apprend-C-en-3-minutes").
Pour que tu comprennes bien la situation (rapport aux émeutes que tu
déclenches en en parlant). Chaque année on y a droit au site du zéro !
Oui, même ici sur les terres sacrées de f.c.l.c. Donc on ne peut pas y
échapper, quoiqu'on en dise, qu'on le descende, qu'on l'allume, qu'on
l'atomise, qu'on l'éjecte sur Mars à coup de pied au cul... il y a
toujours, *TOUJOURS* un martien qui débarque pour nous le revendre. Et
dans la foulée, un élu local intervient, en substance : "c'est très
mauvais et blablabla". Systématique.
Il suffit d'ailleurs de taper "language C" dans le moteur que tout le
monde connaît pour comprendre que c'est de toute évidence LA référence
francophone pour s'initier au C sur le réseau de réseaux.
L'explication des émeutes, c'est que s'il existe un langage qui n'est
pas fait pour les débutants, c'est bien C. Non pas qu'il soit si
difficile à aborder, mais il demande en principe des années pour être
maîtrisé. C'est un langage système, il t'ouvre toutes les portes y
compris celle de la pièce avec un gros bouton rouge.
D'autre part, le temps passant et les paradigmes de programmation ayant
quelque peu évolué, on peut dire que certaines pratiques courantes en C
sont assez passées de mode. Sa bibliothèque standard expose encore des
fonctions qui auraient dû être reléguées aux oubliettes depuis la nuit
des temps (voire n'auraient jamais dû exister, comme le machiavélique et
néanmoins si séduisant gets(), pour ne citer que lui). C a aussi une
fâcheuse tendance à donner de mauvaises habitudes un peu gênantes quand
on passe à d'autres langages (et pas que C++).
Tout ceci est totalement incompatible avec le concept de tutoriel qui
fait figure de chien dans un jeu de quilles. Voilà pour les rires,
quolibets, voire émeutes d'experts. Ici, comme les rares endroits où
l'on peut trouver des experts en C, tu auras à peu près le même genre de
réactions : "Hé ho ! On parle de l'illustre et infâme C bordel ! Faut
arrêter la déconne là hein !". Bon, ils seront moins grossiers, mais le
coeur y sera. C'est un sujet de choix pour des enfilades interminables
(et non-terminées). D'ailleurs, comme tu peux le constater, ça a déjà
commencé (mais c'est bien, ça met un peu d'ambiance dans ces lieux
poussiéreux).
Mon avis (tout à fait personnel), c'est qu'au fond, on a beau être un
vieux de la vieille du C pour qui les tutoriels sur ce langage ne sont
rien d'autre que des attrapes nigauds d'une médiocrité sans nom, ce
tutoriel là n'est pas aussi mauvais que ceux qui ne prennent pas
toujours la peine d'y jeter leur oeil averti veulent bien le faire
croire. Certes, un puriste y trouvera toujours quelque-chose à redire,
mais il ne s'y attardera guère non plus (étant à priori expert, il n'a
pas besoin de tutoriel, lui). Cependant il faut rester honnête : il y a
plusieurs tutoriels en français sur le net pour le C, aussi hérétique
que ce concept puisse paraître. Et celui-là est peut être bien le
meilleur d'entre tous. Car si les grands-sages-experts ici bas le
descendront avec une facilité déconcertante, dans les faits ils auront
beaucoup de difficultés à te proposer mieux.
Bref, plus on connaît le C, plus l'idée de tutoriel est contre-nature.
3. Le site d'Emmanuel (http://www.bien-programmer.fr/index.php). Ce
n'est pas un vulgaire tutoriel et on y apprend pas à faire des trucs
rigolos dès le premier programme, certes. Ça manque cruellement
d'empathie pour le pauvre débutant, certes (c'est pas dans la nature du
personnage ;)). Mais après tout on est pas là pour rigoler. C'est
surtout assez formel, précis et *correct* (ce qui est rare) et plein de
bon conseils pour éviter les mauvaises habitudes. Et il y a quand-même
une initiation. Et en français.
Petit message pour Emmanuel : tu devrais peut-être lancer un appel à
cotisations pour le référencement de ton site... enfin bon, vu les news,
peut-être que tu t'en fous et que tu préfères sévir sur developpez.com
jusqu'à nouvel ordre :)
4. f.c.l.c : le forum ici présent. C'est vrai qu'il a l'air mort le
bled, mais c'est un leurre pour tromper l'ennemi. Tous les grabataires
francophones experts du C sont là, tapis dans l'ombre, prêts à bondir
sur le premier semi-débutant qui aurait l'audace de répondre une
connerie à la moindre question (et même ceux qui répondent bien de toute
façons, ils trouvent toujours une bonne raison de contredire un truc,
aussi sûr qu'un bon vieux compilo qui te les brise pour un bête
point-virgule oublié). Ne *jamais* hésiter à poser des questions de
parfait débutant ici. Même souvent... ça risques pas de saouler, au
contraire, ça mettra un peu de vie dans cette pension de retraite !
5. Pour finir, les plus mauvais tutoriels qui soient pour s'initier au
C, les normes ISO (enfin les derniers drafts du pauvre plutôt) :
C99
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
C11
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Un bon moyen pour dégouter le petit frère qui te fait de l'ombre.
On 08/24/2012 11:25 PM, Pascal06 wrote:On Aug 24, 8:56 pm, Stephane Legras-Decussy
wrote:Le 24/08/2012 09:31, a crit :
alors si d ja confront au C tu as t rebut , je ne conseille
pas le K&R qui est exact, rigoureux et ... rebutant.
Exact et rigoureux sont loin d'être des adjectifs... rebutants pour un
tel langage.il faut un bouquin d'approche sympathique pour ne pas tre
d gout et pour *s'amuser*
Il ne me semble pas que l'OP ait beaucoup envie de s'amuser. Ça tombe
bien d'ailleurs, les compilateurs C manquent cruellement d'humour.une fois qu'on a exp riment quelque chose et vu que a marchait, on
peut relire ce qu'en dit le K&R pour avoir les subtilit s.
en fait pas besoin de bouquin, ce cours en ligne est excellent et le
taux d'erreur est tr s bon ...
http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c...
en orient microcontroleur, ce qui est mon cr neau aussi, je te
conseille les controleurs Atmel et l'outil de dev fourni ...
Bonsoir,
Merci pour ce conseil...
Mouais, bon.J'ai effectivement regardé le site du "0", j'ai meme imprimé le
bouquin...
Diantre, au prix des cartouches d'encre !
Sinon, heu... un tutoriel, ce n'est pas un bouquin.Mais je me suis presque fait incendié (sur fr.sci.electronique) en
parlant de ça !
D'ou ma question ici...
Huhuhu ! J'ai vu le troll venir dès ton tout premier post, mais c'est
pas ta faute. Le sujet du "bouquin pour apprendre le C" est assez
fameux. Il revient à peu près... une fois par an. Et à chaque fois c'est
la même rengaine, à savoir :
1. L'indétrônable et incontournable K&R. Peu pédagogique et patati et
patata, c'est vrai. Mais une très bonne référence (autrement dit : pas
blindé d'erreurs). Cela tient en grande partie au fait que les auteurs
originaux sont aussi les auteurs du langage, et aussi que ce bouquin a
été pendant plus de 10 ans... la seule et unique référence (il précède
la première normalisation d'autant). Ces 2 arguments ne sont toutefois
pas une raison suffisante pour en faire un bon livre pédagogique. Créer
des langages, écrire des bouquins et enseigner sont 3 activités bien
différentes.
Un autre problème du K&R, c'est que malgré les ré-éditions, il n'est pas
très à jour avec les dernières normes et pas du tout avec la dernière en
date, à savoir celle de 2011 (C11, mais à ce niveau, je serais étonné
qu'il existe un bouquin quelconque). La précédente norme date de 1999
(C99) et même celle-là, il me semble que la dernière édition du K&R
français (2004) n'en parle pas (quant au K&R anglais, la dernière
édition date de... 1988 ! autrement dit, la dernière édition anglophone
date d'avant la première normalisation).
Est-ce que c'est si grave ? Pas vraiment en fait. La norme ne change
plus tellement au point de rendre le K&R obsolète. Le monde de C évolue
assez lentement (une révision de la norme tous les 10 ans ~). La norme
C11 est en fait un bébé tout beau tout neuf et encore assez peu
exploitée. Les programmeurs C ne sont pas du genre sur les
starting-blocks mais plutôt dans les gradins à regarder les plus
téméraires se casser la gueule avec un certain amusement (faut bien
qu'ils rigolent un peu parfois). Ils sont peu enclins à adopter les
nouveautés tant qu'elles n'ont pas vraiment fait leur preuves. Ce genre
de choses prend du temps.
Sinon, il y a aussi le "Harbison & Steele" assez souvent cité, mais je
ne le connais pas. Cependant, je ne me souviens pas avoir lu de
critiques négatives à son sujet, c'est sûrement qu'il doit valoir
quelque-chose. On dit qu'il est plus à jour que le K&R vis à vis des
dernières "nouveautés" de C (ce qui n'est pas un exploit vous me direz).
2. Le site du zéro (ou n'importe quel autre
"tuto-kikoo-lol-apprend-C-en-3-minutes").
Pour que tu comprennes bien la situation (rapport aux émeutes que tu
déclenches en en parlant). Chaque année on y a droit au site du zéro !
Oui, même ici sur les terres sacrées de f.c.l.c. Donc on ne peut pas y
échapper, quoiqu'on en dise, qu'on le descende, qu'on l'allume, qu'on
l'atomise, qu'on l'éjecte sur Mars à coup de pied au cul... il y a
toujours, *TOUJOURS* un martien qui débarque pour nous le revendre. Et
dans la foulée, un élu local intervient, en substance : "c'est très
mauvais et blablabla". Systématique.
Il suffit d'ailleurs de taper "language C" dans le moteur que tout le
monde connaît pour comprendre que c'est de toute évidence LA référence
francophone pour s'initier au C sur le réseau de réseaux.
L'explication des émeutes, c'est que s'il existe un langage qui n'est
pas fait pour les débutants, c'est bien C. Non pas qu'il soit si
difficile à aborder, mais il demande en principe des années pour être
maîtrisé. C'est un langage système, il t'ouvre toutes les portes y
compris celle de la pièce avec un gros bouton rouge.
D'autre part, le temps passant et les paradigmes de programmation ayant
quelque peu évolué, on peut dire que certaines pratiques courantes en C
sont assez passées de mode. Sa bibliothèque standard expose encore des
fonctions qui auraient dû être reléguées aux oubliettes depuis la nuit
des temps (voire n'auraient jamais dû exister, comme le machiavélique et
néanmoins si séduisant gets(), pour ne citer que lui). C a aussi une
fâcheuse tendance à donner de mauvaises habitudes un peu gênantes quand
on passe à d'autres langages (et pas que C++).
Tout ceci est totalement incompatible avec le concept de tutoriel qui
fait figure de chien dans un jeu de quilles. Voilà pour les rires,
quolibets, voire émeutes d'experts. Ici, comme les rares endroits où
l'on peut trouver des experts en C, tu auras à peu près le même genre de
réactions : "Hé ho ! On parle de l'illustre et infâme C bordel ! Faut
arrêter la déconne là hein !". Bon, ils seront moins grossiers, mais le
coeur y sera. C'est un sujet de choix pour des enfilades interminables
(et non-terminées). D'ailleurs, comme tu peux le constater, ça a déjà
commencé (mais c'est bien, ça met un peu d'ambiance dans ces lieux
poussiéreux).
Mon avis (tout à fait personnel), c'est qu'au fond, on a beau être un
vieux de la vieille du C pour qui les tutoriels sur ce langage ne sont
rien d'autre que des attrapes nigauds d'une médiocrité sans nom, ce
tutoriel là n'est pas aussi mauvais que ceux qui ne prennent pas
toujours la peine d'y jeter leur oeil averti veulent bien le faire
croire. Certes, un puriste y trouvera toujours quelque-chose à redire,
mais il ne s'y attardera guère non plus (étant à priori expert, il n'a
pas besoin de tutoriel, lui). Cependant il faut rester honnête : il y a
plusieurs tutoriels en français sur le net pour le C, aussi hérétique
que ce concept puisse paraître. Et celui-là est peut être bien le
meilleur d'entre tous. Car si les grands-sages-experts ici bas le
descendront avec une facilité déconcertante, dans les faits ils auront
beaucoup de difficultés à te proposer mieux.
Bref, plus on connaît le C, plus l'idée de tutoriel est contre-nature.
3. Le site d'Emmanuel (http://www.bien-programmer.fr/index.php). Ce
n'est pas un vulgaire tutoriel et on y apprend pas à faire des trucs
rigolos dès le premier programme, certes. Ça manque cruellement
d'empathie pour le pauvre débutant, certes (c'est pas dans la nature du
personnage ;)). Mais après tout on est pas là pour rigoler. C'est
surtout assez formel, précis et *correct* (ce qui est rare) et plein de
bon conseils pour éviter les mauvaises habitudes. Et il y a quand-même
une initiation. Et en français.
Petit message pour Emmanuel : tu devrais peut-être lancer un appel à
cotisations pour le référencement de ton site... enfin bon, vu les news,
peut-être que tu t'en fous et que tu préfères sévir sur developpez.com
jusqu'à nouvel ordre :)
4. f.c.l.c : le forum ici présent. C'est vrai qu'il a l'air mort le
bled, mais c'est un leurre pour tromper l'ennemi. Tous les grabataires
francophones experts du C sont là, tapis dans l'ombre, prêts à bondir
sur le premier semi-débutant qui aurait l'audace de répondre une
connerie à la moindre question (et même ceux qui répondent bien de toute
façons, ils trouvent toujours une bonne raison de contredire un truc,
aussi sûr qu'un bon vieux compilo qui te les brise pour un bête
point-virgule oublié). Ne *jamais* hésiter à poser des questions de
parfait débutant ici. Même souvent... ça risques pas de saouler, au
contraire, ça mettra un peu de vie dans cette pension de retraite !
5. Pour finir, les plus mauvais tutoriels qui soient pour s'initier au
C, les normes ISO (enfin les derniers drafts du pauvre plutôt) :
C99
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
C11
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Un bon moyen pour dégouter le petit frère qui te fait de l'ombre.
Pour moi, le meilleur livre sur le langage C est le livre d'Harbison et
Steele : http://www.amazon.com/Reference-Manual-5th-Edition/dp/013089592X
Sinon, il y a, en français, le livre de Philippe Drix :
- http://livre.fnac.com/a1097476/Philippe-Drix-Langage-c-norme-ansi
Pour moi, le meilleur livre sur le langage C est le livre d'Harbison et
Steele : http://www.amazon.com/Reference-Manual-5th-Edition/dp/013089592X
Sinon, il y a, en français, le livre de Philippe Drix :
- http://livre.fnac.com/a1097476/Philippe-Drix-Langage-c-norme-ansi
Pour moi, le meilleur livre sur le langage C est le livre d'Harbison et
Steele : http://www.amazon.com/Reference-Manual-5th-Edition/dp/013089592X
Sinon, il y a, en français, le livre de Philippe Drix :
- http://livre.fnac.com/a1097476/Philippe-Drix-Langage-c-norme-ansi
Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Le 27/08/2012 13:08, Wykaaa a écrit :Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Le 27/08/2012 13:08, Wykaaa a écrit :
Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Le 27/08/2012 13:08, Wykaaa a écrit :Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Richard Delorme a écrit :Le 27/08/2012 13:08, Wykaaa a écrit :Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de délimitation
de blocs par l'indentation de Python, mais je le comprends en tant
qu'opinion ou goût personnel. Or là j'ai l'impression que tu as des faits
à avancer. Aussi je pose la question : En quoi est-ce nuisible à la
qualité du code et contraire aux principes du génie logiciel ?
Parce que l'indentation ne peut être exprimée correctement en BNF
et qu'une simple erreur dans l'indentation peut produire un gros bogue
que et que l'analyseur syntaxique ne peut pas faire tous les contrôles
nécessaires.
Richard Delorme a écrit :
Le 27/08/2012 13:08, Wykaaa a écrit :
Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de délimitation
de blocs par l'indentation de Python, mais je le comprends en tant
qu'opinion ou goût personnel. Or là j'ai l'impression que tu as des faits
à avancer. Aussi je pose la question : En quoi est-ce nuisible à la
qualité du code et contraire aux principes du génie logiciel ?
Parce que l'indentation ne peut être exprimée correctement en BNF
et qu'une simple erreur dans l'indentation peut produire un gros bogue
que et que l'analyseur syntaxique ne peut pas faire tous les contrôles
nécessaires.
Richard Delorme a écrit :Le 27/08/2012 13:08, Wykaaa a écrit :Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de délimitation
de blocs par l'indentation de Python, mais je le comprends en tant
qu'opinion ou goût personnel. Or là j'ai l'impression que tu as des faits
à avancer. Aussi je pose la question : En quoi est-ce nuisible à la
qualité du code et contraire aux principes du génie logiciel ?
Parce que l'indentation ne peut être exprimée correctement en BNF
et qu'une simple erreur dans l'indentation peut produire un gros bogue
que et que l'analyseur syntaxique ne peut pas faire tous les contrôles
nécessaires.
> > Je comprends que l'on puisse ne pas apprécier le principe de
> > délimitation de blocs par l'indentation de Python, mais je le
> > comprends en tant qu'opinion ou goût personnel. Or là j'ai
> > l'impression que tu as des faits à avancer. Aussi je pose la
> > question : En quoi est-ce nuisible à la qualité du code et
> > contraire aux principes du génie logiciel ?
> Parce que l'indentation ne peut être exprimée correctement en BNF
Avoir le lexeur qui génère des symboles indent/outdent me semble une
technique évidente.
> [...] que et que l'analyseur syntaxique ne peut pas faire tous les
> contrôles nécessaires.
A quoi tu penses? (Comparé à un "end if" ou un "end func toto", je
vois quels contrôles supplémentaires sont possibles, c'est comparé
à un "}" que je ne vois pas).
> > Je comprends que l'on puisse ne pas apprécier le principe de
> > délimitation de blocs par l'indentation de Python, mais je le
> > comprends en tant qu'opinion ou goût personnel. Or là j'ai
> > l'impression que tu as des faits à avancer. Aussi je pose la
> > question : En quoi est-ce nuisible à la qualité du code et
> > contraire aux principes du génie logiciel ?
> Parce que l'indentation ne peut être exprimée correctement en BNF
Avoir le lexeur qui génère des symboles indent/outdent me semble une
technique évidente.
> [...] que et que l'analyseur syntaxique ne peut pas faire tous les
> contrôles nécessaires.
A quoi tu penses? (Comparé à un "end if" ou un "end func toto", je
vois quels contrôles supplémentaires sont possibles, c'est comparé
à un "}" que je ne vois pas).
> > Je comprends que l'on puisse ne pas apprécier le principe de
> > délimitation de blocs par l'indentation de Python, mais je le
> > comprends en tant qu'opinion ou goût personnel. Or là j'ai
> > l'impression que tu as des faits à avancer. Aussi je pose la
> > question : En quoi est-ce nuisible à la qualité du code et
> > contraire aux principes du génie logiciel ?
> Parce que l'indentation ne peut être exprimée correctement en BNF
Avoir le lexeur qui génère des symboles indent/outdent me semble une
technique évidente.
> [...] que et que l'analyseur syntaxique ne peut pas faire tous les
> contrôles nécessaires.
A quoi tu penses? (Comparé à un "end if" ou un "end func toto", je
vois quels contrôles supplémentaires sont possibles, c'est comparé
à un "}" que je ne vois pas).
Le 27/08/2012 13:08, Wykaaa a écrit :Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Le 27/08/2012 13:08, Wykaaa a écrit :
Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Le 27/08/2012 13:08, Wykaaa a écrit :Les langages à la syntaxe laxiste ou farfelue (je pense en
particulier à Python et ses délimitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis spécialiste des langages et
des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
contraires aux principes du génie logiciel (software engineering).
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Damien Wyart a écrit :Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le
comprends en tant qu'opinion ou goût personnel. Or là j'ai
l'impression que tu as des faits à avancer. Aussi je pose la
question : En quoi est-ce nuisible à la qualité du code et
contraire aux principes du génie logiciel ?Parce que l'indentation ne peut être exprimée correctement e n BNF
* Jean-Marc Bourguet in fr.comp.lang.c:Avoir le lexeur qui génère des symboles indent/outdent me sem ble une
technique évidente.
C'est en effet ce qui est expliqué ici :
http://docs.python.org/reference/lexical_analysis.html#indentation
On voit bien que ce trait de langage complique inutilement l'analyse et
rend le code, à priori correct, erronné.
Damien Wyart a écrit :
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le
comprends en tant qu'opinion ou goût personnel. Or là j'ai
l'impression que tu as des faits à avancer. Aussi je pose la
question : En quoi est-ce nuisible à la qualité du code et
contraire aux principes du génie logiciel ?
Parce que l'indentation ne peut être exprimée correctement e n BNF
* Jean-Marc Bourguet <jm@bourguet.org> in fr.comp.lang.c:
Avoir le lexeur qui génère des symboles indent/outdent me sem ble une
technique évidente.
C'est en effet ce qui est expliqué ici :
http://docs.python.org/reference/lexical_analysis.html#indentation
On voit bien que ce trait de langage complique inutilement l'analyse et
rend le code, à priori correct, erronné.
Damien Wyart a écrit :Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le
comprends en tant qu'opinion ou goût personnel. Or là j'ai
l'impression que tu as des faits à avancer. Aussi je pose la
question : En quoi est-ce nuisible à la qualité du code et
contraire aux principes du génie logiciel ?Parce que l'indentation ne peut être exprimée correctement e n BNF
* Jean-Marc Bourguet in fr.comp.lang.c:Avoir le lexeur qui génère des symboles indent/outdent me sem ble une
technique évidente.
C'est en effet ce qui est expliqué ici :
http://docs.python.org/reference/lexical_analysis.html#indentation
On voit bien que ce trait de langage complique inutilement l'analyse et
rend le code, à priori correct, erronné.
Le Mon, 27 Aug 2012 21:27:47 +0200,
Richard Delorme écrivait :Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
suite d'espaces et que le résultat est catastrophique.
Le Mon, 27 Aug 2012 21:27:47 +0200,
Richard Delorme <abulmo@nospam.fr> écrivait :
Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
suite d'espaces et que le résultat est catastrophique.
Le Mon, 27 Aug 2012 21:27:47 +0200,
Richard Delorme écrivait :Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?
Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
suite d'espaces et que le résultat est catastrophique.