Discussion :

[koala01]

entierement d'accord, j'ai appris en faisant des "methodes numeriques" en C,
c'etait super. le C++ est venu par apres et j'en ai vu les avantages.

Oui, mais, à coté de cela, tu as sans doutes (allez, disons plutôt peut-être ) perdu énormément de temps à chercher le moyen de faire certaines choses que les connaissances théoriques t'auraient clairement facilitées.

Le problème, lorsque l'on n'a même jamais entendu un terme que la théorie explique, c'est que... l'on ne sait même pas ce que l'on doit chercher, ce qui ne facilite pas vraiment la recherche d'une solution, et qui occasionne, de facto, une perte de temps considérable.

Si tu avais eu la théorie avant de te trouver dans une situation dans laquelle tu en as besoin "en extrême urgence" (la plupart des développements doivent être faits "pour hier" ), tu aurais sans doute gagné plusieurs heures en pouvant te consacrer "au noeud du problème" plutôt qu'à la recherche de "la notion manquante"

[pseudocode]

Un simple exemple : C++ autorise explicitement le fait d'avoir 65 000 caractères sur une seule ligne de code (c'est un des "minimum" assurés dans une des appendice de la norme).

Pourtant, je serais surpris de croiser un seul développeur (tous langages confondus) qui soit prêt à accepter une telle situation.
Le problème, c'est que si tu apprends une limitation comme étant la règle générale, tu auras énormément de mal à "changer ton fusil d'épaule" lorsque quelqu'un viendra avec... la règle générale.

Hum... Je n'ai jamais dit que les limitations d'un langage étaient les seules règles a appliquer. J'ai parlé de "bonnes pratiques" : la longueur d'une ligne ou d'un source en fait partie... et je ne pense pas que la bonne pratique dans ce cas est d'aller aux limites absolues.

Or, lorsque l'on apprend la théorie "parce que cela colle avec ce que l'on veut apprendre du langage", on apprend généralement... la théorie "adaptée" au langage envisagé.

Aucun javaiste n'aurait l'idée d'envisager un héritage multiple, simplement, parce que... c'est interdit en java.

Et pourtant, il n'y a rien qui interdise l'héritage multiple dans la théorie OO

Bah, c'est plutot en accord avec mon raisonnement alors. Connaitre *seulement* la théorie OO ne t'aidera pas a comprendre pourquoi tu ne peux pas coder un héritage multiple en Java.

Tu sembles oublier que "le programme qui marche" n'est jamais que la toute dernière étape d'un processus beaucoup plus long, qui commence par l'analyse des besoins et qui continue... en se posant la question de savoir comment apporter une solution correcte et cohérente à ces besoins.

Cela signifierait-il pour toi que la "conception" fait partie de la théorie ? Auquel cas je comprends mieux ton raisonnement.

Pour moi ce n'est pas le cas. L'analyse, la conception sont des disciplines tout comme le sont l'implémentation ou le test. Ces disciplines sont donc soumises la meme bivalence théorie/pratique.

Tu peux connaitre la théorie de l'analyse objet/systémique/sémantique/....
Tu peux connaitre la pratique de ces méthodes d'analyses

Mon avis étant que le choix le plus pragmatique est de ne pas s'embêter avec la théorie pure, et de ne pas foncer à l'aveugle non plus. C'est pour cela que, pour moi, les bonnes pratiques sont un cadre formel suffisant pour garantir l'accomplissement de tâches dans une discipline.

Par exemple, concevoir une BdD en respectant la 3NF est une bonne pratique. Dans la plupart des cas (par exemple un site php+mysql) , savoir le pourquoi du comment de la théorie relative a cette pratique ne servira pas à concevoir un meilleur programme.

Personnellement, je ne connais personne qui maitrise la "théorie" de toute la chaine des disciplines nécessaires à la réalisation d'un projet (depuis l'étude d'opportunité jusqu'au CRM). Ça n'empeche pas d'avoir des personnes qui mènent des projets à terme... heureusement.

[TNT89]

En ce qui concerne l'algorithmie, je suis en CPGE et pour la plupart de mes camarades, ils n'avaient jamais écrit une seule ligne de code, et pourtant ils ont réussi à suivre et à comprendre les premiers cours qui concernait les boucles, le calcul de complexité (temporelle).

En même temps c'est assez normal vu que c'est une pensée qui se rapproche de la démonstration mathématique et pour des MP (je suppose ) c'est un peu le nerf de la guerre...

Moi je suis d'avis qu'il y a du bon à être confronté à un problème nécéssitant un algorithme spécifique pour sa résolution, sans le connaître auparavant. Cela permet de mieux en juger les enjeux et les diverses techniques employées.

Personnellement, j'ai appris par moi même le C puis sa légère couche objet et enfin le C++ sans avoir jamais fait d'algorithmie avant. Et je ne regrette rien pour la raison ci-avant : cela m'a permis de mieux juger un algorithme, ses possibles applications etc. lorsqu'on me l'a présenté.

