Discussion :

[koala01]

Cette discussion issue de Apprendre le C & C++, un bon choix ?


Salut,

Si je pouvais te donner un conseil, ce serait d'apprendre en priorité les "base communes", les "principes généraux" que l'on retrouve dans strictement tous les langages: les principes de l'algorithmique et de la programmation structurée d'une part, les principes de la programmation orientée objet d'autre part(même si ces derniers ne s'appliquent pas à tous les langages).

Il ne faut, en effet, pas donner plus de pouvoir aux langages qu'ils n'en ont réellement: ce ne sont que des outils qui permettent d'indiquer à "quelque chose d'aussi bête qu'un ordinateur" ce que l'on attend d'eux.

Seulement, avant de vouloir essayer de faire comprendre à un ordinateur ce que l'on attend de lui, il faut... savoir exactement ce que l'on attend qu'il fasse et dans quel ordre.

Ce n'est qu'une fois que l'on sait clairement et précisément (ou du moins "de manière aussi précise que possible") ce que l'on attend de l'ordinateur qu'il faut faire intervenir un langage de programmation pour le lui indiquer, et le travail se limite alors souvent à un "long et fastidieux travail de dactylographie" (bon, d'accord, j'exagère un peu sur ce point )

Lorsque l'on respecte cet ordre d'apprentissage et de développement avant l'écriture du code, on se donne l'occasion de rendre sa vraie place aux langages de programmation, ils semblent directement beaucoup moins complexes, et l'on passe beaucoup moins longtemps à s'arracher les cheveux en se demandant "pourquoi il ne fait pas ce que je veux".

Ceci dit, je confirme ce qui a déjà été dit par ailleurs: C et C++ sont effectivement des langages fort proches, et s'il est possible que tu sois, à cause de la quantité de code existant, confronté à des situation dans lesquelles ton rencontrera peut être du code C dans du code C++, il est bon et préférable d'apprendre ces langages séparément.

A l'extrême limite, j'en arriverais volontiers à conseiller d'apprendre C++ avant C, histoire de ne pas prendre des "mauvaises habitudes" qui passent pourtant en C pour "des règles de bonnes pratiques" lors de l'apprentissage de C.

Je ne crois personnellement pas qu'il ne vaille pas la peine d'apprendre C, car c'est un langage qui est à l'heure actuelle encore largement utilisé, même si c'est peut être dans des secteurs "de niche".

Par contre, je suis catégorique sur le fait que la connaissance de C n'est nullement un prérequis à l'apprentissage de C++

[NoIdea]

Moi je te conseillerais plutôt, si tu as le temps et que pour l'instant tu n'as pas encore étudié d'autres langages de programmation :

-Apprend le C : les types, les pointeurs, l'algorithmie, les étapes de compilation, les headers...
-fixe toi des projets : créer une librairie (par ex liste chainée ou doublement chainée pour un type donné), Améliore une librairie existante, créer un jeu (avec la SDL par exemple), ... (tout cela est largement possible en C)
Normalement, le paradigme procédural est étudié.
-Apprends le C++ without classes : la surcharge de fonction, la surdéfinition d'opérateur, les templates, les namespaces, les références...
Normalement, le paradigme générique est étudié.
-utilise ce nouveau language : recréé une liste chainée pour n'importe quel type.
-Apprend la notion de classe et surtout le RAII
-Facilite les choses avec la STL
-Normalement la notion d'objet est étudiée bien qu'il y a pas beaucoup de différence entre une class (c++) et une struct (C) mis a part quelques différences de syntaxe.
-Apprend le véritable intérêt des classes : le polymorphisme.
-Facilite encore plus grâce a boost et Qt.
-intéresse toi aux design patterns.

Par contre, je suis catégorique sur le fait que la connaissance de C n'est nullement un prérequis à l'apprentissage de C++

Que tu passes directement au c++ ou que tu fasses c puis c++, les même connaissance seront obtenues. Cependant, commencer par le c++ ne donne pas une idée de ce qu'il se passe dernière :
par exemple, souvent si l'on commence par le c++, un des premiers programme sera
int nb=10;
cout<<nb;
alors que en C on aura
int nb=10;
printf("%i",&nb);

