Newbies en C++ !

Fabien LE LEZ

11/08/2004 à 08:42

On Tue, 10 Aug 2004 19:07:31 +0200, Luc Hermitte
:

Avant : désolé, j'ai paumé mes archives. Elles doivent se trouver
quelque part sur un CD-ROM...

Tu veux les miennes ?

Non. Je garde des archives de fclc++ pour m'y reporter quand j'en
aurai besoin, mais en pratique je n'ai jamais le temps de fouiller
là-dedans.

--
;-)

Fabien LE LEZ

11/08/2004 à 08:43

On Tue, 10 Aug 2004 19:47:50 -0400, "Mario" :

Wow! Vive la francophonie! Quel discussion, que de mots.

C'est ça la magie d'Usenet. Et encore, t'as jamais été voir fufe
(fr.usenet.forums.evolution) ;-)

PS : merci de lire l'intégralité de la page
<http://www.giromini.org/usenet-fr/repondre.html>.

--
;-)

Fabien LE LEZ

11/08/2004 à 08:44

On Tue, 10 Aug 2004 21:03:17 +0200, "Alain Naigeon"
:

mais j'ai trouvé utiles, je dirais même éclairants,
les exemples de classes de vecteur dans les bouquins écrits par des
grand-maîtres de C++.

Je n'en doute pas. Mais de là à les étudier avant même de savoir ce
qu'est un tableau et comment on l'utilise...

--
;-)

Fabien LE LEZ

11/08/2004 à 08:59

On Tue, 10 Aug 2004 22:01:48 +0200, "Alain Naigeon"
:

Mais ça c'est vraiment un peu méprisant d'enfermer son
auditoire dans une étiquette de débutant. Enseigner à
utiliser sans savoir ce qu'on utilise, c'est évidemment
rassurant pour le prof qui est sûr d'avoir en face de lui
d'éternels débutants.

Mon dieu mon dieu...
Oui, quelqu'un qui n'a jamais touché au C++ de sa vie mérite
l'étiquette de débutant. On commence par lui enseigner les choses
simples, pour lui faire perdre cette étiquette. Et une fois que les
choses les plus simples sont assimilées, on passe à des trucs plus
compliqués.

A dix ans, j'avais déjà appris à utiliser l'anneau Z et le corps Q
sans même savoir ce qu'est un anneau ou un corps, ni que ceux-là
s'appelaient Z et Q.
Et je suis bien content qu'on m'ait enseigné les maths par ce
bout-là : non seulement j'aurais eu beaucoup de mal à l'époque à
comprendre la définition d'un anneau, mais en plus, ce que j'ai appris
le plus tôt, et donc que je maîtrise le mieux, est aussi ce qui sert
le plus souvent.

Aujourd'hui, j'ai besoin tous les jours de savoir comment utiliser
std::vector<>, ou que 2+2=4. En m'y replongeant, je pourrais pondre
une classe vector<> ou utiliser la définition de la structure
d'anneau[*], mais c'est vraiment pas quelque chose que je considère
comme fondamental.

[*] et si on vient me parler de groupes abéliens, je préviens : je
mords.

--
;-)

Fabien LE LEZ

11/08/2004 à 09:16

On Tue, 10 Aug 2004 22:01:48 +0200, "Alain Naigeon"
:

C'est là où, sans intention méchante, je dis que le but de
l'enseignement n'est pas forcément la production immédiate.

Arrête-moi si je me trompe, mais j'ai l'impression que tu considères
que la base du C++, l'information fondatrice en quelque sorte, c'est
l'agencement de la mémoire -- le fait qu'une chaîne de caractères
puisse être constituée d'octets contigus.

Quant à moi, je pense que l'information fondatrice du C++, c'est qu'un
objet ayant une sémantique de valeur fonctionne comme int.
Une fois cette "simple" phrase bien comprise, l'élève n'est plus
débutant, et il peut aller de l'avant.

Note que j'ai déjà plus ou moins condamné, dans un précédent post,
l'attitude productiviste qui consiste, par exemple, à
enseigner Visual C++ directement.

--
;-)

Fabien LE LEZ

11/08/2004 à 09:23

On 10 Aug 2004 21:07:33 +0200, Jean-Marc Bourguet :

