editeur et compilateur

Gabriel Dos Reis

09/12/2003 à 11:07

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| > | J'avoue qu'en ce qui concerne la programmation, j'avais toujours
| > | pensé que ça devait être le cas -- on apprend la programmation parce
| > | qu'on a déjà envie de programmer.
|
| > ce qui montre une certaine ignorance de comment le système d'éducation
| > fonctionne. Dans nombre de situations, les élèves ne sont pas présents
| > dans une classe pour une matière donnée parce qu'ils ont envie
| > d'apprendre cette matière particulièrement. Cela peut être parce que
| > cette matière *fait* partie du programme/cursus. La programmation
| > n'est pas une exception.
|
| Je me suis peut-être mal exprimé. Il y a un vieux dicton qui dit : qui
| veut les fins veut les moyens. Quand on arrive au niveau de
| l'université, on n'est pas à l'école parce qu'il y a quelqu'un derrière
| qui dit qu'il faut y aller. (Je l'espère, de toute façon.) Si on suit un
| cours de programmation, c'est qu'on veut le suivre. Peut-être pas en
| tant que cours de programmation, mais parce qu'on veut quelque chose, et
| c'est un moyen d'y arriver. On est, de toute façon, motivé.

On peut être très motivé pour obtenir un certain résultat, mais pas
particulièrement par certains moyens. Avant de passer de l'autre côté
de la barrière, i.e. quand j'étais jeune étudiant et beau, l'École
nous avait demandé d'aller obtenir un diplôme de maîtrise ailleurs
(histoire de voir ce qui se passe ailleurs) et le choix des modules
étaient très limités. Résultat, nous nous étions retrouver à étudier
des matières qu'on aimait pas ou pour lesquelles on n'était pas
particulièrement moitvés -- même si on était décidé d'en finir le plus
rapidement possible avec ces formalités, afin d'entamer un DEA où on
commençait à faire de vrais maths. (La même chose vaut lorsque j'ai
tenté de devenir informaticien). Et je sais que c'est une situation
fréquente. Lorsque je suis passé de l'autre côté de la barrière, j'ai
mésuré comment cela peut être chiant pour le prof :-)

| Je sais que c'est plutôt la théorie, et que dans la pratique... C'est
| vrai que mes rémarques s'adressaient surtout à ceux qui voulaient
| devenir programmeur. Mais je suis toujours de l'avis que la
| programmation en C++, ce n'est pas quelque chose qu'on peut faire
| « comme ça », à côté. Si on ne fait qu'un cour de programmation dans son
| cursus, et dans ce cour, on apprend le C++, et rien d'autre, c'est du
| temps perdu. Connaître C++ sans savoir gérer des fichiers de source,
| voire même se servir réelement d'un éditeur, n'a pas de sens.

et qu'en est-il des gens, dans mon cas, qui n'ont suivi que 4 heures
de cours de C++ et qui ont décidé qu'ils perdaient leur temps ?
(Pour l'autre cours de programmation que j'ai suivi, je ne peux pas
dire s'il s'agit d'informatique théorique ou d'algèbre appliquée.
D'ailleurs, le prof/chargé de TD ne voulait plus me voir).

| La question est complexe, et je ne crois pas que c'est le rôle des profs
| de rendre une matière plus barbante qu'elle ne l'est pas déjà. Mais je
| serais de l'avis qu'on peut s'attendre à une certaine maturité des
| étudiants -- s'ils veulent la fin, ils doivent être près à se motiver
| par rapports aux moyens.

Oui, mais cela est très différent de ce que tu as dit précédemment.

-- Gaby

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m38ylnwcge.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.fr writes:
|
| > | J'avoue qu'en ce qui concerne la programmation, j'avais toujours
| > | pensé que ça devait être le cas -- on apprend la programmation parce
| > | qu'on a déjà envie de programmer.
|
| > ce qui montre une certaine ignorance de comment le système d'éducation
| > fonctionne. Dans nombre de situations, les élèves ne sont pas présents
| > dans une classe pour une matière donnée parce qu'ils ont envie
| > d'apprendre cette matière particulièrement. Cela peut être parce que
| > cette matière *fait* partie du programme/cursus. La programmation
| > n'est pas une exception.
|
| Je me suis peut-être mal exprimé. Il y a un vieux dicton qui dit : qui
| veut les fins veut les moyens. Quand on arrive au niveau de
| l'université, on n'est pas à l'école parce qu'il y a quelqu'un derrière
| qui dit qu'il faut y aller. (Je l'espère, de toute façon.) Si on suit un
| cours de programmation, c'est qu'on veut le suivre. Peut-être pas en
| tant que cours de programmation, mais parce qu'on veut quelque chose, et
| c'est un moyen d'y arriver. On est, de toute façon, motivé.

On peut être très motivé pour obtenir un certain résultat, mais pas
particulièrement par certains moyens. Avant de passer de l'autre côté
de la barrière, i.e. quand j'étais jeune étudiant et beau, l'École
nous avait demandé d'aller obtenir un diplôme de maîtrise ailleurs
(histoire de voir ce qui se passe ailleurs) et le choix des modules
étaient très limités. Résultat, nous nous étions retrouver à étudier
des matières qu'on aimait pas ou pour lesquelles on n'était pas
particulièrement moitvés -- même si on était décidé d'en finir le plus
rapidement possible avec ces formalités, afin d'entamer un DEA où on
commençait à faire de vrais maths. (La même chose vaut lorsque j'ai
tenté de devenir informaticien). Et je sais que c'est une situation
fréquente. Lorsque je suis passé de l'autre côté de la barrière, j'ai
mésuré comment cela peut être chiant pour le prof :-)

| Je sais que c'est plutôt la théorie, et que dans la pratique... C'est
| vrai que mes rémarques s'adressaient surtout à ceux qui voulaient
| devenir programmeur. Mais je suis toujours de l'avis que la
| programmation en C++, ce n'est pas quelque chose qu'on peut faire
| « comme ça », à côté. Si on ne fait qu'un cour de programmation dans son
| cursus, et dans ce cour, on apprend le C++, et rien d'autre, c'est du
| temps perdu. Connaître C++ sans savoir gérer des fichiers de source,
| voire même se servir réelement d'un éditeur, n'a pas de sens.