[koala01]

Hum... Je n'ai jamais dit que les limitations d'un langage étaient les seules règles a appliquer. J'ai parlé de "bonnes pratiques" : la longueur d'une ligne ou d'un source en fait partie... et je ne pense pas que la bonne pratique dans ce cas est d'aller aux limites absolues.

C'était surtout un "exemple par l'absurde" pour montrer que toute pratique admise n'est pas forcément bonne à prendre

Bah, c'est plutot en accord avec mon raisonnement alors. Connaitre *seulement* la théorie OO ne t'aidera pas a comprendre pourquoi tu ne peux pas coder un héritage multiple en Java.

Cela te permettra de le comprendre plus facilement, ne serait-ce que parce que la notion de "losange de la mort" ne te sera pas inconnue.

Il "suffira" d'expliquer de toute classe hérite implicitement de Object et que l'héritage multiple finira donc inexorablement de la sorte pour que tout prenne forme

Cela signifierait-il pour toi que la "conception" fait partie de la théorie ? Auquel cas je comprends mieux ton raisonnement.

Je ne dis pas cela...

Je dis que conception fait partie intégrante du même processus que l'écriture du code ou les tests unitaires et qui a, comme finalité, la production d'une application qui fait ce que l'on attend d'elle quand on l'en attend.

Et je dis en substance qu'il pourrait suffire de donner les "règles de conversion" de la logique imaginée (plus quelques règles de "mise en forme" )à une dactylo pour qu'elle fournisse un code qui compile et qui fait ce que l'on attend de lui.

Bon, d'accord, là je pousse l'exagération un peu loin

Pour moi ce n'est pas le cas. L'analyse, la conception sont des disciplines tout comme le sont l'implémentation ou le test. Ces disciplines sont donc soumises la meme bivalence théorie/pratique.

Je suis tout à fait d'accord avec le fait que toutes les étapes du processus sont autant de disciplines différentes, mais il ne faut pas oublier toutes les "zones floues" où les différentes disciplines doivent se rejoindre:

Si tu ne transmets pas correctement ton analyse des besoins au concepteur, il ne faudra pas trop s'étonner si... la conception elle-même devient, si pas bancale, au moins... inappropriée (ou "pas tout à fait appropriée")

Une fois que le concepteur aura fini de faire tous ses beaux diagrammes, de cas d'utilisation pour voir avec l'analyste des besoins si cela correspond, de classes, d'objets et d'activité, si le concepteur ne donne pas l'algorithme à respecter pour une fonction donnée, c'est l'implémenteur qui devra y réfléchir, en espérant que le concepteur ait au minimum bien fait son boulot en précisant les points importants.

La personne qui doit s'occuper des tests unitaires ne pourra aussi correctement faire son travail que... si elle sait exactement ce que l'on attend des différentes classes et fonctions

Finalement, toutes ces disciplines clairement différentes ont, malgré tout, toujours une "base commune" avec au moins une des discipline "connexe"

Le problème, c'est que pour que "tout roule" correctement, il faut que la théorie applicable à ces "points de jonction" soit connue... des deux parties

Mon avis étant que le choix le plus pragmatique est de ne pas s'embêter avec la théorie pure, et de ne pas foncer à l'aveugle non plus.

Je n'ai jamais dit qu'il fallait absorber l'équivalent l'intégralité de l'encyclopédie universelle de théorie avant de passer à la pratique...

J'ai dit qu'il y a certaines bases théoriques générales dont la connaissance devrait être considérée comme un pré requis.

Et pour éviter toute confusion, les bases générales peuvent parfaitement changer en fonction de la discipline envisagée

C'est pour cela que, pour moi, les bonnes pratiques sont un cadre formel suffisant pour garantir l'accomplissement de tâches dans une discipline.

Mais les bonnes pratiques ne sont, au final, que des corollaires à la théorie... (je parle ici exclusivement des "bonnes pratiques" et de "la théorie" d'ordre tout à fait générales )

Du coup, si tu comprends la théorie, tu comprendras aussi les bonnes pratiques, que l'on n'aura même pas besoin de te marteler, simplement parce... qu'elles "iront de soi"...

Par exemple, concevoir une BdD en respectant la 3NF est une bonne pratique. Dans la plupart des cas (par exemple un site php+mysql) , savoir le pourquoi du comment de la théorie relative a cette pratique ne servira pas à concevoir un meilleur programme.

Non, mais concevoir une base de données cohérente et correcte sera l'un des aspects qui permettront... d'assurer la qualité de l'ensemble du produit.

Personnellement, je ne connais personne qui maitrise la "théorie" de toute la chaine des disciplines nécessaires à la réalisation d'un projet (depuis l'étude d'opportunité jusqu'au CRM).

Je ne demande pas cela non plus...

Je demande "juste" que, pour une discipline donnée, la personne qui en a la charge connaisse la théorie qui est en rapport avec la discipline envisagée.

