Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

[Débat] Apprendre la théorie avant la pratique
Une bonne chose ?

Le , par koala01

63PARTAGES

2  0 
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++

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 16/08/2010 à 17:33
Citation Envoyé par NoIdea Voir le message
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
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 16/08/2010 à 17:49
Citation Envoyé par NoIdea Voir le message
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
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 16/08/2010 à 18:01
Citation Envoyé par NoIdea  Voir le message
Pas forcément, il existe des problèmes ou il n'y a pas de "bon" algorithmes :

j'aurais peut-être du parler d'algorithme "le moins mauvais possible", mais c'est jouer sur les termes ,
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").[/QUOTE]J'ai "eu la chance" d'avoir des cours d'algorithmie et de conception orienté objet sans aucune référence à un langage donné, dans lesquels on ne touchait pour ainsi dire jamais à un ordinateur (tout se faisait sur des feuilles, et l'évaluation de la qualité de l'algorithme se faisait sur le tableau noir).

Cette chance était, il est vrai, couplée avec celle d'avoir un prof très sérieux qui ne se prenait pas au sérieux

Mais je peux t'assurer que, quand les conditions sont présentes, cela ne te manque absolument pas de ne pas voir ce que l'ordinateur fait effectivement, simplement, parce que tu le vois d'une autre manière (dans mon cas : un prof qui "fait le pitre" devant le tableau).

Si, lorsque tu analyse un algorithme proche de
Code : Sélectionner tout
1
2
3
4
5
6
7
 
variable A =0 
tant que A différent de 10 
    machin 
    chose 
    A = A + 1 
fin tant
tu as quelqu'un qui en arrive à un discours proche de
A vaut 0
est-ce que A est différent de 10
OUI, on vient de dire qu'elle vaut 0
on fait machin
on fait chose
A vaut 0 + 1 : A vaut maitenant 1
on retoune au début.
A est il différent de 10
OUI, on vient de dire qu'il vaut 1
...

je peux t'assurer que le fait de ne pas le voir à l'écran ne te manque absolument pas
2  0 
Avatar de Flob90
Membre expert https://www.developpez.com
Le 16/08/2010 à 21:33
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).
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 17/08/2010 à 19:26
Citation Envoyé par pseudocode Voir le message
Dans l'ordre, je trouve qu'apprendre les bonnes pratiques est plus important que d'apprendre la théorie.
Encore une fois, je trouve important de faire la distinction entre les bonnes pratiques "d'ordre générale" et celles qui sont propres à un langage en particulier.

Les bonnes pratiques d'ordre générale trouvent souvent une justification dans la "théorie de base", et cette dernière peut donc aider à... comprendre ces bonnes pratiques.

Pour ce qui est des bonnes pratiques propres à un langage, elles sont, justement... propres au langage visé, et ce qui peut être considéré comme "allant de soi" dans X sera à la limite considéré comme... particulièrement dangereux ou carrément refusé dans Y ou Z.

Pensez à ce que l'on fait en C qui est refusé en C++, à ce qui est "fréquent" en C++ et refusé en java, ce ne sont pas les exemples qui manquent
Il sera toujours temps, si on trouve cela intéressant, d'apprendre la théorie pour comprendre la raison d'être de ces bonnes pratiques. Alors qu'a l'inverse, connaitre la théorie ne vous empêche pas de faire des erreurs de débutant.
Ma théorie est que, justement, lorsque l'on connait la raison d'être de quelque chose, on a beaucoup plus facile à retenir ce quelque chose et on est d'autant plus enclin à accepter de le faire.

Regarde simplement la manière dont tu régira face à l'ordre d'un supérieur s'il te dit simplement "c'est comme cela et pas autrement" par rapport au même ordre pour lequel il aura pris soin de t'expliquer les raisons de l'ordre

Pour le premier, tu pestera sur ton supérieur et tu le fera "avec des pieds de plombs", alors que pour le second tu le fera bien plus volontiers si... tu as compris et que tu adhère aux raisons qu'il t'a donné.