et qu'en est-il des gens, dans mon cas, qui n'ont suivi que 4 heures
de cours de C++ et qui ont décidé qu'ils perdaient leur temps ?
(Pour l'autre cours de programmation que j'ai suivi, je ne peux pas
dire s'il s'agit d'informatique théorique ou d'algèbre appliquée.
D'ailleurs, le prof/chargé de TD ne voulait plus me voir).

| La question est complexe, et je ne crois pas que c'est le rôle des profs
| de rendre une matière plus barbante qu'elle ne l'est pas déjà. Mais je
| serais de l'avis qu'on peut s'attendre à une certaine maturité des
| étudiants -- s'ils veulent la fin, ils doivent être près à se motiver
| par rapports aux moyens.

Oui, mais cela est très différent de ce que tu as dit précédemment.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| > | J'avoue qu'en ce qui concerne la programmation, j'avais toujours
| > | pensé que ça devait être le cas -- on apprend la programmation parce
| > | qu'on a déjà envie de programmer.
|
| > ce qui montre une certaine ignorance de comment le système d'éducation
| > fonctionne. Dans nombre de situations, les élèves ne sont pas présents
| > dans une classe pour une matière donnée parce qu'ils ont envie
| > d'apprendre cette matière particulièrement. Cela peut être parce que
| > cette matière *fait* partie du programme/cursus. La programmation
| > n'est pas une exception.
|
| Je me suis peut-être mal exprimé. Il y a un vieux dicton qui dit : qui
| veut les fins veut les moyens. Quand on arrive au niveau de
| l'université, on n'est pas à l'école parce qu'il y a quelqu'un derrière
| qui dit qu'il faut y aller. (Je l'espère, de toute façon.) Si on suit un
| cours de programmation, c'est qu'on veut le suivre. Peut-être pas en
| tant que cours de programmation, mais parce qu'on veut quelque chose, et
| c'est un moyen d'y arriver. On est, de toute façon, motivé.

On peut être très motivé pour obtenir un certain résultat, mais pas
particulièrement par certains moyens. Avant de passer de l'autre côté
de la barrière, i.e. quand j'étais jeune étudiant et beau, l'École
nous avait demandé d'aller obtenir un diplôme de maîtrise ailleurs
(histoire de voir ce qui se passe ailleurs) et le choix des modules
étaient très limités. Résultat, nous nous étions retrouver à étudier
des matières qu'on aimait pas ou pour lesquelles on n'était pas
particulièrement moitvés -- même si on était décidé d'en finir le plus
rapidement possible avec ces formalités, afin d'entamer un DEA où on
commençait à faire de vrais maths. (La même chose vaut lorsque j'ai
tenté de devenir informaticien). Et je sais que c'est une situation
fréquente. Lorsque je suis passé de l'autre côté de la barrière, j'ai
mésuré comment cela peut être chiant pour le prof :-)

| Je sais que c'est plutôt la théorie, et que dans la pratique... C'est
| vrai que mes rémarques s'adressaient surtout à ceux qui voulaient
| devenir programmeur. Mais je suis toujours de l'avis que la
| programmation en C++, ce n'est pas quelque chose qu'on peut faire
| « comme ça », à côté. Si on ne fait qu'un cour de programmation dans son
| cursus, et dans ce cour, on apprend le C++, et rien d'autre, c'est du
| temps perdu. Connaître C++ sans savoir gérer des fichiers de source,
| voire même se servir réelement d'un éditeur, n'a pas de sens.

et qu'en est-il des gens, dans mon cas, qui n'ont suivi que 4 heures
de cours de C++ et qui ont décidé qu'ils perdaient leur temps ?
(Pour l'autre cours de programmation que j'ai suivi, je ne peux pas
dire s'il s'agit d'informatique théorique ou d'algèbre appliquée.
D'ailleurs, le prof/chargé de TD ne voulait plus me voir).

| La question est complexe, et je ne crois pas que c'est le rôle des profs
| de rendre une matière plus barbante qu'elle ne l'est pas déjà. Mais je
| serais de l'avis qu'on peut s'attendre à une certaine maturité des
| étudiants -- s'ils veulent la fin, ils doivent être près à se motiver
| par rapports aux moyens.

Oui, mais cela est très différent de ce que tu as dit précédemment.

-- Gaby

kanze

09/12/2003 à 11:13

Gabriel Dos Reis wrote in message
news:...

writes:

| mon cas, je vois le C++, et la programmation en général,
| effectivement comme une profession, et même une profession qui se
| pratique par des adultes, et qui exige une certaine rigueur qui ne
| vient pas tout seul.

Je serais presque d'accord si tu enlevais la limite d'âge.

Dans quelle direction ? Je ne mettais pas de limite supérieur d'âge. Et
j'estîme qu'exercer une profession, de façon professionnelle, exige bien
une certaine maturité. Or, si l'âge n'est pas une condition suffisante
de la maturité, il en est bien une condition nécessaire. (Et le niveau
de maturité dont je parle ici, c'est celui qui se développe plus ou
moins entre 14 et 18 ans. Dans la plupart des cas -- je sais que chez
moi, il a été très tard à venir.)

Je ne vois pas ce que cela a de particulier à C++ ou la programmation.

Moi non plus.

Je pratique d'autres métiers que la programmation (je suis
mathématicien de formation) et d'après ce que je vois, ils exigent
tout aussi de la rigueur sinon plus. Et pourtant, je ne susi d'accord
avec les autres parties de tes affirmattions.

Et pourant... Je n'ai exprimé qu'une côté de l'argument. Je sais qu'il y
en a deux, et que ni l'un ni l'autre est 100% juste. Il faut une
équilibre. Tu ne peut pas enseigner que ce qui peut intéresser
immédiatement, parce qu'il y a bien des aspects techniques (comme les
gammes en musique) qu'il faut maîtriser, qu'ils intéressent ou non. Mais
ça ne veut pas dire que c'est mauvais d'ajouter les aspects intéressants
aussi, pour donner de la satisfaction immédiate aux élèves. Une des
définitions de la maturité, c'est la capabilité de travailler en
fonction des satisfactions distantes et non immédiates, mais
psychologiquement, mature ou non, une satisfaction immédiate est un
renforcement non negligeable.

Mais je crois qu'on parle à côté. Tout ce que je dis, c'est qu'il ne
faut pas ne priviléger que le renforcement immédiat. Comme disait Marc :
un bon prof de piano saurait te faire faire des morceaux intéressants
assez vite. Je ne dis pas le contraire, mais je dis aussi qu'il ne
négligera pas les gammes non plus. Surtout quand il s'agit d'un élève
adulte.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3vfor6vwg.fsf@uniton.integrable-solutions.net>...

kanze@gabi-soft.fr writes:

| mon cas, je vois le C++, et la programmation en général,
| effectivement comme une profession, et même une profession qui se
| pratique par des adultes, et qui exige une certaine rigueur qui ne
| vient pas tout seul.