Dans le sens où le débat est tiré, à la base, d'une discussion dans laquelle on parlait de l'apprentissage d'un langage, il est logique que je plaide en faveur de la connaissance des "principes généraux" qui régissent... l'ensemble des langages proches ou apparentés au langage envisagé.

Tout comme je plaiderais en faveur de l'apprentissage prioritaire des principes généraux qui régissent l'ensemble des bases de données qui quelqu'un venait me demander des conseils pour apprendre à... utilise MsSQL, Oracle ou MySQL.

Mais, j'insiste là dessus, il n'est pas question d'abrutir l'étudiant à force de l'assommer avec de la théorie "juste pour faire de la théorie".

Il est "juste" question de lui fournir les "outils minimum" indépendants du langage ou du SGBDR (ou de n'importe quel autre système relatif à la discipline envisagée) avant de s'attaquer à un langage, un SGBDR ou... une méthode quelconque donnée.

Ça n'empeche pas d'avoir des personnes qui mènent des projets à terme... heureusement.

J'en suis bien conscient... et je dirais que c'est encore heureux

Mais il n'empêche que tu auras beaucoup plus de chances, si pas de fournir le projet à terme, au moins de le fournir sans trop dépasser les délais si chaque intervenant "maitrise" la théorie de base qui s'applique à sa propre discipline

[mptijr]

je suis d'accord avec phryos, il est plus simple de programmer en C++ lorsqu'on a les bases du C.

je pense même qu'il en est de même pour JAVA quand connait C++.

C'est vrai que ce n'est pas une nécessité mais on apprend plus vite

[koala01]

je suis d'accord avce phryos, il est plus simple de programmer en C++ lorsqu'on a les bases du C.

je pense même qu'il en est de même pour JAVA quand connait C++.

C'est vrai que ce n'est pas une nécessité mais on apprend plus vite

Cela revient à dire qu'il faut apprendre l'espagnol avant d'essayer d'apprendre l'italien qui est, lui-même le passage obligé pour arriver à apprendre le chinois...

Cela n'a strictement aucun sens !!!

Je suis d'accord que C et C++ partagent une syntaxe sensiblement identique, mais ce n'est absolument pas la syntaxe qui est la partie la plus difficile à apprendre dans un langage de programmation...

L'intérêt qu'il y aurait à apprendre C avant C++ ne tient absolument pas à la relation qu'il y a entre ces deux langages, bien au contraire, cette relation forte est plutôt du genre bloquante dans l'apprentissage de C++ car on se heurte souvent à des réactions proche de "oui, mais ne C, ça se fait comme cela"...

Non, l'intérêt qu'il pourrait y avoir à apprendre C avant C++ serait l'espoir que l'apprentissage de C en profite pour apprendre à l'étudiant... les fameux "principe de base" qui régissent la programmation procédurale qui me tiennent tant à coeur.

C++ est, effectivement, sympa pour permettre une mise en pratique "douce" des principes de programmation générique parce qu'il accepte plusieurs paradigmes, dont la programmation procédurale et la programmation OO.

De la même manière, la proposition d'apprendre C++ avant java n'est réellement intéressante que dans le sens où... C++ permet d'introduire progressivement la notion de programmation orientée objets, justement parce qu'il permet de mélanger l'OO et la programmation procédurale.

Mais, encore une fois, il est possible de donner les bases de la programmation orientées objets sans, forcément, passer par un langage spécifique.

[pseudocode]

Je demande "juste" que, pour une discipline donnée, la personne qui en a la charge connaisse la théorie qui est en rapport avec la discipline envisagée.

Dans le sens où le débat est tiré, à la base, d'une discussion dans laquelle on parlait de l'apprentissage d'un langage, il est logique que je plaide en faveur de la connaissance des "principes généraux" qui régissent... l'ensemble des langages proches ou apparentés au langage envisagé.

Tout comme je plaiderais en faveur de l'apprentissage prioritaire des principes généraux qui régissent l'ensemble des bases de données qui quelqu'un venait me demander des conseils pour apprendre à... utilise MsSQL, Oracle ou MySQL.

Mais, j'insiste là dessus, il n'est pas question d'abrutir l'étudiant à force de l'assommer avec de la théorie "juste pour faire de la théorie".

Il est "juste" question de lui fournir les "outils minimum" indépendants du langage ou du SGBDR (ou de n'importe quel autre système relatif à la discipline envisagée) avant de s'attaquer à un langage, un SGBDR ou... une méthode quelconque donnée.

Ce que tu décris ressemble plus à de la conceptualisation que de la théorie, auquel cas je suis d'accord.

C'est à dire avoir un minimum de maitrise sur un modèle abstrait et généraliste d'une technologie/paradigme/langage. Bref savoir des trucs comme ceci ou comme cela.

C'est différent pour moi de la théorie "mathématique" qui permet de définir, manipuler et valider des axiomes, règles, ou propriétés.

[epsilon68]

Oui, mais, à coté de cela, tu as sans doutes (allez, disons plutôt peut-être ) perdu énormément de temps à chercher le moyen de faire certaines choses que les connaissances théoriques t'auraient clairement facilitées.

la theorie dans les methodes numeriques, c'est un algo non?
bein l'implementer sert à voir pourquoi c'est lent, a le tester, le debugger etc

si tu parles de la theorie des languages, la theorie de la compilation, etc,
bein oui c'est bien, l'appliquer c'est super mieux.
Dans mes cours de compilation, combien de gens ont souffler en disant que ca servait à rien. On ne comprend pas non plus bien le LALR(1) mais bon on l'accepte. Quand tu prends Bison/Flex, la c'est cool et ca te permet de bien mieux suivre et comprendre les cours theoriques.

[koala01]

Ce que tu décris ressemble plus à de la conceptualisation que de la théorie, auquel cas je suis d'accord.

Le terme théorie est effectivement peut être mal choisi, mais je crois que le terme "conceptualisation" n'est pas plus adapté car... trop restrictif.

Une grosse part de ce que je plaide que les débutants apprenne tient, effectivement, de concepts, mais cela va néanmoins un peu plus loin dans le sens où il me semble intéressant qu'il connaissent aussi une ou plusieurs manière de représenter un algorithme:

Je ne parle pas du flow chart, qui n'est pas adapté à la programmation structurée, si ce n'est pour l'ASM, ni du pseudo code car je suis effectivement d'accord avec le fait que, si c'est pour écrire du "faux code", autant en écrire tout de suite du vrai

Mais je parle en revanche du nassi-schneiderman, malgré tout le mal que certains peuvent en penser ou du Jackson qui est particulièrement intéressant lorsqu'il s'agit de "déblayer le terrain" pour une gestion de ruptures, par exemple.

Le tout sans oublier la "règle de base" pour la récursivité : "toujours tester le cas de base"

Je peux t'assurer que la mise au point d'un algorithme cohérent avant de se lancer sur le clavier n'est jamais une perte de temps:

A partir du moment où tu utilise "la bonne méthode" (j'aime particulièrement le nassi-schneiderman, parce qu'il permet de représenter l'ensemble des concepts utilisés en programmation strucutrée séquentielle ) pour le représenter et que tu as déjà vérifié qu'il était correct (en "jouant" à te faire "aussi bête qu'un processeur"), je peux te garantir:

1. que la traduction en code source est automatique (j'ai même un projet en cours qui tend à permettre à l'ordinateur de générer du code source automatiquement sur base d'une logique introduite par l'utilisateur )
2. que la première compilation réussie (comprend: après avoir viré les inévitables fautes d'attention) permettra d'obtenir le résultat attendu.

Tu gagnera donc énormément de temps à l'étape qui t'en fait classiquement perdre le plus: le débuggage, et la phase de tests unitaires se transformera en "pure formalité" dans le sens où elle ne te servira plus qu'à vérifier que tous les aspects ont été pris en compte

Ca, c'est pour la partie "séquentielle" des différents langages.

Lorsque l'on aborde un langage OO, il me semble opportun d'y ajouter quelque concepts (composition Vs agrégation, héritage, polymorphisme, substituabilité, etc), quelques règles / principes ou loi (parmis lesquels Demeter et Liskov) et, si possible, une "méthode quelconque" permettant de représenter les relations entre les différents types d'objet (hein , quoi j'ai parlé d'UML )

Le fait est que, tôt ou tard, il seront confrontés au besoin de "garder une trace" de leurs algorithme ou des relations qui existent entre leurs classes, voire, même, qu'il devront pouvoir... communiquer sur le sujet avec d'autres personnes (soit parce que ces personnes leur transmettent justement des algorithme ou des diagrammes de classes, soit pour permettre aux gens de "savoir ce qui est fait")

Mais comme cet ensemble de "règles" (le mot est un peu fort, mais je n'en trouve pas d'autres ) ne pourra que les aider à assurer une qualité supplémentaire dans leurs développements futurs, autant les leur donner "le plus tôt possible"

Nous sommes bien d'accord sur le fait que cette prose ne vaut que pour ceux qui envisagent d'apprendre... un langage de programmation, indépendamment des autres disciplines envisageables, pour lesquels on trouve aussi une série de "choses" qu'il est intéressant de connaitre indépendamment de la technologie utilisée

la theorie dans les methodes numeriques, c'est un algo non?
bein l'implementer sert à voir pourquoi c'est lent, a le tester, le debugger etc

Mais, avant de l'implémenter, il faut... le créer (ou le copier)...

Je te renvoies à ma prose qui suit une réponse à white_tentacle il y a quelques messages: il ne faut pas donner plus de pouvoir au langage ou au compilateur qu'ils n'en ont réellement

si tu parles de la theorie des languages, la theorie de la compilation, etc,
bein oui c'est bien, l'appliquer c'est super mieux.

Dans mes cours de compilation, combien de gens ont souffler en disant que ca servait à rien. On ne comprend pas non plus bien le LALR(1) mais bon on l'accepte. Quand tu prends Bison/Flex, la c'est cool et ca te permet de bien mieux suivre et comprendre les cours theoriques.

La théorie des langages et de la compilation est, certes très intéressante (du moins pour ceux qu'elle intéresse), mais, effectivement, totalement inutile pour qui n'utilisera jamais bison et flex (ou outils similaires)

Il ne sera jamais mauvais d'expliquer les différentes étapes que suit un compilateur, mais cela rentre beaucoup plus dans le cadre de... l'apprentissage du langage et, quoi qu'il en soit, ca rentre souvent dans la catégorie de "la culture générale, pour mémoire"

Je le répète, je ne dit absolument pas qu'il faut assommer l'étudiant avec l'ensemble de la théorie se rapportant de près ou de loin (et surtout de loin, d'ailleurs ) aux langages de programmation: cela deviendrait rapidement barbant et n'aurait aucun intérêt.

Je l'ai déjà dit, il ne sert à rien d'arriver avec les algorithmes de tri à bulles, de tri par insertion, de A* et de dijkstra ou avec les différents DP existants et d'assommer l'étudiant avec...

Par contre, comme le but de l'apprentissage de ces pré requis est, justement, de lui "apprendre à réfléchir" et que la meilleure manière d'y arriver est, encore, de le "bombarder d'exercices", il est des plus intéressant de le mettre face à des situations qui le mèneront à... les découvrir par lui-même (juste avant de lui dire le nom de l'algorithme ou du DP )

Ce en faveur de quoi je plaide, c'est que l'on apprenne à l'étudiant à réfléchir à la logique qu'il veut transmettre à l'ordinateur grâce à n'importe quel langage.

Je plaide pour qu'il finisse par réfléchir de manière systématique à

je pars de tel point et je veux arriver à tel autre point :
1- De quelles (structures de) données ai-je besoin
2- Quelle logique me permettra d'obtenir le résultat escompté en limitant au mieux les risques d'erreur

A partir du moment où il a pris l'habitude de se poser la question et, surtout, d'y apporter une réponse "estimée correcte", l'apprentissage d'un langage se fait finalement beaucoup plus simplement et peut se limiter à:

• quelques règles de grammaire et de syntaxe
• quelques mots clé
• quelques particularité du langage
• quelques fonctions existantes dans le langage

[pseudocode]

+1 avec ton post.

Le terme théorie est effectivement peut être mal choisi, mais je crois que le terme "conceptualisation" n'est pas plus adapté car... trop restrictif.

Oui, j'en suis conscient mais c'est le mieux que j'ai pu trouver.

[mptijr]

Cela revient à dire qu'il faut apprendre l'espagnol avant d'essayer d'apprendre l'italien qui est, lui-même le passage obligé pour arriver à apprendre le chinois...

Cela n'a strictement aucun sens !!!

Je suis d'accord que C et C++ partagent une syntaxe sensiblement identique, mais ce n'est absolument pas la syntaxe qui est la partie la plus difficile à apprendre dans un langage de programmation...

L'intérêt qu'il y aurait à apprendre C avant C++ ne tient absolument pas à la relation qu'il y a entre ces deux langages, bien au contraire, cette relation forte est plutôt du genre bloquante dans l'apprentissage de C++ car on se heurte souvent à des réactions proche de "oui, mais ne C, ça se fait comme cela"...

Non, l'intérêt qu'il pourrait y avoir à apprendre C avant C++ serait l'espoir que l'apprentissage de C en profite pour apprendre à l'étudiant... les fameux "principe de base" qui régissent la programmation procédurale qui me tiennent tant à coeur.

C++ est, effectivement, sympa pour permettre une mise en pratique "douce" des principes de programmation générique parce qu'il accepte plusieurs paradigmes, dont la programmation procédurale et la programmation OO.

De la même manière, la proposition d'apprendre C++ avant java n'est réellement intéressante que dans le sens où... C++ permet d'introduire progressivement la notion de programmation orientée objets, justement parce qu'il permet de mélanger l'OO et la programmation procédurale.

Mais, encore une fois, il est possible de donner les bases de la programmation orientées objets sans, forcément, passer par un langage spécifique.

On ne se comprend pas peut être, je n'affirme pas qu'il est nécessaire d'apprendre le C avant le C++ mais je dis que celui connait déjà le C apprendra plus vite le C++ car son problème se limitera plus à l'apprentissage des Concepts de la POO.

[white_tentacle]

On ne se comprend pas peut être, je n'affirme pas qu'il est nécessaire d'apprendre le C avant le C++ mais je dis que celui connait déjà le C apprendra plus vite le C++ car son problème se limitera plus à l'apprentissage des Concepts de la POO.

Dans ce cas, mieux vaut faire du pascal, ça évitera de faire prendre de mauvaises habitudes liées à C.

La syntaxe, c'est du sucre, ça n'est pas un problème à apprendre (sauf pour haskell ). Le plus long quand on apprend un nouveau langage, c'est d'apprendre la bibliothèque standard (noms de classes/fonctions, etc).

[Hellwing]

Le terme théorie est effectivement peut être mal choisi, mais je crois que le terme "conceptualisation" n'est pas plus adapté car... trop restrictif.

Une grosse part de ce que je plaide que les débutants apprenne tient, effectivement, de concepts, mais cela va néanmoins un peu plus loin dans le sens où il me semble intéressant qu'il connaissent aussi une ou plusieurs manière de représenter un algorithme:

Je ne parle pas du flow chart, qui n'est pas adapté à la programmation structurée, si ce n'est pour l'ASM, ni du pseudo code car je suis effectivement d'accord avec le fait que, si c'est pour écrire du "faux code", autant en écrire tout de suite du vrai

Mais je parle en revanche du nassi-schneiderman, malgré tout le mal que certains peuvent en penser ou du Jackson qui est particulièrement intéressant lorsqu'il s'agit de "déblayer le terrain" pour une gestion de ruptures, par exemple.

Le tout sans oublier la "règle de base" pour la récursivité : "toujours tester le cas de base"

Je peux t'assurer que la mise au point d'un algorithme cohérent avant de se lancer sur le clavier n'est jamais une perte de temps:

A partir du moment où tu utilise "la bonne méthode" (j'aime particulièrement le nassi-schneiderman, parce qu'il permet de représenter l'ensemble des concepts utilisés en programmation strucutrée séquentielle ) pour le représenter et que tu as déjà vérifié qu'il était correct (en "jouant" à te faire "aussi bête qu'un processeur"), je peux te garantir:

1. que la traduction en code source est automatique (j'ai même un projet en cours qui tend à permettre à l'ordinateur de générer du code source automatiquement sur base d'une logique introduite par l'utilisateur )
2. que la première compilation réussie (comprend: après avoir viré les inévitables fautes d'attention) permettra d'obtenir le résultat attendu.

Tu gagnera donc énormément de temps à l'étape qui t'en fait classiquement perdre le plus: le débuggage, et la phase de tests unitaires se transformera en "pure formalité" dans le sens où elle ne te servira plus qu'à vérifier que tous les aspects ont été pris en compte

Ca, c'est pour la partie "séquentielle" des différents langages.

Lorsque l'on aborde un langage OO, il me semble opportun d'y ajouter quelque concepts (composition Vs agrégation, héritage, polymorphisme, substituabilité, etc), quelques règles / principes ou loi (parmis lesquels Demeter et Liskov) et, si possible, une "méthode quelconque" permettant de représenter les relations entre les différents types d'objet (hein , quoi j'ai parlé d'UML )

Le fait est que, tôt ou tard, il seront confrontés au besoin de "garder une trace" de leurs algorithme ou des relations qui existent entre leurs classes, voire, même, qu'il devront pouvoir... communiquer sur le sujet avec d'autres personnes (soit parce que ces personnes leur transmettent justement des algorithme ou des diagrammes de classes, soit pour permettre aux gens de "savoir ce qui est fait")

Mais comme cet ensemble de "règles" (le mot est un peu fort, mais je n'en trouve pas d'autres ) ne pourra que les aider à assurer une qualité supplémentaire dans leurs développements futurs, autant les leur donner "le plus tôt possible"

Nous sommes bien d'accord sur le fait que cette prose ne vaut que pour ceux qui envisagent d'apprendre... un langage de programmation, indépendamment des autres disciplines envisageables, pour lesquels on trouve aussi une série de "choses" qu'il est intéressant de connaitre indépendamment de la technologie utilisée
Mais, avant de l'implémenter, il faut... le créer (ou le copier)...

Je te renvoies à ma prose qui suit une réponse à white_tentacle il y a quelques messages: il ne faut pas donner plus de pouvoir au langage ou au compilateur qu'ils n'en ont réellement
La théorie des langages et de la compilation est, certes très intéressante (du moins pour ceux qu'elle intéresse), mais, effectivement, totalement inutile pour qui n'utilisera jamais bison et flex (ou outils similaires)

Il ne sera jamais mauvais d'expliquer les différentes étapes que suit un compilateur, mais cela rentre beaucoup plus dans le cadre de... l'apprentissage du langage et, quoi qu'il en soit, ca rentre souvent dans la catégorie de "la culture générale, pour mémoire"

Je le répète, je ne dit absolument pas qu'il faut assommer l'étudiant avec l'ensemble de la théorie se rapportant de près ou de loin (et surtout de loin, d'ailleurs ) aux langages de programmation: cela deviendrait rapidement barbant et n'aurait aucun intérêt.

Je l'ai déjà dit, il ne sert à rien d'arriver avec les algorithmes de tri à bulles, de tri par insertion, de A* et de dijkstra ou avec les différents DP existants et d'assommer l'étudiant avec...

Par contre, comme le but de l'apprentissage de ces pré requis est, justement, de lui "apprendre à réfléchir" et que la meilleure manière d'y arriver est, encore, de le "bombarder d'exercices", il est des plus intéressant de le mettre face à des situations qui le mèneront à... les découvrir par lui-même (juste avant de lui dire le nom de l'algorithme ou du DP )

Ce en faveur de quoi je plaide, c'est que l'on apprenne à l'étudiant à réfléchir à la logique qu'il veut transmettre à l'ordinateur grâce à n'importe quel langage.

Je plaide pour qu'il finisse par réfléchir de manière systématique à


A partir du moment où il a pris l'habitude de se poser la question et, surtout, d'y apporter une réponse "estimée correcte", l'apprentissage d'un langage se fait finalement beaucoup plus simplement et peut se limiter à:

• quelques règles de grammaire et de syntaxe
• quelques mots clé
• quelques particularité du langage
• quelques fonctions existantes dans le langage

Bonjour,

Bien que je n'ai jamais codé en C++, je tiens à faire un petit passage éclair pour donner mon point de vue.

Je suis de l'avis de Koala dans tout son discours, mais je distingue tout de même la théorie de l'algorithmique.
La théorie, pour moi est constituée de l'ensemble de règles, design patterns, algorithmes reconnus, pièges à éviter (comme oublier d'incrémenter l'incrément de boucle), ce qu'est un langage (dans les grandes lignes), etc.
Cela permet de comprendre ce qu'on va faire. Je ne suis pas partisant du "Tu fais d'abord et je t'explique après ce que tu viens de faire".

En ce qui concerne l'algorithmique, c'est déjà une mise en pratique avant même de passer par les langages. Elle est juste plus généraliste que les langages. Quelqu'un qui sait programmer dans un langage saura s'adapter à tous les autres (du même paradigme, j'entends), du moins c'est ce qu'on m'a appris durant mes études.
Et comme dis Koala01, comprendre la logique simpliste du compilateur a son importance dans la formation.

Je ne suis par contre pas d'accord en ce qui concerne le pseudo-code. Je l'utilise régulièrement parce qu'il permet d'écrire les idées en toutes lettres. Certes, c'est un peu plus long à écrire que coder, mais il permet au moins de mettre les idées clairement en place et de comprendre rapidement plusieurs mois après ce qu'il fait. D'un autre côté, n'ayant pas pratiqué les autres méthodes (sauf rarement le flow chart, mais son intérêt est limité dans ce que je développe) mon avis n'est peut être pas très objectif.

PS : Koala01, j'aime beaucoup te lire car tes propos sont à la fois ouverts et constructifs, mais ta manie de mettre des points de suspension pour rajouter un semblant de suspens dans chacune de tes phrases est très pénible

[phryos]

En fait pour ma petite intervention (ce que je n'ai pas faite ressortir assez) il faut prendre en compte que si tu prends un langage qui n'encadre pas assez au départ les étudiants quand tu essaies de leur faire apprendre des notions informatiques comme les espaces mémoires, la pile, les tris. Une manière de raisonner, de construire ces programmes. Tu te retrouves donc avec une 20 d'étudiants qui développe une appli qui arrête pas de planter parce que leur code compile mais fait pas ce qu'il demande (style if (c=1) exit alors qu'initialement il devait comprendre des principes et des concepts.
Je l'ai vécu en séance de TP que je dirigeais, tu es très facilement débordé sur des petites bêtises de codage qui n'arrive pas quand tu utilises un langage qui t'encadre bien.
Le langage n'est qu'un instrument pour comprendre le développement, une fois que tu as les bases, tu passes à des langages qui permettent d'aller plus loin dans les notions. Le C et le C++ rentre dans la seconde catégorie.

[mptijr]

Dans ce cas, mieux vaut faire du pascal, ça évitera de faire prendre de mauvaises habitudes liées à C.

La syntaxe, c'est du sucre, ça n'est pas un problème à apprendre (sauf pour haskell ). Le plus long quand on apprend un nouveau langage, c'est d'apprendre la bibliothèque standard (noms de classes/fonctions, etc).

si tu pense que connaitre le Pascal faciliterait l'apprentissage du C++, je n'y vois aucun inconvénient.

[koala01]

Je ne suis par contre pas d'accord en ce qui concerne le pseudo-code.

J'apporte ma petite précision en ce qui concerne le pseudo code.

Je n'ai rien contre le pseudo code en tant que technique permettant de présenter un algorithme en tant que tel, simplement, il tient parmi les techniques que j'apprécie personnellement le moins.

Ce n'est, évidemment qu'un avis strictement personnel qui est essentiellement du au fait que j'utilise d'autres techniques qui me "correspondent mieux".

Mais bon, j'ai en partie justifié mon avis, et je laisse bien évidemment tout le monde libre d'avoir son avis à lui, même s'il prend le mien à rebours

[Chessmaster1966]

Non !!!
La théorie doit être mise en pratique immédiatement.
Lire tout un chapitre sur la notion de variable (par exemple) sans utiliser au fur et à mesure un compilateur pour tester différents cas est une hérésie !
Si telle chose devait se produire, à coup sûr, cela sera une perte de temps et d'énergie et au bout du compte l'abandon total de l'apprentissage du langage.

Pour ce qui est d'apprendre Le C avant le C++ pour mieux comprendre ce dernier est une hérésie. Soit on fait du C ou soit on fait du C++.
Pour le débutant qui veut apprendre le C++ il est nullement besoin et surtout préférable de ne pas apprendre le C en préalable.

Le C++ est un langage à part entière, il est facile il faut juste être serieux et persevérent et commencer depuis le début sans se hâter à passer au chapitre suivant si certains détails non pas été compris.

Au fur et à mesure de l'avancer dans un chapitre mettre immédiatement en pratique les choses vues. En somme il faut être avec le livre devant son compilateur et bosser. Ecrire, écrire encore écrire des centaines de lignes de code tester différent cas de figure pour un même problème, etc... voilà la clé de la réussite en programmation.

Brian Kernighan inventeur du C a dit cela : "Programming is learned writing programs." (Apprendre à programmer c'est écrire du code).

[Chessmaster1966]

Pour ma part je pense que l'algorithmie ne sert à rien si ne n'est que de perdre du temps. Il est préférable d'écrire directement. Mais pour cela il a une condition sinequanon, c'est de connâître parfaitement le langage C++.

Par contre il est nécessaire à la place de l'algorithmie de définir sur un papier le problème que l'on veut traiter. Comme par exemple :

Problème :
Invite l'utilisateur à saisir trois valeurs correspondant
respectivement a l'operation(+, -, *, /)
operande et suivi du deuxieme operande.
Puis affiche le resultat de l'operation sous la forme ( "2 + 2 = 4").
Si l'operation est inconnue un message indiquant l'erreur
s'affichera.

et voilà la solution (code) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
#include <iostream>
#include <string>
 
using namespace std;
 
 
 
int main()
{
 
    cout << "-------------------------------------------------------------------------\n";
    cout << "Program :\n\n";
    cout << "\tInvite l'utilisateur a saisir trois valeurs correspondant\n";
    cout << "\trespectivement a l'operation(+, -, *, /) suivi du premier\n";
    cout << "\toperande et suivi du deuxieme operande.\n";
    cout << "\tPuis affiche le resultat de l'operation sous forme ("2 + 2 = 4").\n";
    cout << "\tSi l'operation est inconnue un message indiquant l'erreur\n";
    cout << "\ts'affichera.\n";
    cout << "-------------------------------------------------------------------------\n\n";
 
 
 
    cout << "Choisissez une operation (+, -, *, /) : ";
    string str1;
    cin >> str1;
 
    cout << "Entrez deux nombres : ";
    double op1;
    cin >> op1;
    double op2;
    cin >> op2;
 
    //Insère une ligne vierge.
    cout << '\n';
 
    //Affiche l'opération et son résultat demandés.
    if(str1 == "+")
        cout << op1 << " + " << op2 << " = " << op1+op2;
    else if(str1 == "-")
        cout << op1 << " - " << op2 << " = " << op1-op2;
    else if(str1 ==  "*")
        cout << op1 << " * " << op2 << " = " << op1*op2;
    else if(str1 == "/")
        cout << op1 << " / " << op2 << " = " << op1/op2;
    else
        //Si l'opération ne correspond pas à l'une des quatres oprérations
        //de base, l'ordinateur annonce à l'utilisateur qu'il ne la connaît pas.
        cout << "Je ne connais pas cette operation !";
 
    system("pause");
 
   return 0;
 
}

Voilà une manière efficace de programmer, je ne suis donc pas partisan de l'algorithmie.

[hiura]

Pour ma part je pense que l'algorithmie ne sert à rien si ne n'est que de perdre du temps. Il est préférable d'écrire directement. Mais pour cela il a une condition sinequanon, c'est de connâître parfaitement le langage C++.

C'est tellement gros que j'arrive pas à savoir si t'es ironique ou non.

Pour mon expérience perso, j'avais un «petit» projet à réaliser en C++ pour mes cours pré-universitaire dont le titre était : «résolution d'équation et d'inéquation de degré quelconque». A l'époque j'étais bien naïf et j'ai opté pour me lancer directement dans le code, et plus bêtement dans le design de la GUI avant de savoir mes réelles ressources (c'est pas le bon mot, mais il veut pas se décoller du bout de ma langue). Ben ça m'a coûter de tout recommencer à zéro avec un plan plus précis!

[pseudocode]

Pour ma part je pense que l'algorithmie ne sert à rien si ne n'est que de perdre du temps. Il est préférable d'écrire directement. Mais pour cela il a une condition sinequanon, c'est de connâître parfaitement le langage C++.

Je n'aurais qu'une chose à dire :