Les bonnes pratiques suivent exactement le même cheminement
Citation Envoyé par white_tentacle Voir le message
En passant, on peut faire un parallèle intéressant avec d'autres disciplines :

- en musique, certains pensent qu'il faut d'abord apprendre le solfège (la théorie), ensuite un instrument. D'autres préfèrent commencer par un instrument puis apprendre le solfège plus tard, enfin d'autres feront tout en même temps.

- en sport, certains préfèreront la pratique de katas à l'affrontement en match/pratique réelle. Là encore, il y a le même débat.

Il est clair que la méthode qui vise à faire bouffer toute la théorie avant de passer à la pratique est très bonne pour former des gens très compétents, mais qu'elle en rebutera largement plus d'un. Je crois que comme toujours dans l'enseignement, il n'y a pas de règle absolue, si ce n'est de s'adapter à son public .
Comprenons nous (le titre de la discussion est peut être mal choisi, en sommes) : je ne dis absolument pas qu'il faut avoir fini d'ingurgiter toute la théorie avant de passer à la pratique avec un langage particulier.

Je dis que :
1- il est tout à fait possible de se passer d'un langage particulier pour "pratiquer" si les conditions sont réunies

2- Je n'ai rien contre le fait que l'on apprenne, en parallèle, un langage quelconque, pour autant que l'on n'essaye pas d'apprendre de la théorie (qui risque d'être biaisée par les restrictions et les permissivités du langage étudié) pendant cet apprentissage.
Citation Envoyé par yorukaze Voir le message
Une chose à dire : C'est en forgeant qu'on devient forgeron.
Je suis tout à fait d'accord, mais on peut trouver différentes manières de forger:

Si tu demande, pendant la partie théorique, de résoudre un problème concret à l'étudiant, puis que tu l'incite à vérifier oralement que son algorithme est correct et cohérent, c'est aussi une manière de forger... qui ne passe pas forcément par... la connaissance d'un langage quelconque
Pour moi pratique et théorie vont ensemble, c'est une perte de temps à mon sens d'écrire sur un bout de papier une utilisation de patterns, de POO et autres concepts alors qu'on peut le coder directement.
Le "bout de papier" sera souvent la base de la conception et des méthodes de communication... Autant faire prendre directement les bonnes habitudes à l'étudiant pour qu'il commence par... réfléchir à ce qui doit être fait avant de se lancer sur le clavier et de commencer à "vomir" des lignes de code, en n'ayant, bien souvent, qu'un idée beaucoup trop approximative de l'ensemble.

Là où je te rejoins, c'est qu'il ne sert à rien d'arriver avec le diagramme de classe d'un pattern quelconque et de dire "ca, c'est le pattern XXX".

Par contre, ce qui est des plus intéressants, c'est de mettre l'étudiant face à un cas où le dit pattern est, décidément, la moins mauvaise solution.

Il y a nonante chances sur cent (si pas plus) que le diagramme de classes qu'il mettra au point ressemblera furieusement à celui... du pattern que tu voulais lui montrer.

Tu pourra alors attirer l'attention sur les quelques classes qui participent au pattern et lui dire "tu vois ca, c'est le pattern XXX" et, comme il l'aura cherché "de lui-même", il ne l'oubliera plus.

Il est d'ailleurs intéressant de constater que les DP ne sont pas sortis "comme cela" du cerveau malade d'un théoricien un peu fou : ils sont issus d'une étude approfondie des problèmes les plus fréquemment rencontrés et des solutions qui y étaient apportées.

Une fois évacués tous les points de variations propres aux spécificités des projets étudiés, on s'est rendu compte que... les problèmes étaient souvent équivalents et que les solutions étaient, elles aussi, équivalentes, parce que c'étaient... les solutions les moins mauvaise pour obtenir le résultat escompté.
Alors oui la théorie c'est bien, mais sans la pratique c'est pisser dans un violon.
Je suis tout à fait d'accord là dessus, mais, encore une fois, j'ai peut être une vision un peu plus générale de ce que pourrait être la pratique.

