Discussion :

[koala01]

Je n'ai pas abandonné mon char*, mais ça ne m'empêche pas d'utiliser AnsiString. De la même façon, j'utilise des TList et aussi des listes chainées maison (j'utilise Borland).

Ce n'était nullement une attaque personnelle, car, je peux t'assurer que tu es loin d'être le seul à être particulièrement attaché à tes char*

Le bon point pour toi, c'est que tu manipules (je présumes) aussi souvent que possible les TList et les AnsiString de borland, ce qui revient à peu de chose près au même que les std::list ou les std:w)string.

Mais l'utilisation d'une TList ou d'une AnsiString (resp: std::list ou std:w)string) présente quoi qu'il en soit d'énormes avantages en termes de sécurité par rapport à une liste créée "de toute pièce" ou à la gestion d'une chaine de caractères "C style"

Par contre, il ne semble pas que cela gène un développeur C++ d'utiliser la même classe pour des points et des vecteurs. Je n'imagine pas qu'un développeur en C fasse la même erreur.

Cela me gène personnellement au plus haut point, si, comme je le subodore, tu parle d'un point et d'un vecteur du point de vue mathématique.

Ceci dit, une développeur C ne fera sans doute pas l'erreur principalement parce qu'il... manque un certain nombre de mécanismes qui permettraient de la faire

[NoIdea]

Je n'ai pas bien compris ton dernier post :

Parce que tout les y incite, essentiellement...

Incite à échapper à cette règle ?

Que fais tu de mon

Cependant, il faut avoir une idée de comment écrire le code pour savoir si ce que l'on fait "tient la route"

qui implique qu'il faut un peu de pratique pour faire de la théorie ?

[NoIdea]

Justement, ce que je conseille, c'est d'apprendre comment déterminer la "moins mauvaise" logique possible avant même d'écrire le code, en sachant que l'ordinateur ne se posera jamais la question de savoir s'il est effectivement intéressant d'incrémenter A à tel moment précis du code ou s'il n'est pas préférable de le faire deux instructions plus tôt ou plus tard.

On est d'accord mis a part sur le fait que :

-je pense qu'il faut un peu d'expérience pour faire de la théorie
-tu penses que l'on doit faire de la théorie tout de suite même sans l'expérience car sinon on acquiert de mauvaises habitudes

[koala01]

Je n'ai pas bien compris ton dernier post :


Incite à échapper à cette règle ?

Mais oui, tout les y incite...

Il n'y a qu'à lire la grosse majorité des tutos et des cours présents sur le net pour se rendre compte que, dés qu'un principe de programmation est énoncé, il est suivi par... un exemple dans le langage étudié.

Que fais tu de mon qui implique qu'il faut un peu de pratique pour faire de la théorie ?

Non, justement... on ne te laissera pas rouler en voiture (pour pratiquer) avant d'avoir fait preuve de ta connaissance du code de la route (la théorie)... Il devrait en aller de même en programmation

Tu n'a absolument aucun besoin de pratiquer pour apprendre la théorie, bien loin de là

J'admets cependant que la pratique permet, effectivement, de fixer la théorie et peut même s'avérer intéressante pour introduire les règles particulières, mais c'est, justement... une règle particulière de l'apprentissage

[NoIdea]

Non, justement... on ne te laissera pas rouler en voiture (pour pratiquer) avant d'avoir fait preuve de ta connaissance du code de la route (la théorie)... Il devrait en aller de même en programmation

Il y a cependant une différence importante :
Pour la majorité des gens, ils ont déjà vu une voiture, marché dans la rue ou même conduit un vélo. Ils ont donc "pratiquer" le code de la route mais pas en tant que voiture. Penses-tu pouvoir comprendre le code de la route si tu n'avais jamais vu de voiture/moto/vélo de ta vie ?

Alors que en programmation, les débutants arrivent avec aucune expérience/pratique du langage.

[koala01]

On est d'accord mis a part sur le fait que :

-je pense qu'il faut un peu d'expérience pour faire de la théorie

Je suis réellement et intimement persuadé du contraire, mais je ne vais pas reprendre toute l'argumentation que j'ai déjà pu donner dans mes réponses précédentes

-tu penses que l'on doit faire de la théorie tout de suite même sans l'expérience car sinon on acquiers de mauvaises habitudes

Je confirme, je persiste et je signe...

Si tu n'a pas le soutien de la théorie au moment où tu commence à pratiquer, il n'y a strictement aucun garde fou pour t'empêcher d'apprendre quelque chose "qui ne devrait absolument pas se faire" mais qui est "si facile par rapport aux bonnes habitudes".

Tu n'es donc, purement et simplement, pas armé pour te rendre compte que cette pratique est, décidément, une mauvaise habitude, et, comme c'est "si facile de la sorte", tu t'y accrochera comme un morpion à un poil pubien, même lorsque l'on te fera la remarque à ce sujet.

C'est souvent la raison pour laquelle les mauvaises habitudes ont la peau si dure: parce qu'elles présentent une telle facilité ressentie par rapport à ce qui est conseillé / indiqué qu'on se demande réellement pourquoi "perdre son temps" autrement

[PowerM]

Je sens un débat très passionnant en train de faire ( si ce n'est pas déjà le cas), mais malheureusement, je ne comprends rien du tout dans vos propos... x'D

la seule chose que j'ai compris, c'est qu'il n'est pas obligatoire d'apprendre en premier le langage C avant le C++. On peut très bien faire le contraire (non?).

J'ai pris la décision d'apprendre d'abord le C++ puis le C après, pour avoir une meilleur connaissance et mieux distinguer ces deux langages.
J'ai décidé d'acheter :
Je me lance ! : Une introduction à la programmation C++ - Francis Glassborow, Roberta Allen, dans un premier temps puis ensuite d'acheter :
La Bible C++ - Timothy Budd (Auteur), Cay Horstmann (Auteur).

Je vous remercie de vos conseils, si vous avez d'autres suggestions à me faire, je suis preneur.

[koala01]

Il y a cependant une différence importante :
Pour la majorité des gens, ils ont déjà vu une voiture, marché dans la rue ou même conduit un vélo. Ils ont donc "pratiquer" le code de la route mais pas en tant que voiture. Pense tu pouvoir comprendre le code de la route si tu n'avais jamais vu de voiture/moto/vélo de ta vie ?

Alors que en programmation, les débutants arrivent avec aucune expérience/pratique du langage.

Mais tu n'a strictement aucun besoin d'expérience pour apprendre les bases de la programmation:

Dans tous les langages de l'arc-en-ciel (enfin, tous les langages procéduraux impératifs), une boucle reste une boucle, un test reste un test, un tableau reste un tableau, et les différentes structures dynamiques (pile, file, liste, arbres binaires,...) restent des concepts, applicables ou non, identiques.

Même lorsqu'il s'agit de choisir entre un tableau, une liste ou un arbre binaire, tu n'a absolument aucun besoin d'avoir la moindre expérience en programmation si on t'explique clairement "comment ça fonctionne" et quels principes entrent en jeu.

Il est très facile, même sans que le récipiendaire n'ait la moindre pratique de lui faire comprendre que la recherche sera beaucoup plus rapide dans un arbre binaire plus ou moins équilibré que dans une liste car... en lui présentant un simple exemple, on peut lui montrer qu'une recherche se fera, dans un cas de manière strictement séquentielle et dans l'autre cas en utilisant la dichotomie, avec une complexité bien plus avantageuse.

[EDIT]Cela nécessitera sans doute un recours accru au schéma de toutes sortes, mais il n'est absolument pas nécessaire d'utiliser un langage donné pour permettre au récipiendaire d'acquérir la pratique de la théorie

On peut alors se contenter "d'adapter" la théorie au langage étudié en partant du principe que... la théorie de base est connue

[NoIdea]

Les "vrai" débutants ne savent ni ce qu'est une boucle, un tableau ou ...
C'est pourquoi ils doivent apprendre et mettre en pratique les for, while, if, else, ... avant de pouvoir faire de la théorie avec.

[Invité]

Cela me gène personnellement au plus haut point, si, comme je le subodore, tu parle d'un point et d'un vecteur du point de vue mathématique.

Je rebondi sur ce détail, il s'agit effectivement de point(X,Y,Z) et de vecteur(cx,cy,cz) au sens mathématique.
On se trouve là, à l'évidence, où une sérieuse théorie aurait été indispensable.
Je n'ai pas eu la chance d'avoir une formation théorique à la programmation, mais il bien fallu que je m'en sorte tout seul.
En fait, malgré ce que j'ai dit dans un post précédent, je suis sûr que la théorie doit venir avant la pratique, mais, ne serait-ce que pour éviter de décourager le débutant, la pratique doit venir aussitôt après.
C'est dans ce sens que l'apprentissage avec un langage très simple me parait une bonne étape.
Question : Peut-on trouver un Basic (ou autre) pas cher et bien expliqué. Si oui, c'est vraiment ce que je recommande à tous les débutants.

Mais à l'inverse, à quoi servirait d'apprendre le tri à bulle si on ne peut pas l'essayer. Concernant ce tri, j'avais besoin de rapidité, et j'ai mis au point l'algorithme, tout seul, comme un grand, sans savoir qu'il avait déjà un nom.
Ma formation en matière de logique, je l'ai faite sur des langages machine (Olivetti, HP), et j'ai beaucoup lu.

[koala01]

Les "vrai" débutants ne savent ni ce qu'est une boucle, un tableau ou ...
C'est pourquoi ils doivent apprendre et mettre en pratique les for, while, if, else, ... avant de pouvoir faire de la théorie avec.

Mais non, absolument pas...
for, while et if else pourrait très bien se nommer "pour" "tant que" et "si sinon", cela ne changerait absolument rien...

Ce qui importe, c'est de leur faire comprendre que l'exécution n'est pas toujours (c'est même très rarement le cas) en "ligne droite".

Il suffit alors d'introduire la notion de "chemin parallèle" pour parler de tests et de conditions: les tests "simples" (si... sinon) en premier, les tests à "choix multiple" (selon Variable cas Valeur) juste après.

Et, pour finir, il suffit d'introduire le fait qu'il arrive que l'on veuille exécuter des instructions "tant qu'une condition est vrai" (voici venir la boucle "tant que", jusqu'à ce qu'une condition soit vérifiée (voici la boucle "jusque") ou un certain nombre de fois" (voici la boucle "pour")

Que le langage s'attende à voir un for ( ...; ...; ...) ou un perform varying I from 1 by 1 until I > 10 n'est alors qu'un... détail propre au langage.

[Invité]

@ NoIdea,

Les "vrai" débutants ne savent ni ce qu'est une boucle, un tableau ou ...
C'est pourquoi ils doivent apprendre et mettre en pratique les for, while, if, else, ... avant de pouvoir faire de la théorie avec.

Je vais pousser le raisonnement plus loin, un for est une instruction, il y a des signes (= ; etc) et dans la boucle, il y a i = N+1.
Instruction, signes, séparateur, opération etc. constitue la théorie indispensable.
Et en plus, pourquoi l'étudiant ferait un for, s'il ne sait pas pourquoi?

[koala01]

Je n'ai pas eu la chance d'avoir une formation théorique à la programmation, mais il bien fallu que je m'en sorte tout seul.

C'est, quelque part, le problème que de nombreux "pioniers" ont rencontré (cela dit sans offence, hein )

En fait, malgré ce que j'ai dit dans un post précédent, je suis sûr que la théorie doit venir avant la pratique, mais, ne serait-ce que pour éviter de décourager le débutant, la pratique doit venir aussitôt après.

Tant que l'on garde cette notion de "après" cela ne me dérange absolument pas.

Je n'aurais par exemple aucune objection à ce que l'on ait un cours d'algorithmie le lundi en première et deuxième heure et un cours de C (ou de C++) le lundi en troisième et quatrième heure dans lequel on mettrait en oeuvre ce qui a été appris les deux premières heures de la journée (bien que je sois conscient des difficulté d'organisation et de communication que cela pourrait engendrer) .