Je serais presque d'accord si tu enlevais la limite d'âge.

Dans quelle direction ? Je ne mettais pas de limite supérieur d'âge. Et
j'estîme qu'exercer une profession, de façon professionnelle, exige bien
une certaine maturité. Or, si l'âge n'est pas une condition suffisante
de la maturité, il en est bien une condition nécessaire. (Et le niveau
de maturité dont je parle ici, c'est celui qui se développe plus ou
moins entre 14 et 18 ans. Dans la plupart des cas -- je sais que chez
moi, il a été très tard à venir.)

Je ne vois pas ce que cela a de particulier à C++ ou la programmation.

Moi non plus.

Je pratique d'autres métiers que la programmation (je suis
mathématicien de formation) et d'après ce que je vois, ils exigent
tout aussi de la rigueur sinon plus. Et pourtant, je ne susi d'accord
avec les autres parties de tes affirmattions.

Et pourant... Je n'ai exprimé qu'une côté de l'argument. Je sais qu'il y
en a deux, et que ni l'un ni l'autre est 100% juste. Il faut une
équilibre. Tu ne peut pas enseigner que ce qui peut intéresser
immédiatement, parce qu'il y a bien des aspects techniques (comme les
gammes en musique) qu'il faut maîtriser, qu'ils intéressent ou non. Mais
ça ne veut pas dire que c'est mauvais d'ajouter les aspects intéressants
aussi, pour donner de la satisfaction immédiate aux élèves. Une des
définitions de la maturité, c'est la capabilité de travailler en
fonction des satisfactions distantes et non immédiates, mais
psychologiquement, mature ou non, une satisfaction immédiate est un
renforcement non negligeable.

Mais je crois qu'on parle à côté. Tout ce que je dis, c'est qu'il ne
faut pas ne priviléger que le renforcement immédiat. Comme disait Marc :
un bon prof de piano saurait te faire faire des morceaux intéressants
assez vite. Je ne dis pas le contraire, mais je dis aussi qu'il ne
négligera pas les gammes non plus. Surtout quand il s'agit d'un élève
adulte.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis wrote in message
news:...

writes:

| mon cas, je vois le C++, et la programmation en général,
| effectivement comme une profession, et même une profession qui se
| pratique par des adultes, et qui exige une certaine rigueur qui ne
| vient pas tout seul.

Je serais presque d'accord si tu enlevais la limite d'âge.

Dans quelle direction ? Je ne mettais pas de limite supérieur d'âge. Et
j'estîme qu'exercer une profession, de façon professionnelle, exige bien
une certaine maturité. Or, si l'âge n'est pas une condition suffisante
de la maturité, il en est bien une condition nécessaire. (Et le niveau
de maturité dont je parle ici, c'est celui qui se développe plus ou
moins entre 14 et 18 ans. Dans la plupart des cas -- je sais que chez
moi, il a été très tard à venir.)

Je ne vois pas ce que cela a de particulier à C++ ou la programmation.

Moi non plus.

Je pratique d'autres métiers que la programmation (je suis
mathématicien de formation) et d'après ce que je vois, ils exigent
tout aussi de la rigueur sinon plus. Et pourtant, je ne susi d'accord
avec les autres parties de tes affirmattions.

Et pourant... Je n'ai exprimé qu'une côté de l'argument. Je sais qu'il y
en a deux, et que ni l'un ni l'autre est 100% juste. Il faut une
équilibre. Tu ne peut pas enseigner que ce qui peut intéresser
immédiatement, parce qu'il y a bien des aspects techniques (comme les
gammes en musique) qu'il faut maîtriser, qu'ils intéressent ou non. Mais
ça ne veut pas dire que c'est mauvais d'ajouter les aspects intéressants
aussi, pour donner de la satisfaction immédiate aux élèves. Une des
définitions de la maturité, c'est la capabilité de travailler en
fonction des satisfactions distantes et non immédiates, mais
psychologiquement, mature ou non, une satisfaction immédiate est un
renforcement non negligeable.

Mais je crois qu'on parle à côté. Tout ce que je dis, c'est qu'il ne
faut pas ne priviléger que le renforcement immédiat. Comme disait Marc :
un bon prof de piano saurait te faire faire des morceaux intéressants
assez vite. Je ne dis pas le contraire, mais je dis aussi qu'il ne
négligera pas les gammes non plus. Surtout quand il s'agit d'un élève
adulte.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gabriel Dos Reis

09/12/2003 à 11:32

Gabriel Dos Reis

09/12/2003 à 11:34

Marc Boyer writes:

| Après, faire écrire un code à quelqu'un dont ce
| n'est pas le metier, c'est comme faire faire de la
| plomberie à son maçon: faut pas trop en demander,
| on a ce qu'on mérite, et si ça pète dans 3 ans, ça
| peut revenir cher...

Pourquoi, t'as eu des dégâts des eaux récemment ? ;-)

-- Gaby

Marc Boyer

09/12/2003 à 11:35

wrote:

Marc Boyer wrote in message
news:<br1bgp$spe$...

Mais je crois que cette discussion révelle des différences
de point de vue sur la notion d'apprentissage qui nous
séparent bien au delà du simple cadre du C++.

Certes. Disons que je ne suis pas totalement contre ce que tu dis, mais
je crois que souvent, on est allé trop loin dans cette direction. Dans
mon cas, je vois le C++, et la programmation en général, effectivement
comme une profession,

Disons que j'avais en plus un peu raté le contexte: j'avais
eut la flemme de visiter le site "developpez", qu'il se présente
en effet comme un site de professionnels.
Pour ma part, j'admets qu'il y ait des gens qui codent
par pur plaisir, en amateur, pour qui qualité, efficacité
et robustesse ne sont pas des maîtres mots.
J'admets aussi (et c'est du au fait que j'ai beaucoup
enseigné à des gens qui n'ont pas destination à être
informaticien) qu'il existe des professionnels qui ne
sont pas des informaticiens, mais qui ont des besoins
ponctuels d'écriture de code, et auquels on a que le
temps d'apprendre des bases.

Après, faire écrire un code à quelqu'un dont ce
n'est pas le metier, c'est comme faire faire de la
plomberie à son maçon: faut pas trop en demander,
on a ce qu'on mérite, et si ça pète dans 3 ans, ça
peut revenir cher...

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

kanze

09/12/2003 à 12:02

Loïc Joly wrote in message
news:<br2lr6$bpo$...

wrote:

En s'appliquant, on apprend assez d'emacs ou de vi pour commencer en
moins d'une journée. Par la suite, on apprend à fur et au mesure que
les besoins se font sentir.