Et, pour moi, elle peut parfaitement ne pas passer par... un langage de programmation particulier.
2  0 
Avatar de Cyrano
Membre régulier https://www.developpez.com
Le 18/08/2010 à 7:04
Salut tout le monde,
Citation Envoyé par koala01 Voir le message
Et je suis personnellement très coulant quant à l'acception du terme conception: dans bien des cas, le simple fait de se "poser cinq minutes", le temps de boire un café ou de fumer une cigarette (ou une pipe, comme Pierre ) en réfléchissant aux besoins que l'on peut rencontrer peut s'avérer suffisant (sous réserve des problèmes de communication que cela peut engendrer )
Je crois que cette phrase résume fort bien le problème global.

Personnellement, je ne programme ni en C ni en C++, je développe en PHP et je suis complètement autodidacte en la matière. Le premier programme que j'ai écrit, j'ai commencé par le concevoir avec une feuille de papier et un stylo, créant, sans le savoir à l'époque, un algorithme.
Ce que je veux illustrer ici, c'est que ce que nous savons sans forcément l'exprimer, c'est qu'un développement bien fait, c'est d'abord entre 50 et 70% d'analyse.

La programmation, ce n'est pas compliqué, c'est nous (humains) qui sommes compliqués. J'explique à des personnes non informaticiennes qu'elles font de la programmation au quotidien sans le savoir en leur citant un petit exemple bête quoique très parlant. Si je veux faire des frites, je vais me poser certaines questions. La toute première, c'est « Ai-je des patates ?» : pourquoi cette question ? Parce qu'elle n'a que deux réponses possibles, oui ou non. Si c'est non, va pour une boite de petits pois, sinon, question suivante. En fait, on part d'un problème complexe qu'on atomise en questions à réponses binaires.
La difficulté du programmeur, c'est de ralentir le rythme cérébral pour isoler toutes ces questions afin de les transformer en code quel que puisse être le langage.

Donc l'apprentissage de la programmation, ça doit passer d'abord par l'apprentissage de l'analyse. Après ces bases fondamentales on peut intégrer l'apprentissage des langages et des méthodologies : POO, Design patterns et autres éléments qui viendront enrichir les compétences du développeur. La toute première des bonnes pratiques, je crois que ça reste (et ça restera toujours) la logique.
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 18/08/2010 à 10:21
Citation Envoyé par white_tentacle Voir le message
En passant et sans vouloir relancer le débat, je réagis juste à ça :
On va juste veiller à rester dans le cadre du débat actuel, alors
Personne n'a soutenu (en tout cas, pas moi) que c'était bien "parce que le compilateur le permet". On est simplement à un désaccord sur un niveau purement théorique, indépendant du langage cible.
Et pourtant, la théorie générale est claire et sans équivoque: toutes les propriétés valides pour la classe mère ne le sont pas pour les classes dérivés, et donc, l'héritage n'est pas admissible
Je ne pense pas qu'apprendre la théorie après la pratique te fasse réfléchir différemment de si tu l'avais apprise avant ou en même temps. Par contre, ça te fait réfléchir différemment de si tu ne la connais pas, c'est sûr .
Je pense au contraire que tout le problème vient de ce que tu rencontre un principe théorique qui t'interdit quelque chose qui "semble acceptable" pour ton langage cible.

Tu as donc de bonnes raisons de croire, en toute bonne franchise, que la théorie de base n'est pas en adéquation avec les faits.