Par contre, j'ai énormément de mal à accepter un cours ou un tutoriel dédié à un langage donné qui essaye de présenter les principes fondamentaux "pour permettre d'avancer" dans l'étude du langage

C'est dans ce sens que l'apprentissage avec un langage très simple me parait une bonne étape.

Pourquoi simple

Enfin, comprenons nous : la syntaxe peut être simple

Au contraire, qu'il permette un maximum de choses, pour, justement, ne pas se trouver dans une situation dans laquelle la théorie n'est pas applicable à cause des restrictions dues au langage

Mais, et je n'insisterai jamais assez là dessus, que l'apprentissage de la théorie soit clairement distinct de l'apprentissage du langage.

Mais à l'inverse, à quoi servirait d'apprendre le tri à bulle si on ne peut pas l'essayer.

Il n'est pas question de ne pas l'essayer, il est "juste" question d'accepter de "jouer le jeu" en se prenant pour un interpréteur/compilateur/processeur

Concernant ce tri, j'avais besoin de rapidité, et j'ai mis au point l'algorithme, tout seul, comme un grand, sans savoir qu'il avait déjà un nom.

Tu sais, si on lui a donné un nom, c'est uniquement pour qu'il soit facile d'en parler et que tout le monde sache de quoi il s'agit

Ma formation en matière de logique, je l'ai faite sur des langages machine (Olivetti, HP), et j'ai beaucoup lu.