Je ne crois pas qu'on rende service à un débutant en le
lancant à l'eau dans un marais infesté de crocodiles.

template <class Element>
void Tokenize (const std::string & chaine,
std::vector<Element>& tokens,
const std::string & delimiters)
{
tokens.clear();

std::string::size_type start=0;

while((start = chaine.find_first_not_of(delimiters, start)) !=
std::string::npos)
{
std::string::size_type end=
chaine.find_first_of (delimiters, start);
Element element;
Convertir (element, chaine.substr (start, end-start));
tokens.push_back (element);
start=end;
}
}

void Convertir (std::string& out, std::string const& s)
{
out= s;
}

void Convertir (int& i, std::string const& s);
void Convertir (unsigned int& i, std::string const& s);

--
;-)

Jean-Marc Bourguet

11/08/2004 à 09:43

"Alain Naigeon" writes:

"Jean-Marc Bourguet" a écrit dans le message news:

J'ai pas commencé les maths par Bourbaki non plus. J'ai
jamais lu Bourbaki ni même eu un cours à ce niveau de
construction à partir des bases.

Oui mais les tableaux de char ne sont pas implémentés
avec std:string, il me semble bien que c'est juste l'inverse ;-)

C'est bien ce que j'ai ecrit: je me suis servi des reels avant de
savoir comment Bourbaki les definissait (en fait je n'en ai qu'une
vague idee). De meme je prefererais enseigner d'abord les std::string
et les std::vector avant les tableaux.