Or ce n'est pas le cas: ce que tu observe dans ton langage cible n'est, au mieux, que quelque chose de particulier voulu par le langage (ex: l'interdiction de l'héritage multiple dans certains langages), au pire (comme c'est le cas pour ce fameux débat que tu ne veux pas relancer) qu'un "problème" du au fait que le compilateur n'est simplement pas armé pour s'assurer du respect d'un principe donné.

Si, dés le départ, et surtout avant de vouloir écrire une classe dans laquelle tu restreint l'accessibilité d'une méthode publique, on t'avais dit "attention, toute propriété valide dans la classe de base doit l'être dans la classe dérivée", tu n'aurais sans doute jamais imaginer oser un jour restreindre l'accessibilité d'une méthode dans une classe dérivée, ne serait-ce que parce que tu aurais suivi le raisonnement que je présente dans le fil en question.

Mais, comme tu as sans doutes appris LSP "sur le tard" car on t'as sans doute dit "attention, lorsque tu envisage tel héritage, tu es en contradiction avec lui", et que, d'un autre coté, tu en viens à remarquer qu'il n'y a aucun mécanisme permettant à C++ de garantir qu'il est respecté, tu en viens "naturellement" à t'interroger sur la validité du principe.

Si tu avais eu la chance d'utiliser un langage qui soit capable de garantir le respect de LSP (en existe-t-il seulement ) et qu'il t'avais mis en garde contre le fait que la restriction d'accessibilité d'une méthode dans une classe dérivée déroge à ce principe, tu aurais eu une réaction toute différente, basée sur une réflexion proche de
Ben oui, effectivement, une des propriétés valides pour la classe de base n'est plus valide pour la classe dérivée, je ne peux donc pas envisager l'héritage sous cette forme, ou je dois prendre une décision en ce qui concerne l'accessibilité de ma méthode"
(Tu remarqueras que c'est ma thèse dans le débat dont on parle )

Je quitte ici la réponse à ton intervention, pour passer à quelque chose que je tiens à placer dans cette discussion

Il ne faut pas oublier qu'un langage de programmation, quel qu'il soit, n'est, à l'instar des langues "humaines" qu'une série de conventions qui permettent aux parties en présence de se comprendre et de dialoguer.

Les parties en présence sont, en programmation:

L'homme, d'un coté, avec tous ses doutes et toutes ses certitudes, qui connait plusieurs (dizaines de) milliers de mots, qui accepte une multitude de nuances entre le blanc et le noir, entre le vrai et le faux et

L'ordinateur de l'autre coté, qui ne connait que le 1 et le 0,qui se contente d'appliquer les décisions, "d'appliquer les ordres" en "brave petit soldat" sans s'inquiéter de savoir s'il est opportun, à un moment donné, d'effectuer une action donnée ou s'il ne serait pas préférable de l'effectuer "à un autre moment".

Le compilateur ou l'interpréteur n'agissant que... comme l'interprète qui "traduit le message" pour les différentes parties.

Ce n'est pas parce que l'on change de langage (ou de langue) qu'il faut... changer le message.

Il faut, effectivement, adapter le message pour qu'il suive les conventions en cours et qu'il évite de heurter les sensibilités, mais le fond du message reste, fondamentalement, identique.

Dans le cadre d'un langage de programmation, le fond du message, c'est... la logique qui doit être mise en oeuvre, quel que soit le langage qui servira pour la traduction.

La théorie au sujet de laquelle je plaide pour un apprentissage avant d'apprendre un langage particulier n'a, au final, qu'un seul but : permettre au développeur (débutant) de pouvoir énoncer clairement la logique qu'il demande à l'ordinateur de mettre en oeuvre.

A ce sujet, je n'ai pas choisi les deux premières lignes de ma signature par hasard...(vous aurez sans doute compris le clin d'oeil de la première )

La première nous rappelle qu'il n'est pas utile de multiplier par six puis de diviser par 3 si, tout ce que l'on veut, c'est multiplier par deux.

La deuxième touche au noeud du problème de la programmation: pour énoncer clairement le message que l'on souhaite transmettre à l'ordinateur, il faut, avant tout, correctement le concevoir (tient donc: concevoir et conception ont une racine commune, non )

La "mise au point" du message que l'on veut transmettre doit se baser sur... une théorie sans faille, et doit se faire bien avant de s'adresser "à l'interprète" si on souhaite obtenir au final... quelque chose qui fait ce que l'on attend de lui exactement quand on l'en attend.
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 19/08/2010 à 2:01
Citation Envoyé par pseudocode Voir le message
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
Citation Envoyé par epsilon68 Voir le message
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
2  0 
Avatar de white_tentacle
Membre émérite https://www.developpez.com
Le 19/08/2010 à 11:45
Citation Envoyé par mptijr Voir le message
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).
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 16/08/2010 à 16:59
Citation Envoyé par NoIdea Voir le message

-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
1  0