Quelqu'un de débutant pensera longtemps(ou pas), ne pensera jamais qu'on ne puisse pas afficher quelque chose dans cout. De plus, la syntaxe de "fonction" est cachée par l'opérateur <<
Alors que dans le deuxième cas, un débutant verra tout de suite que pour chaque chose, il y a une manière différente de les afficher. De plus, printf ressemble réellement à une fonction.

histoire de ne pas prendre des "mauvaises habitudes" qui passent pourtant en C pour "des règles de bonnes pratiques" lors de l'apprentissage de C.

koala, a tu de nombreux exemples de mauvaises habitudes autres que les #define utilisés en permanence et l'absence de RAII ?

[koala01]

-Apprend le C : les types, les pointeurs, l'algorithmie...

Pourquoi vouloir faire apprendre l'algorithmie et les bases de la programmation en passant par un langage, quel qu'il soit

Les bases de la programmation, algorithmie en tête, sont totalement indépendantes de n'importe quel langage et s'appliquent strictement à tous.

C'est, à mon sens, justement parce que les approches "traditionnelles" essayent d'inculquer les bases de la programmation en même temps qu'un langage particulier que tous les langages semblent si complexes et rebutants aux récipiendaires.

De même pour la programmation orientée objets: C++ a l'énorme avantage de permettre certaines chose que d'autres langages refusent (l'exemple classique étant l'héritage multiple ), mais tous les langages OO incitent le développeur / le programmeur à respecter les mêmes règles, principes et loi de manière plus ou moins stricte selon leur propre philosophie.

Si tu commences par apprendre les "bonnes pratiques" qui te permettent de développer un projet qui "tient la route", si tu y adjoint des méthodes de développement qui te permettent d'avoir une vue d'ensemble cohérente de l'adaptation de ton projet au besoins exprimés (je penses, entre autres, à UML), l'apprentissage d'un langage OO devient particulièrement aisé, parce qu'il te devient possible de faire le rapprochement entre ce que tu as envisagé "de manière abstraite" (en mettant ta méthode de développement en oeuvre) et ce que le langage permet "concrètement".

Tu n'a donc "plus qu'à"... adapter ta connaissance des principes généraux aux restrictions et au permissivités du langage que tu apprend

Encore une fois, cette méthode d'apprentissage permet de "démystifier" le langage que tu apprend

[Invité]

@Koala

Seulement, avant de vouloir essayer de faire comprendre à un ordinateur ce que l'on attend de lui, il faut... savoir exactement ce que l'on attend qu'il fasse et dans quel ordre.

Ce n'est qu'une fois que l'on sait clairement et précisément (ou du moins "de manière aussi précise que possible") ce que l'on attend de l'ordinateur qu'il faut faire intervenir un langage de programmation pour le lui indiquer, et le travail se limite alors souvent à un "long et fastidieux travail de dactylographie" (bon, d'accord, j'exagère un peu sur ce point )

Là je suis complètement d'accord. Autrefois, quand on développait, on décrivait la logique, on dessinait l'organigramme etc, et on avait deux ou trois passages par jour. On allait lire son petit (ou gros suivant le cas) paquet de cartes à trois bâtiments de là, on allait chercher son listing une heure plus tard, dans le même bâtiment. Là je vous assure que c'était du développement et l'étape programmation était accessoire. Si le programme concernait le dessin, on allait chercher la bande dans la salle machine, et il fallait attendre que la table soit libre pour avoir le résultat.
Mais maintenant, il semble que l'on mette la programmation en avant.

Par contre, je ne suis pas vraiment d'accord avec votre dernier post.

De la même façon qu'on ne peut pas apprendre à parler anglais dans des livres, on ne peut pas apprendre les échanges avec une machine (un langage) sans discuter effectivement avec elle.
Si j'avais à conseiller un débutant, je lui dirais de commencer avec un truc très simple, comme le BASIC. Autrement dit, à choisir pour commencer entre le C et le C++, c'est sans hésiter le C. Je ne sais pas quelle mauvaise habitude on risque de prendre, mais ça me parait complètement secondaire par rapport à l'avantage de "savoir ce qui se passe".
La lecture de chaque post de ces forums me confirme cela.
Je sais bien, c'est un sujet maintes fois évoqué, autant j'admets que le C n'est pas un prérequis nécessaire au C++, autant je suis sur que pour comprendre la programmation, il faut commencer pas du bas-niveau (au sens où on l'utilise dans ce domaine).

