Bonjour, ayant 14 ans et m'int=E9ressant beaucoup a l'informatique,
j'ai essay=E9 d'apprendre le plus de chose cot=E9 hardware enfin y a
toujours des trucs nouveaux mais ... Maintenant je veux me lancer dans
la partie software et commencer par les langages de programmation. Je
voudrais savoir par quel langage commencer ? On m'a conseill=E9 Ocaml ou
Python.
Moi j'ai débuté en ASM-6502, puis Pascal, puis C, puis C++. Si c'était à refaire, je sauterais les 2 premières étapes, même si Pascal a été assez formateur pour apprendre le solfège. Mais c'était il y a 25 ans. A la limite, aujourd'hui je pourrais recommander un truc comme Delphi. Y'a pire comme clickodrome. Et passer de Pascal à C n'est pas très pénible.
Ben j'aurais presque tendance à dire que de nos jours on peut même sauter la troisième étapes.
Quand à commencer par delphi et passer au C plus tard ça me semble plutôt pas mal aussi.
Bertrand Lenoir-Welter wrote:
Moi j'ai débuté en ASM-6502, puis Pascal, puis C, puis C++. Si c'était à
refaire, je sauterais les 2 premières étapes, même si Pascal a été assez
formateur pour apprendre le solfège. Mais c'était il y a 25 ans. A la
limite, aujourd'hui je pourrais recommander un truc comme Delphi. Y'a
pire comme clickodrome. Et passer de Pascal à C n'est pas très pénible.
Ben j'aurais presque tendance à dire que de nos jours on peut même
sauter la troisième étapes.
Quand à commencer par delphi et passer au C plus tard ça me semble
plutôt pas mal aussi.
Moi j'ai débuté en ASM-6502, puis Pascal, puis C, puis C++. Si c'était à refaire, je sauterais les 2 premières étapes, même si Pascal a été assez formateur pour apprendre le solfège. Mais c'était il y a 25 ans. A la limite, aujourd'hui je pourrais recommander un truc comme Delphi. Y'a pire comme clickodrome. Et passer de Pascal à C n'est pas très pénible.
Ben j'aurais presque tendance à dire que de nos jours on peut même sauter la troisième étapes.
Quand à commencer par delphi et passer au C plus tard ça me semble plutôt pas mal aussi.
Bertrand Lenoir-Welter
batyann811 :
Ben j'aurais presque tendance à dire que de nos jours on peut même sauter la troisième étapes.
Apprendre directement le C++ sans connaître le C ?
Bigre, je dois être vieux-jeu, mais je n'ai pas les mêmes tendances que vous. Drôle d'époque...
batyann811 :
Ben j'aurais presque tendance à dire que de nos jours on peut même
sauter la troisième étapes.
Apprendre directement le C++ sans connaître le C ?
Bigre, je dois être vieux-jeu, mais je n'ai pas les mêmes tendances que
vous. Drôle d'époque...
Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
Bertrand Lenoir-Welter
Damienmou :
Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
Pour faire très simple - et merci d'avance aux ayatollahs de ne pas me taper dessus - C++ est un sur-ensemble de C qui permet d'aller plus loin. Ce qui fait qu'un programme écrit en C sera accepté par un compilateur C++ et fonctionnera de la même façon. Donc C++ reprend la syntaxe de C en y ajoutant quelques épices pour que les plats soient plus agréables à cuisiner. Je ne vais pas entrer dans les détails de ces épices qui ne parleraient pas à quelqu'un qui de toute façon ne pratique pas le C. Disons juste qu'au départ, le C est un langage dit "structuré", dont l'architecture est héritée de Pascal, Modula et d'autres que j'ignore : on crée des fonctions (ou des "procédures" en Pascal) qui sont des sous-ensembles de programmes qui permettent de faire un bout de traitement limité mais bien encadré. Et à force de faire des sous-ensembles, on finit par avoir un ensemble complet. Ces sous-ensembles traitent des données, soit locales au sous-ensemble, soit globales à tout le programme. On a un point de départ du programme, et des points de sortie (plus les sorties involontaires). Un programme C ressemble à une arborescence de fonctions qui s'appellent les unes les autres vers le haut à partir du point de départ. Ces fonctions ne sont pas imbriquées les unes dans les autres (contrairement à Pascal, on ne peut pas mettre une petite fonction à l'intérieur d'une plus grosse). Les fonctions ne sont pas groupées par famille et c'est donc au programmeur de s'organiser pour retrouver son chemin.
Avec C++, on s'est dit que la syntaxe de base du C était sympathique mais, comme les programmes gagnaient en complexité et donc perdaient en lisibilité, on a décidé qu'il était encore plus malin de regrouper les fonctions et certaines données qui traitent des choses communes. Ce qu'on appelle des "objets", ou "classes". Un objet est un ensemble bien circonscrit qui contient des fonctions et des données internes. Le programmeur le construit en général sous la forme d'une "boîte noire" qui présente à l'extérieur un certain nombre de fonctionnalités accessibles au reste du programme, mais les autres programmeurs ne veulent pas savoir comment ça se débrouille à l'intérieur du moment que ça marche. Donc c'est beaucoup plus modulaire, avec des cloisons plutôt étanches entre les sous-ensembles du programme. Et le fait d'avoir un sous-ensemble très modulaire et indépendant du reste peut permettre d'autant mieux de le réutiliser pour d'autres programmes selon le bon vieil adage : "Quand ça marche, ne touchez à rien."
Exemple bateau : je crée une application graphique avec un bouton sur lequel on peut cliquer. En C, je vais avoir des données sans doute regroupées dans une structure (un premier pas vers C++, mais on ne peut y mettre que des données), comme les coordonnées du rectangle qui contient le bouton, son état (cliqué, relâché, grisé), sa couleur, le texte qui est dessus, etc. Par ailleurs, je vais écrire des fonctions (donc des bouts de code actif) qui feront réagir ce bouton : l'afficher en bosse ou en creux ou en grisé selon son état, dire si la souris est dessus, dire dans quel état il est, etc. Donc j'ai d'une part des données - ou variables - et d'autre part des fonctions - du code, le tout plus ou moins disséminé selon l'humeur du programmeur.
En C++, je vais créer un objet "MonBouton", et les autres programmeurs du projet n'ont pas à savoir comment il fonctionne. Simplement, je leur propose des données et des fonctions accessibles via l'identificateur de ce bouton (qu'on appelle "instance"). S'ils créent un "MonBouton" quelque part dans leur propre partie de programme, celui-ci leur fournira de quoi dialoguer : les fonctions sont DANS l'objet. Ce ne sont plus des fonctions auquelles je dois dire sur quoi elles agissent. "MonBouton" est une boîte étanche, mais avec son mode d'emploi. On n'est pas des sauvages. Et s'il a besoin de fonctions à usage strictement internes, ça ne regarde que moi et je ne les mets pas dans le mode d'emploi.
Bon, tout ça, c'est très résumé. C++ va ensuite beaucoup beaucoup plus loin, notamment dans les notions de réutilisabilité et donc de portabilité, mais mieux vaut ne pas entrer dans les détails techniques. Si tu fais du C, au bout d'un moment tu trouveras naturel de passer à C++ et même tu te demanderas comment tu as fait pour t'en passer aussi longtemps. Mais au moins, tu sauras pourquoi tu fais du C++ et tu en tireras d'autant mieux toute la substantifique moelle.
J'ajoute qu'avec un peu de mauvaise volonté, on peut très bien arriver faire de la programmation pas modulaire, pas réutilisable et pas portable en C++, et inversement, avec de la bonne volonté, on peut faire des quasi-boîtes noires très portable en C-tout-court. L'outil ne donne pas le talent ; il est juste là pour aider.
Damienmou :
Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre
Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
Pour faire très simple - et merci d'avance aux ayatollahs de ne pas me
taper dessus - C++ est un sur-ensemble de C qui permet d'aller plus
loin. Ce qui fait qu'un programme écrit en C sera accepté par un
compilateur C++ et fonctionnera de la même façon. Donc C++ reprend la
syntaxe de C en y ajoutant quelques épices pour que les plats soient
plus agréables à cuisiner. Je ne vais pas entrer dans les détails de ces
épices qui ne parleraient pas à quelqu'un qui de toute façon ne pratique
pas le C. Disons juste qu'au départ, le C est un langage dit
"structuré", dont l'architecture est héritée de Pascal, Modula et
d'autres que j'ignore : on crée des fonctions (ou des "procédures" en
Pascal) qui sont des sous-ensembles de programmes qui permettent de
faire un bout de traitement limité mais bien encadré. Et à force de
faire des sous-ensembles, on finit par avoir un ensemble complet. Ces
sous-ensembles traitent des données, soit locales au sous-ensemble, soit
globales à tout le programme. On a un point de départ du programme, et
des points de sortie (plus les sorties involontaires). Un programme C
ressemble à une arborescence de fonctions qui s'appellent les unes les
autres vers le haut à partir du point de départ. Ces fonctions ne sont
pas imbriquées les unes dans les autres (contrairement à Pascal, on ne
peut pas mettre une petite fonction à l'intérieur d'une plus grosse).
Les fonctions ne sont pas groupées par famille et c'est donc au
programmeur de s'organiser pour retrouver son chemin.
Avec C++, on s'est dit que la syntaxe de base du C était sympathique
mais, comme les programmes gagnaient en complexité et donc perdaient en
lisibilité, on a décidé qu'il était encore plus malin de regrouper les
fonctions et certaines données qui traitent des choses communes. Ce
qu'on appelle des "objets", ou "classes". Un objet est un ensemble bien
circonscrit qui contient des fonctions et des données internes. Le
programmeur le construit en général sous la forme d'une "boîte noire"
qui présente à l'extérieur un certain nombre de fonctionnalités
accessibles au reste du programme, mais les autres programmeurs ne
veulent pas savoir comment ça se débrouille à l'intérieur du moment que
ça marche. Donc c'est beaucoup plus modulaire, avec des cloisons plutôt
étanches entre les sous-ensembles du programme. Et le fait d'avoir un
sous-ensemble très modulaire et indépendant du reste peut permettre
d'autant mieux de le réutiliser pour d'autres programmes selon le bon
vieil adage : "Quand ça marche, ne touchez à rien."
Exemple bateau : je crée une application graphique avec un bouton sur
lequel on peut cliquer. En C, je vais avoir des données sans doute
regroupées dans une structure (un premier pas vers C++, mais on ne peut
y mettre que des données), comme les coordonnées du rectangle qui
contient le bouton, son état (cliqué, relâché, grisé), sa couleur, le
texte qui est dessus, etc. Par ailleurs, je vais écrire des fonctions
(donc des bouts de code actif) qui feront réagir ce bouton : l'afficher
en bosse ou en creux ou en grisé selon son état, dire si la souris est
dessus, dire dans quel état il est, etc. Donc j'ai d'une part des
données - ou variables - et d'autre part des fonctions - du code, le
tout plus ou moins disséminé selon l'humeur du programmeur.
En C++, je vais créer un objet "MonBouton", et les autres programmeurs
du projet n'ont pas à savoir comment il fonctionne. Simplement, je leur
propose des données et des fonctions accessibles via l'identificateur de
ce bouton (qu'on appelle "instance"). S'ils créent un "MonBouton"
quelque part dans leur propre partie de programme, celui-ci leur
fournira de quoi dialoguer : les fonctions sont DANS l'objet. Ce ne sont
plus des fonctions auquelles je dois dire sur quoi elles agissent.
"MonBouton" est une boîte étanche, mais avec son mode d'emploi. On n'est
pas des sauvages. Et s'il a besoin de fonctions à usage strictement
internes, ça ne regarde que moi et je ne les mets pas dans le mode d'emploi.
Bon, tout ça, c'est très résumé. C++ va ensuite beaucoup beaucoup plus
loin, notamment dans les notions de réutilisabilité et donc de
portabilité, mais mieux vaut ne pas entrer dans les détails techniques.
Si tu fais du C, au bout d'un moment tu trouveras naturel de passer à
C++ et même tu te demanderas comment tu as fait pour t'en passer aussi
longtemps. Mais au moins, tu sauras pourquoi tu fais du C++ et tu en
tireras d'autant mieux toute la substantifique moelle.
J'ajoute qu'avec un peu de mauvaise volonté, on peut très bien arriver
faire de la programmation pas modulaire, pas réutilisable et pas
portable en C++, et inversement, avec de la bonne volonté, on peut faire
des quasi-boîtes noires très portable en C-tout-court. L'outil ne donne
pas le talent ; il est juste là pour aider.
Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
Pour faire très simple - et merci d'avance aux ayatollahs de ne pas me taper dessus - C++ est un sur-ensemble de C qui permet d'aller plus loin. Ce qui fait qu'un programme écrit en C sera accepté par un compilateur C++ et fonctionnera de la même façon. Donc C++ reprend la syntaxe de C en y ajoutant quelques épices pour que les plats soient plus agréables à cuisiner. Je ne vais pas entrer dans les détails de ces épices qui ne parleraient pas à quelqu'un qui de toute façon ne pratique pas le C. Disons juste qu'au départ, le C est un langage dit "structuré", dont l'architecture est héritée de Pascal, Modula et d'autres que j'ignore : on crée des fonctions (ou des "procédures" en Pascal) qui sont des sous-ensembles de programmes qui permettent de faire un bout de traitement limité mais bien encadré. Et à force de faire des sous-ensembles, on finit par avoir un ensemble complet. Ces sous-ensembles traitent des données, soit locales au sous-ensemble, soit globales à tout le programme. On a un point de départ du programme, et des points de sortie (plus les sorties involontaires). Un programme C ressemble à une arborescence de fonctions qui s'appellent les unes les autres vers le haut à partir du point de départ. Ces fonctions ne sont pas imbriquées les unes dans les autres (contrairement à Pascal, on ne peut pas mettre une petite fonction à l'intérieur d'une plus grosse). Les fonctions ne sont pas groupées par famille et c'est donc au programmeur de s'organiser pour retrouver son chemin.
Avec C++, on s'est dit que la syntaxe de base du C était sympathique mais, comme les programmes gagnaient en complexité et donc perdaient en lisibilité, on a décidé qu'il était encore plus malin de regrouper les fonctions et certaines données qui traitent des choses communes. Ce qu'on appelle des "objets", ou "classes". Un objet est un ensemble bien circonscrit qui contient des fonctions et des données internes. Le programmeur le construit en général sous la forme d'une "boîte noire" qui présente à l'extérieur un certain nombre de fonctionnalités accessibles au reste du programme, mais les autres programmeurs ne veulent pas savoir comment ça se débrouille à l'intérieur du moment que ça marche. Donc c'est beaucoup plus modulaire, avec des cloisons plutôt étanches entre les sous-ensembles du programme. Et le fait d'avoir un sous-ensemble très modulaire et indépendant du reste peut permettre d'autant mieux de le réutiliser pour d'autres programmes selon le bon vieil adage : "Quand ça marche, ne touchez à rien."
Exemple bateau : je crée une application graphique avec un bouton sur lequel on peut cliquer. En C, je vais avoir des données sans doute regroupées dans une structure (un premier pas vers C++, mais on ne peut y mettre que des données), comme les coordonnées du rectangle qui contient le bouton, son état (cliqué, relâché, grisé), sa couleur, le texte qui est dessus, etc. Par ailleurs, je vais écrire des fonctions (donc des bouts de code actif) qui feront réagir ce bouton : l'afficher en bosse ou en creux ou en grisé selon son état, dire si la souris est dessus, dire dans quel état il est, etc. Donc j'ai d'une part des données - ou variables - et d'autre part des fonctions - du code, le tout plus ou moins disséminé selon l'humeur du programmeur.
En C++, je vais créer un objet "MonBouton", et les autres programmeurs du projet n'ont pas à savoir comment il fonctionne. Simplement, je leur propose des données et des fonctions accessibles via l'identificateur de ce bouton (qu'on appelle "instance"). S'ils créent un "MonBouton" quelque part dans leur propre partie de programme, celui-ci leur fournira de quoi dialoguer : les fonctions sont DANS l'objet. Ce ne sont plus des fonctions auquelles je dois dire sur quoi elles agissent. "MonBouton" est une boîte étanche, mais avec son mode d'emploi. On n'est pas des sauvages. Et s'il a besoin de fonctions à usage strictement internes, ça ne regarde que moi et je ne les mets pas dans le mode d'emploi.
Bon, tout ça, c'est très résumé. C++ va ensuite beaucoup beaucoup plus loin, notamment dans les notions de réutilisabilité et donc de portabilité, mais mieux vaut ne pas entrer dans les détails techniques. Si tu fais du C, au bout d'un moment tu trouveras naturel de passer à C++ et même tu te demanderas comment tu as fait pour t'en passer aussi longtemps. Mais au moins, tu sauras pourquoi tu fais du C++ et tu en tireras d'autant mieux toute la substantifique moelle.
J'ajoute qu'avec un peu de mauvaise volonté, on peut très bien arriver faire de la programmation pas modulaire, pas réutilisable et pas portable en C++, et inversement, avec de la bonne volonté, on peut faire des quasi-boîtes noires très portable en C-tout-court. L'outil ne donne pas le talent ; il est juste là pour aider.
Vincent Burel
je ferais plus court que Bertrand ! qui a plutot bien expliqué ce que le ++ ajoute au 'C'.
Pour ma part je dirais que le C++ est une forme évoluée du 'C', d'organisation du code qui permet de formaliser plus strictement des objects (class) sous le controle du compilateur. Personnellement, je trouve ce formalisme limitant et générateur de bordel. De plus, dans la pratique la réutilisation et la portabilité du C++ n'est pas meilleurs que pour du 'C' (d'ailleurs ces deux notions dépendent plus du programmeur que du langage lui-même).
Parfois, je travaille sur du code C++, ou avec des gens qui développent en C++ , et je constate que le ++ génére (presque par nature pour ainsi dire) deux gros problèmes dans le développement d'application (et je parle d'appli pro de bonne taille) : - Un défaut de maitrise des séquences d'appel. - Un défaut de maitrise des conditions initiales. Ce qui fait que souvent, tu constates que le programmeur C++ est incapable de te dire si telle métode est appelée avant ou après telle autre, et qu'il ne sait pas dire quelle objet initialise tel champ d'un classe. Et quand tu viens du "C", tu trouves ça proprement hallucinant.
Programmer, c'est d'abord maitriser les conditions initiales et la séquence d'appels... VB
"Damienmou" wrote in message news: Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
je ferais plus court que Bertrand ! qui a plutot bien expliqué ce que le ++
ajoute au 'C'.
Pour ma part je dirais que le C++ est une forme évoluée du 'C',
d'organisation du code qui permet de formaliser plus strictement des objects
(class) sous le controle du compilateur.
Personnellement, je trouve ce formalisme limitant et générateur de bordel.
De plus, dans la pratique la réutilisation et la portabilité du C++ n'est
pas meilleurs que pour du 'C' (d'ailleurs ces deux notions dépendent plus du
programmeur que du langage lui-même).
Parfois, je travaille sur du code C++, ou avec des gens qui développent en
C++ , et je constate que le ++ génére (presque par nature pour ainsi dire)
deux gros problèmes dans le développement d'application (et je parle d'appli
pro de bonne taille) :
- Un défaut de maitrise des séquences d'appel.
- Un défaut de maitrise des conditions initiales.
Ce qui fait que souvent, tu constates que le programmeur C++ est incapable
de te dire si telle métode est appelée avant ou après telle autre, et qu'il
ne sait pas dire quelle objet initialise tel champ d'un classe. Et quand tu
viens du "C", tu trouves ça proprement hallucinant.
Programmer, c'est d'abord maitriser les conditions initiales et la séquence
d'appels...
VB
"Damienmou" <damienordi@orange.fr> wrote in message
news:a3ca0e4d-cb43-4910-8fbf-3504bb2d5f0e@z23g2000prd.googlegroups.com...
Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre
Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
je ferais plus court que Bertrand ! qui a plutot bien expliqué ce que le ++ ajoute au 'C'.
Pour ma part je dirais que le C++ est une forme évoluée du 'C', d'organisation du code qui permet de formaliser plus strictement des objects (class) sous le controle du compilateur. Personnellement, je trouve ce formalisme limitant et générateur de bordel. De plus, dans la pratique la réutilisation et la portabilité du C++ n'est pas meilleurs que pour du 'C' (d'ailleurs ces deux notions dépendent plus du programmeur que du langage lui-même).
Parfois, je travaille sur du code C++, ou avec des gens qui développent en C++ , et je constate que le ++ génére (presque par nature pour ainsi dire) deux gros problèmes dans le développement d'application (et je parle d'appli pro de bonne taille) : - Un défaut de maitrise des séquences d'appel. - Un défaut de maitrise des conditions initiales. Ce qui fait que souvent, tu constates que le programmeur C++ est incapable de te dire si telle métode est appelée avant ou après telle autre, et qu'il ne sait pas dire quelle objet initialise tel champ d'un classe. Et quand tu viens du "C", tu trouves ça proprement hallucinant.
Programmer, c'est d'abord maitriser les conditions initiales et la séquence d'appels... VB
"Damienmou" wrote in message news: Alors deja ce n'est pas une passion d'ado. J'ai commencé a apprendre Ocaml. Mais apres le C ou le C++ c'est quoi la différence ?