Si ta seule raison de commencer par les tableaux, c'est que c'est la
base de l'implementation, pourquoi ne pas commencer encore plus bas,
avec l'assembleur? Mais l'assembleur ce n'est jamais qu'une
abstraction aussi, pour bien comprendre ce qui se passe il faut
connaitre l'architecture et la micro-architecture du processeur
(regarde c'est le meme assembleur pour les 486 et les pentiums,
pourtant l'implementation est completement differente). Oh, mais ce
n'est qu'une abstraction pour un ensemble de machine d'etats et de
circuits combinatoires ayant des fonctions complexes du genre ALU.
Mais cette vision n'est elle meme qu'une abstraction: tout ce qu'on a
ce n'est que des portes logiques et des elements sequentiels de base.
Mais non, il n'y a que des transistors et des connections. Mais ta
modelisation des transistors n'est qu'un modele bien simplifie, il
faut utiliser les modeles de spice avec une centaine de parametres et
modeliser les connections avec leurs composantes R, L et C. Mais non,
il faut appliquer les equations de Maxwell et la physique quantique.
Desole, je prefere commencer par l'abstraction la plus elevee et
ensuite voir comment ca peut etre implemente sur base d'abstraction
plus faible.

La pédagogie de TC++PL 1ère et 2ième édition est en effet bien
reconnue... pour être déficiente. Je connais quelqu'un qui a
appris le C++ dans la 1ère édition qui l'a brulée parce qu'il ne
pouvait plus la voir.

Il reste quand même tous les autres, ce qui fait beaucoup de monde
si l'on exclut les culottes courtes.

Et dans ce monde la, qui est partisant pour enseigner le C++
aujourd'hui comme ils l'ont fait alors? Stroustrup, certainement pas
(ce qui est une raison de plus pour ne pas l'invoquer). Koenig non
plus.

Je ne crois pas qu'on rende service à un débutant en le lancant à
l'eau dans un marais infesté de crocodiles.

Mais ça c'est vraiment un peu méprisant d'enfermer son auditoire
dans une étiquette de débutant. Enseigner à utiliser sans savoir ce
qu'on utilise, c'est évidemment rassurant pour le prof qui est sûr
d'avoir en face de lui d'éternels débutants. J'ai l'impression que
vous essayez de refaire aujourd'hui, en informatique, le coup du
taylorisme.

Pourquoi diable parce qu'on *commence* par quelque chose, voudrait on
se *limiter* a cette chose? Je n'ai pas pretendu que tu voulais
limiter l'enseignement du C++ a ce qui etait enseigne il y a 10 ans.
Alors, s'il te plait, ne pretends pas que je veux limiter
l'enseignement du C++ a la premiere seance de travaux diriges. Dire
que certaines difficultes peuvent attendre, ce n'est pas dire qu'il ne
faut jamais les aborder.

Ca tiens du procès d'intention.

Aucune méchanceté de ma part, au sens où j'aurais sous-entendu une
volonté délibérée, etc. Mais on peut participer à une tendance très
forte aujourd'hui, sous la pression des évènements. Et, pourquoi
pas, avec les meilleurs intentions du monde ; quel prof ne serait
pas rongé à la longue par la constatation que ses élèves sont au
chômage ?

Une des raisons (il y en a d'autres) pour lesquelles j'ai quitte
l'universite est que je me sentais coince entre des objectifs
contradictoire d'enseignement et de recherche et que je n'arrivais pas
a voir comment faire les deux correctement et que je me faisais tapper
sur les doigts parce que je priviligiais les etudiants... Quand tu
refonds un cours, tu sais que les derniers qui en « profiteront » se
retrouveront sur le marche du travail dans un minimum de 4 ou 5 ans,
souvent plus. Alors l'adequation parfaite entre ce que tu enseignes
et le marche, tu l'oublies et tu essayes d'enseigner les principes qui
te semblent importants plus que les details. Dans ce cadre, les
idiosyncrasies de la manipulation des tableaux en C++ sont plus des
details que des principes.

Et c'est vrai qu'on écrit plus vite et plus sûrement avec
std:string. Le seul problème, c'est que celui qui a inventé
std:string a reçu une formation tellement "mauvaise" qu'elle lui a
inculqué l' "insight" pour pouvoir l'inventer. Evidemment cette
formation ignorait std:string :-)

L'enseignement n'est pas oblige de faire revivre l'histoire.

Je prefere pouvoir enseigner deux concepts separement que de devoir
les meler. Parce que c'est justement quand il faut les meler qu'on se
retrouve a en donner une version exagerement simplifiee pour ne pas
dire mensongere de l'un. Combien de gens ne croient ils pas en une
equivalence entre pointeurs et tableaux par exemple?

L'enseignement est une evolution, je prefere qu'elle soit progressive
que disruptive.

C'est là où, sans intention méchante, je dis que le but de
l'enseignement n'est pas forcément la production immédiate.

La seule "productivite" immediate que je cherche, c'est de pouvoir
maintenir l'interet en pouvant proposer des exercices ne semblant pas
trop artificiels a la premiere seande de TD.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"Alain Naigeon" <anaigeon@free.fr> writes:

"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
ld6bfc.481.ln@news.bourguet.org...

J'ai pas commencé les maths par Bourbaki non plus. J'ai
jamais lu Bourbaki ni même eu un cours à ce niveau de
construction à partir des bases.

Oui mais les tableaux de char ne sont pas implémentés
avec std:string, il me semble bien que c'est juste l'inverse ;-)

C'est bien ce que j'ai ecrit: je me suis servi des reels avant de
savoir comment Bourbaki les definissait (en fait je n'en ai qu'une
vague idee). De meme je prefererais enseigner d'abord les std::string
et les std::vector avant les tableaux.

Si ta seule raison de commencer par les tableaux, c'est que c'est la
base de l'implementation, pourquoi ne pas commencer encore plus bas,
avec l'assembleur? Mais l'assembleur ce n'est jamais qu'une
abstraction aussi, pour bien comprendre ce qui se passe il faut
connaitre l'architecture et la micro-architecture du processeur
(regarde c'est le meme assembleur pour les 486 et les pentiums,
pourtant l'implementation est completement differente). Oh, mais ce
n'est qu'une abstraction pour un ensemble de machine d'etats et de
circuits combinatoires ayant des fonctions complexes du genre ALU.
Mais cette vision n'est elle meme qu'une abstraction: tout ce qu'on a
ce n'est que des portes logiques et des elements sequentiels de base.
Mais non, il n'y a que des transistors et des connections. Mais ta
modelisation des transistors n'est qu'un modele bien simplifie, il
faut utiliser les modeles de spice avec une centaine de parametres et
modeliser les connections avec leurs composantes R, L et C. Mais non,
il faut appliquer les equations de Maxwell et la physique quantique.
Desole, je prefere commencer par l'abstraction la plus elevee et
ensuite voir comment ca peut etre implemente sur base d'abstraction
plus faible.

La pédagogie de TC++PL 1ère et 2ième édition est en effet bien
reconnue... pour être déficiente. Je connais quelqu'un qui a
appris le C++ dans la 1ère édition qui l'a brulée parce qu'il ne
pouvait plus la voir.

Il reste quand même tous les autres, ce qui fait beaucoup de monde
si l'on exclut les culottes courtes.

Et dans ce monde la, qui est partisant pour enseigner le C++
aujourd'hui comme ils l'ont fait alors? Stroustrup, certainement pas
(ce qui est une raison de plus pour ne pas l'invoquer). Koenig non
plus.

Je ne crois pas qu'on rende service à un débutant en le lancant à
l'eau dans un marais infesté de crocodiles.

Mais ça c'est vraiment un peu méprisant d'enfermer son auditoire
dans une étiquette de débutant. Enseigner à utiliser sans savoir ce
qu'on utilise, c'est évidemment rassurant pour le prof qui est sûr
d'avoir en face de lui d'éternels débutants. J'ai l'impression que
vous essayez de refaire aujourd'hui, en informatique, le coup du
taylorisme.

Pourquoi diable parce qu'on *commence* par quelque chose, voudrait on
se *limiter* a cette chose? Je n'ai pas pretendu que tu voulais
limiter l'enseignement du C++ a ce qui etait enseigne il y a 10 ans.
Alors, s'il te plait, ne pretends pas que je veux limiter
l'enseignement du C++ a la premiere seance de travaux diriges. Dire
que certaines difficultes peuvent attendre, ce n'est pas dire qu'il ne
faut jamais les aborder.

Ca tiens du procès d'intention.

Aucune méchanceté de ma part, au sens où j'aurais sous-entendu une
volonté délibérée, etc. Mais on peut participer à une tendance très
forte aujourd'hui, sous la pression des évènements. Et, pourquoi
pas, avec les meilleurs intentions du monde ; quel prof ne serait
pas rongé à la longue par la constatation que ses élèves sont au
chômage ?

Une des raisons (il y en a d'autres) pour lesquelles j'ai quitte
l'universite est que je me sentais coince entre des objectifs
contradictoire d'enseignement et de recherche et que je n'arrivais pas
a voir comment faire les deux correctement et que je me faisais tapper
sur les doigts parce que je priviligiais les etudiants... Quand tu
refonds un cours, tu sais que les derniers qui en « profiteront » se
retrouveront sur le marche du travail dans un minimum de 4 ou 5 ans,
souvent plus. Alors l'adequation parfaite entre ce que tu enseignes
et le marche, tu l'oublies et tu essayes d'enseigner les principes qui
te semblent importants plus que les details. Dans ce cadre, les
idiosyncrasies de la manipulation des tableaux en C++ sont plus des
details que des principes.

Et c'est vrai qu'on écrit plus vite et plus sûrement avec
std:string. Le seul problème, c'est que celui qui a inventé
std:string a reçu une formation tellement "mauvaise" qu'elle lui a
inculqué l' "insight" pour pouvoir l'inventer. Evidemment cette
formation ignorait std:string :-)

L'enseignement n'est pas oblige de faire revivre l'histoire.

Je prefere pouvoir enseigner deux concepts separement que de devoir
les meler. Parce que c'est justement quand il faut les meler qu'on se
retrouve a en donner une version exagerement simplifiee pour ne pas
dire mensongere de l'un. Combien de gens ne croient ils pas en une
equivalence entre pointeurs et tableaux par exemple?

L'enseignement est une evolution, je prefere qu'elle soit progressive
que disruptive.

C'est là où, sans intention méchante, je dis que le but de
l'enseignement n'est pas forcément la production immédiate.

La seule "productivite" immediate que je cherche, c'est de pouvoir
maintenir l'interet en pouvant proposer des exercices ne semblant pas
trop artificiels a la premiere seande de TD.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

"Alain Naigeon" writes:

"Jean-Marc Bourguet" a écrit dans le message news:

J'ai pas commencé les maths par Bourbaki non plus. J'ai
jamais lu Bourbaki ni même eu un cours à ce niveau de
construction à partir des bases.

Oui mais les tableaux de char ne sont pas implémentés
avec std:string, il me semble bien que c'est juste l'inverse ;-)

C'est bien ce que j'ai ecrit: je me suis servi des reels avant de
savoir comment Bourbaki les definissait (en fait je n'en ai qu'une
vague idee). De meme je prefererais enseigner d'abord les std::string
et les std::vector avant les tableaux.

Si ta seule raison de commencer par les tableaux, c'est que c'est la
base de l'implementation, pourquoi ne pas commencer encore plus bas,
avec l'assembleur? Mais l'assembleur ce n'est jamais qu'une
abstraction aussi, pour bien comprendre ce qui se passe il faut
connaitre l'architecture et la micro-architecture du processeur
(regarde c'est le meme assembleur pour les 486 et les pentiums,
pourtant l'implementation est completement differente). Oh, mais ce
n'est qu'une abstraction pour un ensemble de machine d'etats et de
circuits combinatoires ayant des fonctions complexes du genre ALU.
Mais cette vision n'est elle meme qu'une abstraction: tout ce qu'on a
ce n'est que des portes logiques et des elements sequentiels de base.
Mais non, il n'y a que des transistors et des connections. Mais ta
modelisation des transistors n'est qu'un modele bien simplifie, il
faut utiliser les modeles de spice avec une centaine de parametres et
modeliser les connections avec leurs composantes R, L et C. Mais non,
il faut appliquer les equations de Maxwell et la physique quantique.
Desole, je prefere commencer par l'abstraction la plus elevee et
ensuite voir comment ca peut etre implemente sur base d'abstraction
plus faible.

La pédagogie de TC++PL 1ère et 2ième édition est en effet bien
reconnue... pour être déficiente. Je connais quelqu'un qui a
appris le C++ dans la 1ère édition qui l'a brulée parce qu'il ne
pouvait plus la voir.

Il reste quand même tous les autres, ce qui fait beaucoup de monde
si l'on exclut les culottes courtes.

Et dans ce monde la, qui est partisant pour enseigner le C++
aujourd'hui comme ils l'ont fait alors? Stroustrup, certainement pas
(ce qui est une raison de plus pour ne pas l'invoquer). Koenig non
plus.

Je ne crois pas qu'on rende service à un débutant en le lancant à
l'eau dans un marais infesté de crocodiles.

Mais ça c'est vraiment un peu méprisant d'enfermer son auditoire
dans une étiquette de débutant. Enseigner à utiliser sans savoir ce
qu'on utilise, c'est évidemment rassurant pour le prof qui est sûr
d'avoir en face de lui d'éternels débutants. J'ai l'impression que
vous essayez de refaire aujourd'hui, en informatique, le coup du
taylorisme.

Pourquoi diable parce qu'on *commence* par quelque chose, voudrait on
se *limiter* a cette chose? Je n'ai pas pretendu que tu voulais
limiter l'enseignement du C++ a ce qui etait enseigne il y a 10 ans.
Alors, s'il te plait, ne pretends pas que je veux limiter
l'enseignement du C++ a la premiere seance de travaux diriges. Dire
que certaines difficultes peuvent attendre, ce n'est pas dire qu'il ne
faut jamais les aborder.

Ca tiens du procès d'intention.

Aucune méchanceté de ma part, au sens où j'aurais sous-entendu une
volonté délibérée, etc. Mais on peut participer à une tendance très
forte aujourd'hui, sous la pression des évènements. Et, pourquoi
pas, avec les meilleurs intentions du monde ; quel prof ne serait
pas rongé à la longue par la constatation que ses élèves sont au
chômage ?

Une des raisons (il y en a d'autres) pour lesquelles j'ai quitte
l'universite est que je me sentais coince entre des objectifs
contradictoire d'enseignement et de recherche et que je n'arrivais pas
a voir comment faire les deux correctement et que je me faisais tapper
sur les doigts parce que je priviligiais les etudiants... Quand tu
refonds un cours, tu sais que les derniers qui en « profiteront » se
retrouveront sur le marche du travail dans un minimum de 4 ou 5 ans,
souvent plus. Alors l'adequation parfaite entre ce que tu enseignes
et le marche, tu l'oublies et tu essayes d'enseigner les principes qui
te semblent importants plus que les details. Dans ce cadre, les
idiosyncrasies de la manipulation des tableaux en C++ sont plus des
details que des principes.

Et c'est vrai qu'on écrit plus vite et plus sûrement avec
std:string. Le seul problème, c'est que celui qui a inventé
std:string a reçu une formation tellement "mauvaise" qu'elle lui a
inculqué l' "insight" pour pouvoir l'inventer. Evidemment cette
formation ignorait std:string :-)

L'enseignement n'est pas oblige de faire revivre l'histoire.

Je prefere pouvoir enseigner deux concepts separement que de devoir
les meler. Parce que c'est justement quand il faut les meler qu'on se
retrouve a en donner une version exagerement simplifiee pour ne pas
dire mensongere de l'un. Combien de gens ne croient ils pas en une
equivalence entre pointeurs et tableaux par exemple?

L'enseignement est une evolution, je prefere qu'elle soit progressive
que disruptive.

C'est là où, sans intention méchante, je dis que le but de
l'enseignement n'est pas forcément la production immédiate.

La seule "productivite" immediate que je cherche, c'est de pouvoir
maintenir l'interet en pouvant proposer des exercices ne semblant pas
trop artificiels a la premiere seande de TD.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet

11/08/2004 à 10:07

Richard Delorme writes:

Jean-Marc Bourguet wrote:

Un langage peut aider a utiliser des formes de controles structurees
il peut meme ne fournir que celles-ci. Il est preferable d'utiliser
un tel langage et je suis donc d'accord avec Dijstra. Ce qui
n'empeche pas qu'on puisse faire de la programmation structuree (cad
se restreindre aux structures de controles correspondantes) dans un
langage qui n'offre aucune aide.
Exactement comme on peut faire la P00 dans un lanage qui n'offre
aucune idee (le C ou meme l'assembleur) meme si c'est preferable
d'utiliser un langage qui offre des aides (le C++).

Bien sûr, mais on ne peut pas dire pour autant que le langage C est
un langage orienté objet, ni l'assembleur un langage structuré parce
qu'il est possible de difficilement programmer avec dans ces
paradigmes.

L'assembleur n'est pas un langage structure. La programmation en
assembleur se fait pourtant generalement de facon structuree.

Le C et l'assembleur sont deux langages différents exactement pour
les mêmes raisons que le C et le C++ sont deux langages différents.

Nous sommes d'accord la dessus. Ce n'est simplement pas la pratique
de la programmation structuree qui rend differentes la programmation
en C et en assembleur.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

kanze

11/08/2004 à 10:25

Alexandre Bacquart wrote in message
news:<411936aa$0$3157$...

Fabien LE LEZ wrote:

A condition de vouloir rester débutant. J'ai des doutes sur la
formation qu'apporte l'apprentissage du Basic.

Il a le mérite d'être facile à apprendre pour les autoditactes.

Quand il s'agit de la programmation, le langage n'en est qu'une partie.
Le Basic a beau être facile à apprendre, il rend les autres choses qu'il
faut savoir plus difficile.

Il apporte les bases de la programmation, de la manière la plus simple
possible.

Justement, non. Le problème avec le Basic, c'est qu'il évite les bases
de la programmation. (Les bonnes, en tout cas.)

Introduction de concepts dont peu de langages peuvent se passer : les
variables, les structures de contrôle, les fonctions...

Attention. On parle ici de Basic. Non des évolutions ultérieur. La Basic
n'a pas de véritable notion de fonction, ni des structures de données.
Et ses structures de contrôle sont extrèmement limitées. C'est pourquoi
les maîtres l'ont condamné si fortements.

D'après ce que j'ai entendu, Visual Basic n'a du Basic que le nom. Je ne
le connais pas. Je ne le juge donc pas. Sauf pour les deux grands
défauts que je le connais -- le nom (il faut éviter le Basic à tout prix
si on veut apprendre à programmer), et la manque de portabilité (je
travaille surtout sur des machines Unix). Pour quelqu'un qui veut
simplement bidouiller, je ne sais pas si ce sont des critiques
importantes. (S'il espère un jour aussi pouvoir bidouiller sur un Mac ou
sous Linux, la manque de portabilité EST un défaut à prendre en compte.)

Pour le bidouillage, personellement, j'utilise le shell de Unix, avec
les outils classiques Unix -- y compris sous Windows, grace à CygWin.
Mais ce choix est beaucoup lié à mon histoire personnelle, et le type de
choses que je bidouille (rien avec GNU, par exemple) ; je ne crois pas
que ce soit la bonne solution pour tout le monde.

J'ai entendu parler de deux possibilités portables : Python et TCL/TK.
Je ne les connais ni l'un ni l'autre, mais j'en ai entendu du bien,
surtout de Python. Alors, ce sont éventuellement des possibilités.

Aussi d'après ce que j'ai entendu dire, les langages de script d'Excel
ou de Word sont en fait du VB. Si on veut interagir avec ce genre de
programme, c'est probable que VB soit le meilleur choix.

Enfin, une chose est certaine : si le but n'est que des petits
bidouillages, et qu'on ne connaît pas déjà bien le C++, le C++ n'est pas
un bon choix. C'est un langage conçu pour des professionnels -- il
permet beaucoup, mais il impose une certaine discipline pour l'utiliser
efficacement. Dans une certaine mésure, c'est vrai pour tous les
langages, quand il s'agit de développer un système professionnel d'une
certaine taille. Mais pour des petits bidouillages, le coût de la mise
en oeuvre initial risque d'être énorme.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alexandre Bacquart <tek512@hotmail.com> wrote in message
news:<411936aa$0$3157$626a14ce@news.free.fr>...

Fabien LE LEZ wrote:

A condition de vouloir rester débutant. J'ai des doutes sur la
formation qu'apporte l'apprentissage du Basic.

Il a le mérite d'être facile à apprendre pour les autoditactes.

Quand il s'agit de la programmation, le langage n'en est qu'une partie.
Le Basic a beau être facile à apprendre, il rend les autres choses qu'il
faut savoir plus difficile.

Il apporte les bases de la programmation, de la manière la plus simple
possible.

Justement, non. Le problème avec le Basic, c'est qu'il évite les bases
de la programmation. (Les bonnes, en tout cas.)

Introduction de concepts dont peu de langages peuvent se passer : les
variables, les structures de contrôle, les fonctions...

Attention. On parle ici de Basic. Non des évolutions ultérieur. La Basic
n'a pas de véritable notion de fonction, ni des structures de données.
Et ses structures de contrôle sont extrèmement limitées. C'est pourquoi
les maîtres l'ont condamné si fortements.

D'après ce que j'ai entendu, Visual Basic n'a du Basic que le nom. Je ne
le connais pas. Je ne le juge donc pas. Sauf pour les deux grands
défauts que je le connais -- le nom (il faut éviter le Basic à tout prix
si on veut apprendre à programmer), et la manque de portabilité (je
travaille surtout sur des machines Unix). Pour quelqu'un qui veut
simplement bidouiller, je ne sais pas si ce sont des critiques
importantes. (S'il espère un jour aussi pouvoir bidouiller sur un Mac ou
sous Linux, la manque de portabilité EST un défaut à prendre en compte.)

Pour le bidouillage, personellement, j'utilise le shell de Unix, avec
les outils classiques Unix -- y compris sous Windows, grace à CygWin.
Mais ce choix est beaucoup lié à mon histoire personnelle, et le type de
choses que je bidouille (rien avec GNU, par exemple) ; je ne crois pas
que ce soit la bonne solution pour tout le monde.

J'ai entendu parler de deux possibilités portables : Python et TCL/TK.
Je ne les connais ni l'un ni l'autre, mais j'en ai entendu du bien,
surtout de Python. Alors, ce sont éventuellement des possibilités.

Aussi d'après ce que j'ai entendu dire, les langages de script d'Excel
ou de Word sont en fait du VB. Si on veut interagir avec ce genre de
programme, c'est probable que VB soit le meilleur choix.

Enfin, une chose est certaine : si le but n'est que des petits
bidouillages, et qu'on ne connaît pas déjà bien le C++, le C++ n'est pas
un bon choix. C'est un langage conçu pour des professionnels -- il
permet beaucoup, mais il impose une certaine discipline pour l'utiliser
efficacement. Dans une certaine mésure, c'est vrai pour tous les
langages, quand il s'agit de développer un système professionnel d'une
certaine taille. Mais pour des petits bidouillages, le coût de la mise
en oeuvre initial risque d'être énorme.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Alexandre Bacquart wrote in message
news:<411936aa$0$3157$...

Fabien LE LEZ wrote:

A condition de vouloir rester débutant. J'ai des doutes sur la
formation qu'apporte l'apprentissage du Basic.

Il a le mérite d'être facile à apprendre pour les autoditactes.

Quand il s'agit de la programmation, le langage n'en est qu'une partie.
Le Basic a beau être facile à apprendre, il rend les autres choses qu'il
faut savoir plus difficile.

Il apporte les bases de la programmation, de la manière la plus simple
possible.

Justement, non. Le problème avec le Basic, c'est qu'il évite les bases
de la programmation. (Les bonnes, en tout cas.)

Introduction de concepts dont peu de langages peuvent se passer : les
variables, les structures de contrôle, les fonctions...

Attention. On parle ici de Basic. Non des évolutions ultérieur. La Basic
n'a pas de véritable notion de fonction, ni des structures de données.
Et ses structures de contrôle sont extrèmement limitées. C'est pourquoi
les maîtres l'ont condamné si fortements.

D'après ce que j'ai entendu, Visual Basic n'a du Basic que le nom. Je ne
le connais pas. Je ne le juge donc pas. Sauf pour les deux grands
défauts que je le connais -- le nom (il faut éviter le Basic à tout prix
si on veut apprendre à programmer), et la manque de portabilité (je
travaille surtout sur des machines Unix). Pour quelqu'un qui veut
simplement bidouiller, je ne sais pas si ce sont des critiques
importantes. (S'il espère un jour aussi pouvoir bidouiller sur un Mac ou
sous Linux, la manque de portabilité EST un défaut à prendre en compte.)

Pour le bidouillage, personellement, j'utilise le shell de Unix, avec
les outils classiques Unix -- y compris sous Windows, grace à CygWin.
Mais ce choix est beaucoup lié à mon histoire personnelle, et le type de
choses que je bidouille (rien avec GNU, par exemple) ; je ne crois pas
que ce soit la bonne solution pour tout le monde.

J'ai entendu parler de deux possibilités portables : Python et TCL/TK.
Je ne les connais ni l'un ni l'autre, mais j'en ai entendu du bien,
surtout de Python. Alors, ce sont éventuellement des possibilités.

Aussi d'après ce que j'ai entendu dire, les langages de script d'Excel
ou de Word sont en fait du VB. Si on veut interagir avec ce genre de
programme, c'est probable que VB soit le meilleur choix.

Enfin, une chose est certaine : si le but n'est que des petits
bidouillages, et qu'on ne connaît pas déjà bien le C++, le C++ n'est pas
un bon choix. C'est un langage conçu pour des professionnels -- il
permet beaucoup, mais il impose une certaine discipline pour l'utiliser
efficacement. Dans une certaine mésure, c'est vrai pour tous les
langages, quand il s'agit de développer un système professionnel d'une
certaine taille. Mais pour des petits bidouillages, le coût de la mise
en oeuvre initial risque d'être énorme.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze

11/08/2004 à 10:40

Pierre Maurette wrote in message
news:...

Fabien LE LEZ a écrit:

On Tue, 10 Aug 2004 08:59:10 +0200, Pierre Maurette
:

Certes, mais la norme C++ elle-même se réfère à celle du C.

Peut-être. Mais la norme n'est pas un cours, mais une référence,
d'ailleurs plus écrite pour les éditeurs de compilateurs que pour les
programmeurs.

Oooops. Moi qui vous pensais favorable au port du voile en
informatique, voilà ti pas que vous nous boudez LA NORME...

On parlait de l'apprentissage. Tu ne lis pas le code de la route pour
apprendre à conduire. D'ailleurs, je doute que même la plupart des
conducteurs expérimentés n'ont jamais lu le code de la route.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Newbies en C++ !

10 réponses

Veuillez sélectionner un problème