La formation en matière de logique peut s'acquérir au travers de différents biais, et ces biais sont de plus en plus nombreux.

Mais les choses étant ce qu'elles sont, nous ne reprocherons à personne le fait de se former avec un media "moderne" plutôt qu'en épluchant un bouquin de 750 pages écrit il y a 20 ans

[eyquem]

Je sens un débat très passionnant en train de faire ( si ce n'est pas déjà le cas), mais malheureusement, je ne comprends rien du tout dans vos propos

Je me faisais justement la réflexion en lisant les deux files que le problème quasi constant en tous les domaines est que c’est seulement après avoir traversé une expérience (dans le sens général : expérience de vie) que l’on sait et comprend ce que l’on aurait dû savoir et comprendre avant d’entrer dans cette expérience pour la débuter et la poursuivre de la meilleure façon.

La première conséquence de ceci est qu’au départ la véritable portée des choses qu’on entend ou qu’on lit nous échappe: on manque des clés théoriques parce qu’on n’a encore jamais eu l'expérience pratique de passer certaines portes.

[gl]

les déclarations de variable en début de fonction

En début de bloc, pas de fonction. Et ce n'est plus vrai en C99.

Pour le reste +1

[koala01]

Je me faisais justement la réflexion en lisant les deux files que le problème quasi constant en tous les domaines est que c’est seulement après avoir traversé une expérience (dans le sens général : expérience de vie) que l’on sait et comprend ce que l’on aurait dû savoir et comprendre avant d’entrer dans cette expérience pour la débuter et la poursuivre de la meilleure façon.

La première conséquence de ceci est qu’au départ la véritable portée des choses qu’on entend ou qu’on lit nous échappe: on manque des clés théoriques parce qu’on n’a encore jamais eu l'expérience pratique de passer certaines portes.

Si je suis conscient de la nécessité pour chacun de "faire ses propres expériences" (dieu sais que ca a été un de mes dada, et que ca l'est encore ), je me dis à l'usage qu'il est quand même parfois bon d'écouter les autres afin d'éviter ce qui peut l'être: il est d'autant moins marrant de se "casser la gueule" que l'on sait qu'un grand nombre de gens l'ont fait avant nous et qu'on a refusé de les écouter ... Et je parle (encore une fois) d'expérience

Je parle aussi d'expérience lorsque j'aborde le coté rébarbatif des cours et tuto qui mélangent trop allègrement un peu de théorie dans beaucoup de pratique propre à un langage.

Et je voudrais enfin préciser que je ne plaide nullement en faveur d'un "bourrage de crâne" pour la théorie sans la mettre en pratique, mais que je plaide pour... une mise en oeuvre de celle-ci sans ...passer par un langage de programmation donné.

Cela peut paraitre paradoxal, de mettre la théorie en pratique sans passer par un langage donné, et pourtant:

Une fois que les principes nécessaires sont acquis pour permettre à quelqu'un de créer un algorithme du type "tri à bulle" (parce que Pierre vient d'en parler ) en place, qu'est-ce qui empêche de demander au récipiendaire de demander de nous créer un algorithme capable de trier les valeurs que l'on obtient (dans l'ordre) 5, 45, 9, 8, 54, 94 et 2 (vous comprendrez qu'elles ont été écrites au hasard ) et de lui demander de se mettre "à la place du processeur" pour vérifier que son algorithme "tient la route", sans aucune prescription en terme de langage

Justement, le fait qu'il doive "travailler mentalement" le "formera" à la recherche et au respect de la "meilleure" logique possible.

Quand, un peu plus tard, nous lui aurons donné la liste des instructions et la syntaxe propres à un langage donné qui lui sont nécessaires pour implémenter concrètement le tri à bulle, il suffira de lui demander d'essayer de le coder pour qu'il puisse voir "le résultat concret"...

Mais, après avoir "joué au processeur", aura-t-il vraiment besoin de cela pour rester motivé

[arthurik]

Alors pour dire que apprendre la théorie peut faciliter la tâche pour apprendre un langage, c'est non! Car la théorie dans ce cas n'est pas celle du langage mais de toute la programmation!
Mais pratiquer un language peut nous éclaircir beaucoup de chose sur la théorie si pas tout! Car la théorie n'est pas aussi compréhensible qu'en pratiquant son propre avis sur elle!
J'ai réussi à comprendre la programmation créant des jeux sans comprendre ce que c'est un pixel, mais aujourdui ce n'est plus pareil, en tout cas je comprends ce que c'est un pixel et plus!

[Flob90]

En ce qui concerne l'algorithmie, je suis en COGE 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).

Et je ne crois pas qu'une fois passé sur Caml cela a aidé, cela serait même plûtot l'inverse (l'interpréteur CamlLight est assez mauvais quand il s'agit d'indiquer une erreur AMA ...).

Donc je pense aussi que la théorie est un bon préambule à la pratique, il permet de s'abstraire d'un support, d'éviter de s'attacher à des techniques du langage quand on conçoit un algorithme, d'apprendre rapidement à évaluer s'il va marcher (quand on vous impose de démontrer un algo, en général vous partez pas sur quelque chose qui marchera peut-etre ...)

Pour ce qui est des autres théories liées à la programmation (OO, Typage, Métrique ....) je ne sais pas trop quoi penser. Pour l'OO je pense aussi que de ne partir d'aucun langage peut-etre une bonne idée. Pour les 2 autres que j'ai coté elles sont je crois assez abstraite en soit).

[NoIdea]

Je pense que si on parle à quelqu'un qui n'a jamais vu une ligne de code , de langage de programmation, algorithme, POO, templates, ... il n'en retiendra que très peu et oubliera tout très rapidement.
Cependant, si on lui montre les possibilités offertes par le langage (pour un mathématicien la puissance de calcul, pour d'autres les jeux vidéos,...) il pourra avoir un attrait. Puis, il faut lui enseigner les clés pour le faire :

Au début il peu s'agir d'explication théorique comme "une boucle for consiste à... et est utilisée pour..." mais il faudra que rapidement les mettre en pratique sans quoi il oubliera tout et verra son objectif se perdre (et donc sa motivation).
En les mettant en pratique, il pourra vérifier la qualité de son raisonnement (un test véritable est toujours mieux qu'un test "dans la tête" et donne l'impression d'aboutissement). Plus tard, quand le sentiment d'aboutissement ne sera plus nécessaire, que son objectif ne lui paraitra pas inatteignable (ou du moins qu'il comprendra les mécanismes), il pourra faire de la théorie pure.
Si on lui explique ce qu'est un tri a bulle, il n'en comprendra pas vraiment l'intérêt car il n'en n'aura jamais eut besoin.

[koala01]

Alors pour dire que apprendre la théorie peut faciliter la tâche pour apprendre un lanuage, c'est non! Car la théorie dans ce cas n'est pas celle du langage mais de toute la programmation!
Mais pratiquer un langage peut nous éclaircir beaucoup de chose sur la théorie si pas tout! Car la théorie n'est pas aussi compréhensible qu'en pratiquant son propre avis sur elle!
J'ai réussi à comprendre la programmation créant des jeux sans comprendre ce que c'est un pixel, mais aujourdui ce n'est plus pareil, en tout cas je comprends ce que c'est un pixel et plus!

Il est vrai qu'il y a... théorie et théorie.

Je ne parle pas forcément de celle qui te permet de savoir comment fonctionne un pixel (ce qui est d'ailleurs aussi fort soumis à variation en fonction du matériel et du langage), mais bel et bien des "principes de base" de la programmation.

Je parle de connaitre et de pouvoir utiliser tous des termes comme variable, type, fonction, test (à choix multiple), boucle, type définis par l'utilisateur, pile, file, liste, ...

Je parle d'être capable de réfléchir à la logique qui permettra, pourquoi pas, de déterminer la position d'un "sprite" lorsqu'il doit être affiché, en fonction de différents paramètres qu'il te faut évaluer ou calculer.

Je te parle d'être capable de réfléchir à une logique qui... empêchera ton personnage de "tomber" en dehors de ton plateau de jeu.

Je te parle de cette approche qui te permettra de gérer "au mieux" les différents sons, animations ou objets mobiles, en fonction des besoins, de déterminer quand il est préférable de les charger en mémoire, et de déterminer quand il est intéressant de les "décharger".

Tout cela peut être appris et devrait être compris avant d'essayer d'écrire le code car, si tu ne réfléchis pas à ces différents aspects, tu te retrouves avec un bonhomme marche "dans le vide" ou qui n'avance que de manière sacadée, avec des sons entièrement décalés par rapport à l'événement qui est censé le produire, à des temps de chargements qui te laisse l'occasion de boire ton café, le digérer et aller le pisser avant que ton jeu ne se lance.

Je ne compte plus le nombre de fois où un débutant s'est plaint des piètres performances de son programme, alors qu'il y avait un manque flagrant de réflexion "a priori" quant à la logique à mettre en oeuvre.

Cela se voyait à la manière même dont son code était structuré, et j'imagine sans peine sa tête devant le raisonnement que l'on suivait pour lui proposer une solution.

Tous ces écueils peuvent cependant être évités, et le débutant peut facilement resté motivé par le résultat obtenu s'il prend simplement la peine de se poser cinq minutes pour réfléchir à la logique avant de se mettre à "vomir" des lignes de code.

Et cette réflexion ne peut avoir, en définitive, qu'une seule base saine: la théorie et les "grands principes de la programmation", éventuellement adaptés au langage qu'il utilise.

C'est encore pire avec les langages qui permettent une gestion manuelle de la mémoire:

Combien de fois ne voit on pas dans le programme d'un débutant qu'il essaye de déréférencer ou de manipuler l'adresse d'un pointeur sans avoir au préalable... alloué la mémoire, ou après... avoir explictement libéré celle-ci

Une petite minute de réflexion, le simple fait d'avoir couché la logique sur un bout de serviette en papier lui aurait permis de se rendre compte que cette réservation ou cette libération de mémoire intervenait à... un mauvais moment.

La conception, de manière générale, est effectivement une tâche abstraite mais une étape indispensable à l'obtention d'un résultat au minimum "potable", et il est finalement très facile de la rendre beaucoup plus concrète sans avoir besoin de passer par un langage particulier: il "suffit" d'inciter le concepteur à se prendre "rien qu'un instant" pour l'ordinateur qui recevra les instructions.

Comme je l'ai dit, ce jeu de rôle permet, outre d'éventuels moments de rigolade (si celui qui endosse le rôle ne se prend pas trop au sérieux ), de concrétiser la manière dont le code sera effectivement exécuté.