J'ai essayé les deux. Le problème est que j'avais déjà d'autres
habitudes de frappe, et au bout de bien plus d'une journée d'essais,
j'utilise sous windows visual C++ et sous Linux/Irix (plus rare)
nedit. Pourquoi ? Principalmeent parce que ce sont des outils qui ont
(par défaut et sans devoir comprendre le Lisp) des raccourcis clavier
cohérents avec ceux de tous les autres logiciles que je peux utiliser
partout.

Je ne connais pas nedit ; je ne peux donc pas dire beaucoup. Mais il y a
bien des éditeurs où on a besoin de moins de frappes pour effectuer le
même boulot. Et que si tu développes en C++ intensivement, l'effort
nécessaire à les apprendre se repaie très vite en productivité accrue.

C'est le vieux argument sur le « user friendliness ». Ce qui est
« friendly » pour le débuttant ne l'est pas forcement pour l'expert. Une
commande comme « affiche-moi tous les fichiers dans le répertoire
actuel » est très intuitif pour un débuttant, mais je préfère de loin
« ls ». Même si j'ai dû investir du temps à l'apprendre. Ça vaut,
évidemment, parce que j'utilise la commande souvent. J'aimerais bien que
les commandes que j'utilise plus rarement soient plus intuitives ; que
je n'ai pas constamment le besoin de tapper « man quelquechose ».

Et mon argument n'est pas tellement pour ou contre tel ou tel éditeur,
mais plutôt sur les critères qui servent à évaluer l'éditeur. Que
l'argument que emacs soit rébarbant pour un débuttant n'en est pas un,
parce que si tu programmes, tu vas passer énormement du temps avec
l'éditeur.

De plus les avantages présupposés d'Emacs ou vi sur visualStudio ne me
sont pas apparus du tout. Pour switcher entre mode saisie et mode
déplacement, j'ai depuis toujours l'habitude de bouger ma main gauche
de 20cm vers la droite vers les touches flèchées, et avec ma droite de
saisir la souris. Y a-t-il d'autres différences fondamentales ?

Tu viens de citer une différence critique. S'il faut lever la main de la
position de base du clavier, l'éditeur n'est pas bon. Ceci dit, je ne
crois pas que ce soit le cas non plus avec l'éditeur du Visual Studios.
Je ne le connais pas, mais au moins avec les autres outils Microsoft, il
est en général possible de tout faire sans lever la main du clavier. À
condition de s'y connaître, évidemment.

Ce qui me gène surtout à moi, avec l'environement Microsoft, c'est la
manque de portabilité. Je travaille beaucoup sous Unix. Alors, avec
l'environement CygWin sous Windows, j'ai à peu près le même environement
dans tous les cas. Je n'ai donc pas eu l'occasion d'apprendre comment
fonctionne l'environement Visual Studio.