Pour mémoire, il y a eu un échange de post très intéressant sur le forum concurrent (je parle du forum C naturellement).

PS Vous écrivez plus vite que moi, j'ai 2 post de retard

[koala01]

@Koala

Là je suis complètement d'accord. Autrefois, quand on développait, on décrivait la logique, on dessinait l'organigramme etc, et on avait deux ou trois passages par jour. On allait lire son petit (ou gros suivant le cas) paquet de cartes à trois bâtiments de là, on allait chercher son listing une heure plus tard, dans le même bâtiment. Là je vous assure que c'était du développement et l'étape programmation était accessoire. Si le programme concernait le dessin, on allait chercher la bande dans la salle machine, et il fallait attendre que la table soit libre pour avoir le résultat.
Mais maintenant, il semble que l'on mette la programmation en avant.

Et c'est un très grand tord...

La programmation est et doit rester "l'étape finale" d'un processus de développement.

On se comprend ici sur les termes: je veux dire par là que la programmation vient "une fois que l'on a la (quasi) certitude que l'ensemble tient la route", quitte, si cette étape montre des lacunes dans ce qui a été fait avant, à ce que l'on reparte dans un processus de développement afin de les supprimer

Par contre, je ne suis pas vraiment d'accord avec votre dernier post.

De la même façon qu'on ne peut pas apprendre à parler anglais dans des livres, on ne peut pas apprendre les échanges avec une machine (un langage) sans discuter effectivement avec elle.

Pour l'accent et la prononciation, je suis d'accord, rien ne vaut l'oral.

Par contre, en ce qui concerne le vocabulaire et la grammaire, il est presque plus facile de les acquérir grâce... aux lectures.

Je lis particulièrement bien l'anglais, et je l'écrit finalement pas si mal, mais je dois avouer que je le parle quand même avec "l'accent d'une vache espagnole", principalement parce que j'ai effectivement peu d'occasions de le pratiquer

Si j'avais à conseiller un débutant, je lui dirais de commencer avec un truc très simple, comme le BASIC. Autrement dit, à choisir pour commencer entre le C et le C++, c'est sans hésiter le C. Je ne sais pas quelle mauvaise habitude on risque de prendre, mais ça me parait complètement secondaire par rapport à l'avantage de "savoir ce qui se passe".

Je serais plutôt de l'avis contraire...

La priorité devrait être que... cela fonctionne correctement avant de fonctionner vite.

Un programme qui mène vite à une erreur est, pour moi, bien moins intéressant qu'un programme qui fait ce qu'on attend de lui, même s'il le fait un peu plus lentement.

Je ne veux absolument pas dire par là que la notion de performances doit être oubliée, mais, c'est à mon sens quelque chose qui doit être évalué une fois que l'on a... un résultat exploitable.