Ce qui me gène aussi, c'est l'attitude que emacs ou vi, c'est un
environement « exotique » ou pour des « geeks ». Emacs avec un shell de
type Unix (bash ou ksh), dans des multiples fenêtres qu'on peut changer
sans lever les mains du clavier, c'est un envirionement on ne peut plus
conviviable une fois qu'on l'a appris. Et vue que c'est où on va passer
le plus gros de son temps, l'apprentissage vaut la peine. Mais ce n'est
certainement pas le seul environnement possible -- le collègue ici qui
fait le client sous Windows travaille avec Visual Studios, et il fait
aussi tout sans jamais lever la main du clavier (et avec une vitesse et
une paucité de frappe qui m'éblouit).

Le problème que je vois, c'est l'attitude. Qu'on choisit Visual Studios
parce que c'est un environement puissant, qu'on va apprendre (mais qu'il
faut de l'effort pour bien apprendre), c'est tout à fait bien. C'est
qu'on le choisit avec l'idée que ça va éviter la nécessité d'un
apprentissage, parce que tout est intuitif, qui me pose le problème.
C'est l'attitude qui l'accompagne trop souvent, et non l'outil en soi.

(Je ne souhaite pas entrainer une discussion stérile et sans fin sur
les éditeurs, d'où d'ailleurs le temps que j'ai mis à répondre, mais
j'en ai eu assez d'entendre des préférences personnelles mises en
avant comme s'il s'agissait de vérités fondamentales)

C'est difficile à discuter dans l'abstraction, surtout de ce qu'on ne
connaît pas. Je peux dire que dans mon cas personnel, emacs est
supérieur à Visual Studios, pour la simple raison que Visual Studios ne
supportent pas du tout ce que je dois faire, c-à-d développer un serveur
sous Solaris. Emacs/Bash gagne au niveau de la portabilité. Pour la
reste, je ne le connais pas.

Si la question se pose : qu'est-ce qu'on doit enseigner aux débuttants,
je penche pour une solution portable, parce qu'a priori, on ne sait pas
sur quoi ils vont travailler par la suite. Encore que ça dépend ;
j'imagine qu'il existe bien des cycles d'enseignement orienté
exclusivement Windows, où on apprend le C++ avec MFC, etc. Dans ce
cas-là, Visual Studios me semble tout à fait indiquer. (Mais je tiens
alors à ce qu'ils enseignent comme un outil complex et puissant, qui
exige aussi son apprentissage pour qu'on y devient réelement efficace.)

Quant à nedit, je ne peux rien dire, parce que je ne le connais pas du
tout.

Ou alors, si tu veux vraiment utiliser Emacs comme éditeur pour C++,
je conseille d'apprendre d'abord à se servir d'Emacs, et après[*]
seulement de commencer à apprendre le C++.

C'est une possibilité aussi. Je dirais en tout cas qu'avant
d'apprendre ou emacs ou le C++, on commence par apprendre ce que
c'est qu'un ordinateur, avec un système d'exploitation, qu'on sache
par exemple l'allumer et l'éteindre, faire des backups (eh, oui), et
d'autres petites bricoles, de préférence au niveau de la ligne de
commande.

Pourquoi ? Si un outil me permet de faire une sauvegarde plus
simplement et avec suffisemment d'options avec une IHM, et sans phase
d'apprentissage, pourquoi ne pas l'utiliser ? Si mon but dans la vie
est de devenir un expert en sauvegarde de données, pourquoi pas, mais
si ce n'est pas le cas je ne voit pas trop l'intérêt. Qui saurait
encore aujourd'hui démarrer sa voiture avec une manivelle ?

C'est une façon de combiner deux choses. D'une côté, l'environement
aujourd'hui, c'est que tu risques fort d'avoir ta propre machine un
jour à l'autre, avec ton propre disque. Savoir faire un sauvegarde me
semble donc nécessaire. De l'autre, tôt ou tard, il faut bien savoir
pouvoir automatiser des activités répétatives. Pour l'instant, je ne
connais pas d'autre solution que des scripts -- des .bat sous Windows,
si tu préfères.

Et qu'on sache se servir d'un clavier. J'avoue ne pas comprendre
comment on peut sortir d'un lycée sans avoir apris quelque chose
d'aussi fondamental.

Parce qu'on considère que le goulot d'étranglement est en général
situé ailleur ?

Il y a malheureusement beaucoup de goulots d'étranglement, et apprendre
à tapper ne va pas les éliminer tous. N'empêche qu'il améliorera ta
productivité.

Vouloir optimiser la vitesse de frappe à tout prix, n'est-ce pas
équivalent à "optimiser" du code avant profiling ?

Non, parce qu'on sait que ça apportera une benefice. Sur tout les
projets. Si tu régardes bien les discussions dans la passée, j'admets
l'optimisation avant profiling dans le cas de certaines bibliothèques ;
même sans le profiler, si j'écris une implémentation de la bibliothèque
standard, je sais qu'il y aura bien une utilisation quelque part où
vector::operator[] serait critique. De même, je sais déjà que si tu vas
programmer professionnellement, il y aurait des moments où ta vitesse de
frapper va jouer sur ta productivité.

Note bien que la vitesse de frappe, ça ne joue pas que lorsque tu écris
le programme. Ça joue peut-être même plus quand tu écris la
documentation. (Je suis actuellement en train de porter de la
documentation Doxygen dans de l'ancien code, et peut t'assurer, je suis
bien content que je tappe vite.)

Pour la plupart des gens avec qui je travaille, la frappe effective de
texte n'est qu'une activité annexe par rapport, par exemple, à la
phrase de réflexion, ou la phase de lecture de texte existant, pour
laquelle la présence d'une souris peut être intéressante.

Tout à fait. La frappe ne concerne que certaines parties du
développement ; quand je lis du code en préparation d'une revue de code,
par exemple, je ne touche même pas au clavier -- je fais uniquement avec
la souris (qui est un outil admirable pour scrolling dans du texte).

De point de vue ergonomique, ce qu'il faut éviter, c'est d'aller de
l'un à l'autre.

En outre, les méthodes de frappe que je connais (ma mère est prof de
dactylo) sont plus destinées à la saisie de texte que de programmes
informatiques.

La plupart des caractères que je frappe dans un programme sont bien du
texte. Et développer un programme ne comporte pas que du code.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<br2lr6$bpo$1@news-reader1.wanadoo.fr>...

kanze@gabi-soft.fr wrote:

En s'appliquant, on apprend assez d'emacs ou de vi pour commencer en
moins d'une journée. Par la suite, on apprend à fur et au mesure que
les besoins se font sentir.

J'ai essayé les deux. Le problème est que j'avais déjà d'autres
habitudes de frappe, et au bout de bien plus d'une journée d'essais,
j'utilise sous windows visual C++ et sous Linux/Irix (plus rare)
nedit. Pourquoi ? Principalmeent parce que ce sont des outils qui ont
(par défaut et sans devoir comprendre le Lisp) des raccourcis clavier
cohérents avec ceux de tous les autres logiciles que je peux utiliser
partout.

Je ne connais pas nedit ; je ne peux donc pas dire beaucoup. Mais il y a
bien des éditeurs où on a besoin de moins de frappes pour effectuer le
même boulot. Et que si tu développes en C++ intensivement, l'effort
nécessaire à les apprendre se repaie très vite en productivité accrue.

C'est le vieux argument sur le « user friendliness ». Ce qui est
« friendly » pour le débuttant ne l'est pas forcement pour l'expert. Une
commande comme « affiche-moi tous les fichiers dans le répertoire
actuel » est très intuitif pour un débuttant, mais je préfère de loin
« ls ». Même si j'ai dû investir du temps à l'apprendre. Ça vaut,
évidemment, parce que j'utilise la commande souvent. J'aimerais bien que
les commandes que j'utilise plus rarement soient plus intuitives ; que
je n'ai pas constamment le besoin de tapper « man quelquechose ».

Et mon argument n'est pas tellement pour ou contre tel ou tel éditeur,
mais plutôt sur les critères qui servent à évaluer l'éditeur. Que
l'argument que emacs soit rébarbant pour un débuttant n'en est pas un,
parce que si tu programmes, tu vas passer énormement du temps avec
l'éditeur.

De plus les avantages présupposés d'Emacs ou vi sur visualStudio ne me
sont pas apparus du tout. Pour switcher entre mode saisie et mode
déplacement, j'ai depuis toujours l'habitude de bouger ma main gauche
de 20cm vers la droite vers les touches flèchées, et avec ma droite de
saisir la souris. Y a-t-il d'autres différences fondamentales ?

Tu viens de citer une différence critique. S'il faut lever la main de la
position de base du clavier, l'éditeur n'est pas bon. Ceci dit, je ne
crois pas que ce soit le cas non plus avec l'éditeur du Visual Studios.
Je ne le connais pas, mais au moins avec les autres outils Microsoft, il
est en général possible de tout faire sans lever la main du clavier. À
condition de s'y connaître, évidemment.

Ce qui me gène surtout à moi, avec l'environement Microsoft, c'est la
manque de portabilité. Je travaille beaucoup sous Unix. Alors, avec
l'environement CygWin sous Windows, j'ai à peu près le même environement
dans tous les cas. Je n'ai donc pas eu l'occasion d'apprendre comment
fonctionne l'environement Visual Studio.

Ce qui me gène aussi, c'est l'attitude que emacs ou vi, c'est un
environement « exotique » ou pour des « geeks ». Emacs avec un shell de
type Unix (bash ou ksh), dans des multiples fenêtres qu'on peut changer
sans lever les mains du clavier, c'est un envirionement on ne peut plus
conviviable une fois qu'on l'a appris. Et vue que c'est où on va passer
le plus gros de son temps, l'apprentissage vaut la peine. Mais ce n'est
certainement pas le seul environnement possible -- le collègue ici qui
fait le client sous Windows travaille avec Visual Studios, et il fait
aussi tout sans jamais lever la main du clavier (et avec une vitesse et
une paucité de frappe qui m'éblouit).

Le problème que je vois, c'est l'attitude. Qu'on choisit Visual Studios
parce que c'est un environement puissant, qu'on va apprendre (mais qu'il
faut de l'effort pour bien apprendre), c'est tout à fait bien. C'est
qu'on le choisit avec l'idée que ça va éviter la nécessité d'un
apprentissage, parce que tout est intuitif, qui me pose le problème.
C'est l'attitude qui l'accompagne trop souvent, et non l'outil en soi.

(Je ne souhaite pas entrainer une discussion stérile et sans fin sur
les éditeurs, d'où d'ailleurs le temps que j'ai mis à répondre, mais
j'en ai eu assez d'entendre des préférences personnelles mises en
avant comme s'il s'agissait de vérités fondamentales)

C'est difficile à discuter dans l'abstraction, surtout de ce qu'on ne
connaît pas. Je peux dire que dans mon cas personnel, emacs est
supérieur à Visual Studios, pour la simple raison que Visual Studios ne
supportent pas du tout ce que je dois faire, c-à-d développer un serveur
sous Solaris. Emacs/Bash gagne au niveau de la portabilité. Pour la
reste, je ne le connais pas.

Si la question se pose : qu'est-ce qu'on doit enseigner aux débuttants,
je penche pour une solution portable, parce qu'a priori, on ne sait pas
sur quoi ils vont travailler par la suite. Encore que ça dépend ;
j'imagine qu'il existe bien des cycles d'enseignement orienté
exclusivement Windows, où on apprend le C++ avec MFC, etc. Dans ce
cas-là, Visual Studios me semble tout à fait indiquer. (Mais je tiens
alors à ce qu'ils enseignent comme un outil complex et puissant, qui
exige aussi son apprentissage pour qu'on y devient réelement efficace.)

Quant à nedit, je ne peux rien dire, parce que je ne le connais pas du
tout.

Ou alors, si tu veux vraiment utiliser Emacs comme éditeur pour C++,
je conseille d'apprendre d'abord à se servir d'Emacs, et après[*]
seulement de commencer à apprendre le C++.

C'est une possibilité aussi. Je dirais en tout cas qu'avant
d'apprendre ou emacs ou le C++, on commence par apprendre ce que
c'est qu'un ordinateur, avec un système d'exploitation, qu'on sache
par exemple l'allumer et l'éteindre, faire des backups (eh, oui), et
d'autres petites bricoles, de préférence au niveau de la ligne de
commande.

Pourquoi ? Si un outil me permet de faire une sauvegarde plus
simplement et avec suffisemment d'options avec une IHM, et sans phase
d'apprentissage, pourquoi ne pas l'utiliser ? Si mon but dans la vie
est de devenir un expert en sauvegarde de données, pourquoi pas, mais
si ce n'est pas le cas je ne voit pas trop l'intérêt. Qui saurait
encore aujourd'hui démarrer sa voiture avec une manivelle ?

C'est une façon de combiner deux choses. D'une côté, l'environement
aujourd'hui, c'est que tu risques fort d'avoir ta propre machine un
jour à l'autre, avec ton propre disque. Savoir faire un sauvegarde me
semble donc nécessaire. De l'autre, tôt ou tard, il faut bien savoir
pouvoir automatiser des activités répétatives. Pour l'instant, je ne
connais pas d'autre solution que des scripts -- des .bat sous Windows,
si tu préfères.

Et qu'on sache se servir d'un clavier. J'avoue ne pas comprendre
comment on peut sortir d'un lycée sans avoir apris quelque chose
d'aussi fondamental.

Parce qu'on considère que le goulot d'étranglement est en général
situé ailleur ?

Il y a malheureusement beaucoup de goulots d'étranglement, et apprendre
à tapper ne va pas les éliminer tous. N'empêche qu'il améliorera ta
productivité.

Vouloir optimiser la vitesse de frappe à tout prix, n'est-ce pas
équivalent à "optimiser" du code avant profiling ?

Non, parce qu'on sait que ça apportera une benefice. Sur tout les
projets. Si tu régardes bien les discussions dans la passée, j'admets
l'optimisation avant profiling dans le cas de certaines bibliothèques ;
même sans le profiler, si j'écris une implémentation de la bibliothèque
standard, je sais qu'il y aura bien une utilisation quelque part où
vector::operator[] serait critique. De même, je sais déjà que si tu vas
programmer professionnellement, il y aurait des moments où ta vitesse de
frapper va jouer sur ta productivité.

Note bien que la vitesse de frappe, ça ne joue pas que lorsque tu écris
le programme. Ça joue peut-être même plus quand tu écris la
documentation. (Je suis actuellement en train de porter de la
documentation Doxygen dans de l'ancien code, et peut t'assurer, je suis
bien content que je tappe vite.)

Pour la plupart des gens avec qui je travaille, la frappe effective de
texte n'est qu'une activité annexe par rapport, par exemple, à la
phrase de réflexion, ou la phase de lecture de texte existant, pour
laquelle la présence d'une souris peut être intéressante.

Tout à fait. La frappe ne concerne que certaines parties du
développement ; quand je lis du code en préparation d'une revue de code,
par exemple, je ne touche même pas au clavier -- je fais uniquement avec
la souris (qui est un outil admirable pour scrolling dans du texte).

De point de vue ergonomique, ce qu'il faut éviter, c'est d'aller de
l'un à l'autre.

En outre, les méthodes de frappe que je connais (ma mère est prof de
dactylo) sont plus destinées à la saisie de texte que de programmes
informatiques.

La plupart des caractères que je frappe dans un programme sont bien du
texte. Et développer un programme ne comporte pas que du code.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

Loïc Joly wrote in message
news:<br2lr6$bpo$...

wrote:

En s'appliquant, on apprend assez d'emacs ou de vi pour commencer en
moins d'une journée. Par la suite, on apprend à fur et au mesure que
les besoins se font sentir.

J'ai essayé les deux. Le problème est que j'avais déjà d'autres
habitudes de frappe, et au bout de bien plus d'une journée d'essais,
j'utilise sous windows visual C++ et sous Linux/Irix (plus rare)
nedit. Pourquoi ? Principalmeent parce que ce sont des outils qui ont
(par défaut et sans devoir comprendre le Lisp) des raccourcis clavier
cohérents avec ceux de tous les autres logiciles que je peux utiliser
partout.

Je ne connais pas nedit ; je ne peux donc pas dire beaucoup. Mais il y a
bien des éditeurs où on a besoin de moins de frappes pour effectuer le
même boulot. Et que si tu développes en C++ intensivement, l'effort
nécessaire à les apprendre se repaie très vite en productivité accrue.

C'est le vieux argument sur le « user friendliness ». Ce qui est
« friendly » pour le débuttant ne l'est pas forcement pour l'expert. Une
commande comme « affiche-moi tous les fichiers dans le répertoire
actuel » est très intuitif pour un débuttant, mais je préfère de loin
« ls ». Même si j'ai dû investir du temps à l'apprendre. Ça vaut,
évidemment, parce que j'utilise la commande souvent. J'aimerais bien que
les commandes que j'utilise plus rarement soient plus intuitives ; que
je n'ai pas constamment le besoin de tapper « man quelquechose ».

Et mon argument n'est pas tellement pour ou contre tel ou tel éditeur,
mais plutôt sur les critères qui servent à évaluer l'éditeur. Que
l'argument que emacs soit rébarbant pour un débuttant n'en est pas un,
parce que si tu programmes, tu vas passer énormement du temps avec
l'éditeur.

De plus les avantages présupposés d'Emacs ou vi sur visualStudio ne me
sont pas apparus du tout. Pour switcher entre mode saisie et mode
déplacement, j'ai depuis toujours l'habitude de bouger ma main gauche
de 20cm vers la droite vers les touches flèchées, et avec ma droite de
saisir la souris. Y a-t-il d'autres différences fondamentales ?

Tu viens de citer une différence critique. S'il faut lever la main de la
position de base du clavier, l'éditeur n'est pas bon. Ceci dit, je ne
crois pas que ce soit le cas non plus avec l'éditeur du Visual Studios.
Je ne le connais pas, mais au moins avec les autres outils Microsoft, il
est en général possible de tout faire sans lever la main du clavier. À
condition de s'y connaître, évidemment.

Ce qui me gène surtout à moi, avec l'environement Microsoft, c'est la
manque de portabilité. Je travaille beaucoup sous Unix. Alors, avec
l'environement CygWin sous Windows, j'ai à peu près le même environement
dans tous les cas. Je n'ai donc pas eu l'occasion d'apprendre comment
fonctionne l'environement Visual Studio.

Ce qui me gène aussi, c'est l'attitude que emacs ou vi, c'est un
environement « exotique » ou pour des « geeks ». Emacs avec un shell de
type Unix (bash ou ksh), dans des multiples fenêtres qu'on peut changer
sans lever les mains du clavier, c'est un envirionement on ne peut plus
conviviable une fois qu'on l'a appris. Et vue que c'est où on va passer
le plus gros de son temps, l'apprentissage vaut la peine. Mais ce n'est
certainement pas le seul environnement possible -- le collègue ici qui
fait le client sous Windows travaille avec Visual Studios, et il fait
aussi tout sans jamais lever la main du clavier (et avec une vitesse et
une paucité de frappe qui m'éblouit).

Le problème que je vois, c'est l'attitude. Qu'on choisit Visual Studios
parce que c'est un environement puissant, qu'on va apprendre (mais qu'il
faut de l'effort pour bien apprendre), c'est tout à fait bien. C'est
qu'on le choisit avec l'idée que ça va éviter la nécessité d'un
apprentissage, parce que tout est intuitif, qui me pose le problème.
C'est l'attitude qui l'accompagne trop souvent, et non l'outil en soi.

(Je ne souhaite pas entrainer une discussion stérile et sans fin sur
les éditeurs, d'où d'ailleurs le temps que j'ai mis à répondre, mais
j'en ai eu assez d'entendre des préférences personnelles mises en
avant comme s'il s'agissait de vérités fondamentales)

C'est difficile à discuter dans l'abstraction, surtout de ce qu'on ne
connaît pas. Je peux dire que dans mon cas personnel, emacs est
supérieur à Visual Studios, pour la simple raison que Visual Studios ne
supportent pas du tout ce que je dois faire, c-à-d développer un serveur
sous Solaris. Emacs/Bash gagne au niveau de la portabilité. Pour la
reste, je ne le connais pas.

Si la question se pose : qu'est-ce qu'on doit enseigner aux débuttants,
je penche pour une solution portable, parce qu'a priori, on ne sait pas
sur quoi ils vont travailler par la suite. Encore que ça dépend ;
j'imagine qu'il existe bien des cycles d'enseignement orienté
exclusivement Windows, où on apprend le C++ avec MFC, etc. Dans ce
cas-là, Visual Studios me semble tout à fait indiquer. (Mais je tiens
alors à ce qu'ils enseignent comme un outil complex et puissant, qui
exige aussi son apprentissage pour qu'on y devient réelement efficace.)

Quant à nedit, je ne peux rien dire, parce que je ne le connais pas du
tout.

Ou alors, si tu veux vraiment utiliser Emacs comme éditeur pour C++,
je conseille d'apprendre d'abord à se servir d'Emacs, et après[*]
seulement de commencer à apprendre le C++.

C'est une possibilité aussi. Je dirais en tout cas qu'avant
d'apprendre ou emacs ou le C++, on commence par apprendre ce que
c'est qu'un ordinateur, avec un système d'exploitation, qu'on sache
par exemple l'allumer et l'éteindre, faire des backups (eh, oui), et
d'autres petites bricoles, de préférence au niveau de la ligne de
commande.

Pourquoi ? Si un outil me permet de faire une sauvegarde plus
simplement et avec suffisemment d'options avec une IHM, et sans phase
d'apprentissage, pourquoi ne pas l'utiliser ? Si mon but dans la vie
est de devenir un expert en sauvegarde de données, pourquoi pas, mais
si ce n'est pas le cas je ne voit pas trop l'intérêt. Qui saurait
encore aujourd'hui démarrer sa voiture avec une manivelle ?

C'est une façon de combiner deux choses. D'une côté, l'environement
aujourd'hui, c'est que tu risques fort d'avoir ta propre machine un
jour à l'autre, avec ton propre disque. Savoir faire un sauvegarde me
semble donc nécessaire. De l'autre, tôt ou tard, il faut bien savoir
pouvoir automatiser des activités répétatives. Pour l'instant, je ne
connais pas d'autre solution que des scripts -- des .bat sous Windows,
si tu préfères.

Et qu'on sache se servir d'un clavier. J'avoue ne pas comprendre
comment on peut sortir d'un lycée sans avoir apris quelque chose
d'aussi fondamental.

Parce qu'on considère que le goulot d'étranglement est en général
situé ailleur ?

Il y a malheureusement beaucoup de goulots d'étranglement, et apprendre
à tapper ne va pas les éliminer tous. N'empêche qu'il améliorera ta
productivité.

Vouloir optimiser la vitesse de frappe à tout prix, n'est-ce pas
équivalent à "optimiser" du code avant profiling ?

Non, parce qu'on sait que ça apportera une benefice. Sur tout les
projets. Si tu régardes bien les discussions dans la passée, j'admets
l'optimisation avant profiling dans le cas de certaines bibliothèques ;
même sans le profiler, si j'écris une implémentation de la bibliothèque
standard, je sais qu'il y aura bien une utilisation quelque part où
vector::operator[] serait critique. De même, je sais déjà que si tu vas
programmer professionnellement, il y aurait des moments où ta vitesse de
frapper va jouer sur ta productivité.

Note bien que la vitesse de frappe, ça ne joue pas que lorsque tu écris
le programme. Ça joue peut-être même plus quand tu écris la
documentation. (Je suis actuellement en train de porter de la
documentation Doxygen dans de l'ancien code, et peut t'assurer, je suis
bien content que je tappe vite.)

Pour la plupart des gens avec qui je travaille, la frappe effective de
texte n'est qu'une activité annexe par rapport, par exemple, à la
phrase de réflexion, ou la phase de lecture de texte existant, pour
laquelle la présence d'une souris peut être intéressante.

Tout à fait. La frappe ne concerne que certaines parties du
développement ; quand je lis du code en préparation d'une revue de code,
par exemple, je ne touche même pas au clavier -- je fais uniquement avec
la souris (qui est un outil admirable pour scrolling dans du texte).

De point de vue ergonomique, ce qu'il faut éviter, c'est d'aller de
l'un à l'autre.

En outre, les méthodes de frappe que je connais (ma mère est prof de
dactylo) sont plus destinées à la saisie de texte que de programmes
informatiques.

La plupart des caractères que je frappe dans un programme sont bien du
texte. Et développer un programme ne comporte pas que du code.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gabriel Dos Reis

09/12/2003 à 12:33

writes:

| Loïc Joly wrote in message
| news:<br2lr6$bpo$...
| > wrote:
|
| > > En s'appliquant, on apprend assez d'emacs ou de vi pour commencer en
| > > moins d'une journée. Par la suite, on apprend à fur et au mesure que
| > > les besoins se font sentir.
|
| > J'ai essayé les deux. Le problème est que j'avais déjà d'autres
| > habitudes de frappe, et au bout de bien plus d'une journée d'essais,
| > j'utilise sous windows visual C++ et sous Linux/Irix (plus rare)
| > nedit. Pourquoi ? Principalmeent parce que ce sont des outils qui ont
| > (par défaut et sans devoir comprendre le Lisp) des raccourcis clavier
| > cohérents avec ceux de tous les autres logiciles que je peux utiliser
| > partout.
|
| Je ne connais pas nedit ; je ne peux donc pas dire beaucoup.

C'est pour cela qu'il est plus que bienvenu que tu ne présentes pas tes
préférences comme des vérités révelées. Et ne viens pas me faire le
coup du mec dont le français n'est pas la langue maternelle ou
similaire. Des gens dont le français n'est pas la langue maternelle
ont quand même relevé que tu es moins docte sur les groupes
anglophones que tu ne l'es ici.

[...]

| Ce qui me gène aussi, c'est l'attitude que emacs ou vi, c'est un
| environement « exotique » ou pour des « geeks ».

Peux-tu donner des références spécifiques à des messages dans ce thread ?

-- Gaby

Pierre Maurette

09/12/2003 à 12:36

a écrit
[...]

Par contre, décréter que l'on apprend à programmer par envie est tout
à fait réducteur.

C'est une simplification. Je le sais.
Et j'ai été un peu trop lyrique dans ma réponse ;-)

Alors, toute la question est là : est-ce que tu enseignes à des adultes,
qui veulent apprendre (pour une raison ou une autre -- pas forcement
parce que la matière leur intéresse en soi), ou est-ce que tu enseignes
à des enfants, parce que c'est quelque chose qui va leur servir plus
tard, et qu'il s'agit de leur en faire naître l'intérêt ? Je sais que la
dicotomie est un peu artificielle, et schématisée, mais c'est quand même
une question qu'il faut se poser. (Et comme l'a remarqué Gaby, je n'ai
pas assez d'expérience avec l'éducation nationale pour savoir la
situation réele dans les universités. J'aurais tendance à dire que si on
se trouve encore au stade de l'éveil, c'est qu'il y a un problème
profond en amont.)
Le premier langage que devraient apprendre les étudiants en informatique au

niveau universitaire est sans hésitation le français, par rapport auquel la
majorité en sont au stade de l'éveil.
Ça a un goût de troll, mais ....
Pierre

Gabriel Dos Reis

09/12/2003 à 12:48

"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> writes:

| Le premier langage que devraient apprendre les étudiants en informatique au
| niveau universitaire est sans hésitation le français, par rapport auquel la
| majorité en sont au stade de l'éveil.

C'est pour pouvoir lire les traductions françaises des documentations
en anglais ? ;-p

(tiens au fait Michel, j'ai enfin vu, touché et parcouru ton travail
sur la traduction française de TC++PL3: merci !)

-- Gaby

Michel Michaud

09/12/2003 à 16:44

Dans news:, Jean-Marc

"Michel Michaud" writes:

Dans news:,
En s'appliquant, on apprend assez d'emacs ou de vi pour commencer
en moins d'une journée. Par la suite, on apprend à fur et au
mesure que les besoins se font sentir.

Sans s'appliquer, on peut apprendre d'autres éditeurs en quelques
minutes :-)

Ce que tu peux faire avec ces editeurs en quelques minutes, tu peux
le faire avec emacs dans le meme temps. Ce que tu peux faire avec

C'est gentil de dire « tu », parce que dans ce cas tu as raison,
moi je peux :-)

Mais si on généralise, je peux t'assurer que c'est faux. Ça fait
des années qu'on enseigne emacs, je sais de quoi je parle (et vi
est pire bien entendu). Si on parle de gens qui ne connaissent rien
de rien à l'informatique, alors peut-être que ce n'est pas tellement
plus difficile. Mais si quelqu'un a déjà utiliser un seul logiciel
genre traitement de texte (ou même moins proche d'un éditeur), alors
emacs est très loin.

emacs au bout d'une journee, tu ne peux pas le faire avec ces
editeurs.

Une journée. Tu veux dire 8 heures d'apprentissage (et non pas
d'utilisation) ? Je n'ai pas le goût d'enseigner emacs pendant
8 heures ! Alors oui, plus tard, quand les élèves auront le
goût d'apprendre plus, emacs sera vraiment bien. La discussion
(qui est d'ailleurs HS...) n'est pas sur la pertinence de emacs
dans le monde des développeurs, mais bien sur la pertinence de
montrer emacs avant toute chose (ou presque).

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

editeur et compilateur

10 réponses

Veuillez sélectionner un problème