En cela, savoir comment se comportera le processeur (après l'étape de compilation) ou le compilateur devient finalement bien moins important que d'avoir une logique... logique et clairement la" moins mauvaise possible"

[white_tentacle]

koala, a tu de nombreux exemples de mauvaises habitudes autres que les #define utilisés en permanence et l'absence de RAII ?

Le nommage différent parce qu'il n'y a pas de namespace ni de surcharge, les passages de paramètres par pointeurs parce qu'il n'y a pas de références, les single return (absence de raii), les déclarations de variable en début de fonction, etc. Je suis sûr qu'on en trouve rapidement plein d'autres.

[koala01]

Le nommage différent parce qu'il n'y a pas de namespace ni de surcharge, les passages de paramètres par pointeurs parce qu'il n'y a pas de références, les single return (absence de raii), les déclarations de variable en début de fonction, etc. Je suis sûr qu'on en trouve rapidement plein d'autres.

Ouppss... je n'avais pas vu la question

Comme tu y a répondu, je pourrais aussi citer la gestions manuelle de la mémoire systématique, le recours aux tableaux de caractères pour représenter des... chaines de caractères, l'utilisation même de fonctions issues du C en C++, le transtypage vers void pour transmettre un paramètre dont le type n'est pas connu à une fonction, et il y en a encore d'autres

Je crois que, si tout le monde s'y met, nous devrions sans doute arriver à dresser une liste presque exhaustive contenant pas loin d'une centaine de pratiques conseillées en C et déconseillées en C++

[NoIdea]

Les bases de la programmation, algorithmie en tête, sont totalement indépendantes de n'importe quel langage et s'appliquent strictement à tous.

Tout à fait d'accord, mais, pour regarder les conséquences de son algorithme (lenteur, et autres défauts), il faut à un moment écrire dans un langage cet algorithme. Or je ne pense pas qu'apprendre un troisième langage soit une bonne idée.

De même pour l'OO.

[NoIdea]

Quant au mauvaises pratiques, si vous voulez dire que les bibliothèques C que l'on inclut ont des problèmes, d'accord (namespace, nom des fonctions...). Toutefois, il existe souvent des wrapper.
Cependant, dans le cas où les programmeurs et eux même ont des mauvaises habitude, je suis moins d'accord :

qu'il n'y a pas de namespace ni de surcharge, les passages de paramètres par pointeurs parce qu'il n'y a pas de références, les single return (absence de raii), les déclarations de variable en début de fonction

namespace=touche finale + utile que dans les gros projets.
surcharge= problème corrigé dans la partie 2 : le C++ without classes.
absence de raii=vrai problème mais peut être corrigé.

la gestions manuelle de la mémoire systématique, le recours aux tableaux de caractères pour représenter des... chaines de caractères, l'utilisation même de fonctions issues du C en C++, le transtypage vers void pour transmettre un paramètre dont le type n'est pas connu à une fonction, et il y en a encore d'autres

Personnellement, je pense qu'il existe peu de personne qui apprécie de gérer la mémoire systématiquement ainsi que les chaines de caractère. Avec la découverte de la STL, ces habitudes devraient se perdre rapidement :
on ne parle pas de quelqu'un qui va programmer en C pendant 10 ans puis qui va se mettre au c++.
Utilisé des fonctions issue du C plutôt que du c++ ne pose de problème qu'en cas de mélange des 2.
Quant-aux transcryptage vers void, il est souvent remplaçable par des templates qui sont découverte dans mon chapitre 2. De plus, gérer des void* plutot que des template est beaucoup plus dur.

Je pense donc, qu'il y a de faible chance pour que quelqu'un puisse s'imprégner de mauvaises habitudes qui ne seront pas changées rapidement par la venue du c++ et quelques mois de C.

que les approches "traditionnelles"

Il me semblait qu'une approche traditionnelle était plutot :

-C
-C with classes
-c++

et non

-C
-C++ without classes
-C++

[koala01]

Quant au mauvaises pratiques, si vous voulez dire que les bibliothèques C que l'on inclut ont des problèmes, d'accord (namespace, nom des fonctions...). Toutefois, il existe souvent des wrapper.
Cependant, dans le cas où les programmeurs et eux même ont des mauvaises habitude, je suis moins d'accord :

Demande à quelqu'un qui a l'habitude de coder en C d'écrire un code en C++... Tu risques d'avoir pas mal de surprises

namespace=touche finale + utile que dans les gros projets.

Loin de là...

namespace : un espace de noms dédié pour chaque projet, dés le début du projet, même s'il n'est pas subdivisé, et même si le projet reste limité.

Cela permettra justement de ne pas "tout laisser trainer" dans l'espace de noms global

surcharge= problème corrigé dans la partie 2 : le C++ without classes.
absence de raii=vrai problème mais peut être corrigé.

A condition d'y penser...

Personnellement, je pense qu'il existe peu de personne qui apprécie de gérer la mémoire systématiquement ainsi que les chaines de caractère. Avec la découverte de la STL, ces habitudes devraient se perdre rapidement :
on ne parle pas de quelqu'un qui va programmer en C pendant 10 ans puis qui va se mettre au c++.
Utilisé des fonctions issue du C plutôt que du c++ ne pose de problème qu'en cas de mélange des 2.

Les mauvaises habitudes, surtout si on les a surinées comme "bonnes" pour un autre langage sont malheureusement les plus difficiles à perdre...

Le forum fourmille d'exemples de ce genre

Quant-aux transcryptage vers void, il est souvent remplaçable par des templates qui sont découverte dans mon chapitre 2. De plus, gérer des void* plutot que des template est beaucoup plus dur.

Je pense donc, qu'il y a de faible chance pour que quelqu'un puisse s'imprégner de mauvaises habitudes qui ne seront pas changées rapidement par la venue du c++ et quelques mois de C.

Hum...

J'ai l'impression que l'on ne participe pas vraiment sur les mêmes forums...

De mon expérience personnelle, je peux t'assurer qu'il est parfois très difficile d'inciter quelqu'un à abandonner son précieux char* au profit de std::string ou d'abandonner son Type* au profit de std::vector

Il me semblait qu'une approche traditionnelle était plutot :
-C
-C with classes
-c++

et non

-C
-C++ without classes
-C++

Ce que j'appelle "approche traditionnelle" regroupe toute approche tentant d'inculquer des "principes de base" (adaptés au paradigme mis en avant) au travers d'un langage particulier.

As tu déjà remarqué la tête de javaistes lorsque tu leur lance le terme "LSP"

Certains ne savent même pas ce que c'est, simplement parce que tout hérite implicitement de Object, et qu'ils en arrivent à ne même pas se poser la question de l'opportunité d'un héritage.

Le problème, c'est que si tu base l'étude des "principes fondamentaux" sur un langage donné, tu en biaise l'apprentissage du seul fait des restrictions ou permissivités du langage en question.

Les "bonnes pratiques" qui découlent alors du langage passent pour être "la règle générale", alors qu'elles devraient être considérée comme... l'exception propre au langage

[koala01]

Tout à fait d'accord, mais, pour regarder les conséquences de son algorithme (lenteur, et autres défauts), il faut à un moment écrire dans un langage cet algorithme. Or je ne pense pas qu'apprendre un troisième langage soit une bonne idée.

Pas forcément...

Si tu apprend à te mettre à la place de l'ordinateur qui reçois les instructions une à une, tu peux déjà très rapidement arriver à déterminer où pêche l'algorithme.

Et cela peut occasionner quelques franches moment de rigolade, si tu le fais sérieusement sans te prendre au sérieux

Il s'agit d'un exercice dans lequel je me lance très régulièrement, et je peux t'assurer que grâce à cela, la première compilation réussie me donne généralement... exactement le résultat que je souhaitais.

Il te permet aussi bien de tester la logique générale que de trouver les instructions qui sont répétées de manière indues, et, si tu effectue suffisamment (comprend: tant que tu remarque quelque chose d'illogique) d'itération écriture / modification de l'algorithme -->test mental, tu arrives très rapidement à un algorithme "optimal"

Cette manière de faire peut, aussi, te permettre de déterminer qu'une structure de données particulière ne semble, par exemple, pas forcément adaptée ( l'exemple typique serait l'utilisation d'un tableau ou d'une liste quand un arbre binaire s'avèrerait plus efficace pour la recherche).

N'oublie pas que l'ordinateur est quelque chose de, finalement, totalement idiot qui ne sait (même si j'exagère un peu) que compter de 0 à un et qu'appliquer un nombre très restreint d'opération de base.

Tu ne pourra donc lui donner que "l'intelligence" que tu veux bien / peux lui inculquer, et c'est pour cela que tout le travail intellectuel que tu aura fourni avant d'écrire ta première ligne de code sera particulièrement valorisé par la suite

[NoIdea]

tu arrives très rapidement à un algorithme "optimal"

Pas forcément, il existe des problèmes ou il n'y a pas de "bon" algorithmes :
On utilise donc des heuristiques, pour ce rendre compte de la lenteur d'un algorithme par rapport à une heuristique sans le tester, dur-dur parfois...
De plus, je ne pense pas qu'un débutant veuille pouvoir au début exécuter un algorithme uniquement dans sa tête (à un moment, il faut qu'il le "voit").

[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.

[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.

[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

[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

[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).

[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é.