Je me permets de reprendre une question posée dans le forum Python.
Citation : candide
Apparemment, c'est une question sujet à débats. Je vois d'ailleurs trois débats :
1°) le C++ est-il un bon langage pour découvrir la programmation ?
2°) Le C est-il un meilleur langage que le C++ pour découvrir la programmation ?
3°) Python est-il un bon langage pour découvrir la programmation et permet-il ensuite une approche plus aisée d'autres langages ?
Voilà trois bons sujets de dissertation (thèse, antithèse, synthèse)
Je réponds à ce qu'a dit Nohar :
Citation : nohar
1°) le C++ est-il un bon langage pour découvrir la programmation ?
Je ne le pense pas. C++ est un langage très puissant mais dont la syntaxe est complexe et tellement riche que cela demande un certain effort pour gagner une intuition dessus (au boulot, il m'est déjà arrivé, par exemple, de devoir ré-expliquer à un collègue la différence entre un constchar* et un charconst*). Il laisse le développeur tellement libre de faire ce qu'il veut que lorsque l'on débute, on a beaucoup de mal à identifier la bonne façon d'agir (« dois-je utiliser un pointeur ? un pointeur intelligent ? une référence ? faire une copie ?) : je ne crois pas qu'il soit vraiment utile à un débutant de devoir constamment se poser la question encombrante du niveau d'abstraction auquel il souhaite (ou doit) coder tel ou tel élément de son programme. Je pense au contraire que c'est une source de blocages, là où un autre langage le restreindrait un peu plus, et le ferait plutôt se concentrer sur la bonne conception de son programme (la bonne manière de le découper en fonctions ou en objets, notamment).
Effectivement, C++ est un langage complexe et riche. Pour un débutant, le guidage sera fondamental : le «tuteur» (éventuellement numérique) doit lui cacher certaines notions pour éviter la surcharge cognitive. C'est pour ça que je disais qu'on ne peut donner de réponse absolue, ça dépend, entre autres, de la conception du document d'apprentissage, de ses possibilités de personnalisation.
La question de l'apprentissage direct du C++ se pose. En effet, c'est un langage moderne, puissant et répandu, dont l'apprentissage peut se révéler indispensable ou tout du moins fort utile. Alors commencer par le C ou Python, admettons, mais pour arrêter QUAND l'apprentissage ? Jusqu'où faut-il apprendre pour être suffisamment initié ? C'est une question à laquelle la personne qui se lance dans l'apprentissage ne pourra donner une réponse appropriée (ipso facto car un zéro par définition ne sait pas). Et puis, il y aussi le risque d'être déformé par l'apprentissage d'un langage, par exemple le typage dynamique de Python peut induire des automatismes qui ne seront plus valable en C++.
Citation : nohar
2°) Le C est-il un meilleur langage que le C++ pour découvrir la programmation ?
Je le crois. Simplement parce que le C est un sous-ensemble du C++ qui se suffit à lui-même, et qu'il propose un univers moins vaste. Pour autant, C et C++ ne sont pas assez complémentaires à mon sens pour que cela justifie de pratiquer les deux à la fois…
Là, je ne peux m'exprimer puisque je ne connais pas le C++ mais j'ai cru comprendre -- et je suis de plus en plus convaincu -- que C++, enseigné par un tuteur éclairé, peut faciliter l'apprentissage des débutants. La question est que le tuteur doit savoir cacher certains éléments du langage et attendre que la personne qui apprend soit en mesure de recevoir certaines connaissances.
Citation : nohar
3°) Python est-il un bon langage pour découvrir la programmation et permet-il ensuite une approche plus aisée d'autres langages ?
Je me suis déjà expliqué plein de fois sur ce sujet. Ma réponse est oui.
Je pense que cela peut se discuter, ça dépend des projets de la personne qui apprend, il se peut en particulier que son but ultime soit d'apprendre C++ (ça aurait pu être mon cas). Comme j'ai dit, cela pose deux questions :
-- quand s'arrêter ?
-- certains acquis Python peuvent ralentir l'acquisition de notions C++.
1 et 2, facile (et re-re-re-re-re-dite): non* et non **.
* -> quoique, contre-exemple: /Je me Lance/ de Francis Glassborrow (que je ne saurais jamais écrire), une expérience originale: enseignement du C++ procédural sans OO, sans templates, sans pointeurs, sans exceptions à une dame qui avait touché un peu à tout dans sa vie sauf (encore) à la programmation.
** C reste le pire choix (après un assembleur, ou feu(x) BASIC(s)), le débutant est obligatoirement confronté à des détails complexes, que même le C++ ne lui met pas sous le nez.
3- je dirais "probablement" (même si le langage ne réussit pas à me convaincre -- le simple fait que V{moves}= (sous vim) ne permette pas de réindenter automatiquement un patté de code après refactoring (déplacement massifs de lignes) lui fait perdre beaucoup de points -- face aux autres langages de scripts)
Je pense aussi que l'utilisation de C++ pour commencer la programmation n'est pas le meilleur choix, même si certains documents d'apprentissages s'en sortent sans doute bien.
Pour moi le problème n'est pas tant la complexité dans l'absolu d'un langage dans son ensemble, mais plutôt la quantité de cette complexité qui est imposée aux gens, au lieu d'être seulement proposée. Je prends des exemples que je connais bien, les foncteurs et les objets en OCaml sont des fonctionnalités puissantes et complexes, mais cette complexité se "paie à l'usage"; si on ne s'en sert pas soi-même, on n'est pas confronté à cette complexité. Je pense que les métaclasses de Python entrent aussi dans ce cadre.
Plus précisément encore il y a différents modes d'usages, une distinction classique (que l'on peut raffiner) étant "producteur" et "consommateur" : typiquement, le "producteur" est la personne qui crée une bibliothèque utilisant une fonctionnalité avancée, et le "consommateur" est l'utilisateur de cette bibliothèque; généralement le producteur est celui qui choisit de concevoir son code autour d'une fonctionnalité, et le consommateur est celui qui utilise le code utilisant la fonctionnalité, sans la mettre en place lui-même directement.
Il y a des fonctionnalités qui respectent bien cette barrière. Par exemple, on n'a pas besoin de connaître toutes les finesses de la surcharge d'opérateur pour utiliser du code qui surcharge des opérateurs. Pour les templates C++, c'est un peu plus compliqué : les utiliser en "producteur" est très complexe (c'est une fonctionnalité horrible objectivement, D faisant beaucoup mieux à ce niveau-là), les utiliser en consommateur est raisonnable (on peut s'en servir comme des "génériques" Java/C#, ou plus naïvement des classes indexées par des types)... quand ça marche; quand ça ne marche pas les rapports d'erreurs cassent cette distinction et l'utilisateur se retrouve à payer lui aussi le prix de la complexité.
Un autre exemple de fonctionnalité d'un langage qui n'arrive pour l'instant pas à instaurer une barrière "producteur / consommateur" solide est les signatures des interfaces en Scala. Elles sont très expressives et utiles pour le concepteur d'une bibliothèque, mais on ne sait pas encore présenter à l'utilisateur débutant une signature simple et compréhensible qui "résume", pour un cas d'utilisation simple, la signature fine et compliquée qu'il a aujourd'hui sous les yeux.
Pour moi C++ a trop de fonctionnalités qui envahissent l'utilisateur débutant pour être vraiment agréable pour commencer. Java s'est construit en réponse à cette complexité et je dirais qu'à choisir entre les deux (même si aucun des deux ne me semble un choix désirable), autant choisir Java (ou D par exemple).
Pour moi l'avantage principal de Python est sa syntaxe épurée et surtout le fait de forcer l'indentation. Je pense au billet de Chris Okasaki, In praise of mandatory indentation for novice programmers, qui explique que l'indentation obligatoire aide beaucoup les débutants en les forçant à structurer leur code.
Pour moi, python se définit plus par les erreurs qu'il ne fait pas que par ses qualités intrinsèques (sauf cette consistence de la syntaxe sur lequel les concepteurs ont fait un travail important). Il n'y a rien qui rend Python un choix excitant (au contraire de, par exemple, Scheme, OCaml ou Haskell, où on se dit qu'on va pouvoir faire de belles choses).
Enfin, quelques remarques (qui pourraient être développées en paragraphes complets, mais j'ai pitié des lecteurs et je manque de temps) :
- Je pense qu'il y a de meilleurs choix que d'autres et j'espère avoir fourni des critères qui permettent de justifier objectivement ces décisions, au lieu de se ramener à des questions de préférence personnelles. J'espère que ça motivera les participants à ce sujet à faire de même; je ne critique pas les posts ci-dessus, ils sont peu argumentés factuellement mais je sais qu'ils viennent de gens ayant une large expérience des langages dont il parle et de l'aide aux débutants, donc que leur position est appuyée par l'expérience.
- Malgré l'existence de bons et mauvais choix, je pense qu'un débutant motivé peut s'en sortir quoi qu'il fasse au début (les théories du style "on ne peut pas désapprendre et un mauvais début pourri le cerveau" c'est fun pour troller mais peu crédible). Les discussions "quel est le meilleur choix pour débuter" ayant tendance à être longues et houleuses, il faut savoir quand arrêter d'hésiter et dépenser plutôt son énergie dans l'apprentissage/enseignement proprement dit; le retour sur investissement décroît à partir d'un cerveau niveau de découpe de cheveux en quatre.
- Candide précise qu'on ne peut pas découpler la question de l'apprentissage de celle de l'encadrant; j'insiste aussi qu'on doit se poser la question du support d'apprentissage. Un langage donné peut être un bon choix s'il est accompagné d'un bon livre/document, et un mauvais choix avec un mauvais document. En fait je pense que le cours/document suivi a plus d'importance que le langage choisi. Le SICP par exemple a une bonne réputation auprès d'un certain type d'étudiants (élèves motivés et éduqués scientifiquement) et je pense que ses qualités le placent au dessus du débat "Scheme ou pas".
- "Découvrir la programmation" est assez vague, la question de quoi faire, et en particulier quoi apprendre/enseigner, se pose assez vite. Pour ma part je pense que, quand on débute en programmation, de l'expérience pratique sur de petits programmes est plus utile au début qu'une vision large sur des concepts généraux d'ingénérie logicielle et d'études de gros programmes. Je suis donc tenté par les langages qui permettent facilement de faire un peu d'algorithmique, et j'attache moins d'importance aux fonctionnalités structurantes, en particulier à la programmation orientée objet qui a autant de défauts que de qualité (de la façon dont elle est habituellement enseignée, c'est à dire relativement mal). C'est ce qui me fait considérer favorablement les langages fonctionnels pour débuter (en tout cas pour les étudiant ayant déjà un petit bagage mathématiques). Des gens ayant en tête d'enseigner/apprendre des points différents de la programmation (par exemple de la programmation embarquée en assembleur ou C bizarre) feront, de façon justifiée, des choix différents.
Bon, entièrement d'accord avec le laïus de bluestorm.
Je vais juste rebondir sur un point :
Citation : nohar
2°) Le C est-il un meilleur langage que le C++ pour découvrir la programmation ?
Je le crois. Simplement parce que le C est un sous-ensemble du C++ qui se suffit à lui-même, et qu'il propose un univers moins vaste. Pour autant, C et C++ ne sont pas assez complémentaires à mon sens pour que cela justifie de pratiquer les deux à la fois…
C'est très objectif, mais j'ai tendance à penser le contraire, le C++ serrait plus adapté à un débutant. L'approche de certaines notions en C++ sont plutôt simple (les tableaux, les chaines, ... ), contrairement au C qui est plus bas niveau et ou on doit pensé à des petits détails dût soit à la syntaxe ou encore la gestion mémoire. La manière de programmer en C et C++ diverge en nombreux points, c'est pour cela que j'ai du mal à accepter le fais que le C++ soit un sur-ensemble du C même si à la base, c'était cela.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles- ♡ Copying is an act of love.
Cet inépuisable sujet prend pour une fois une tournure intéressante (dû au forum ?). J'essaye de suivre la même direction...
Certains argument proposés ci-dessus sont assez intéressants, car très valables tout en sortant des habituels ressassements. Je fais le tour :
- un argument (classique) en faveur de python est qu'il force l'indentation. Et c'est assez vrai dans un cadre d'apprentissage. Mais Imghs souligne qu'il est impossible d'utiliser l'indentation automatique, ce qu'à vrai dire j'ai aussi toujours trouvé assez énervant. Alors quoi, va on dire Python serait réservé à l'apprentissage ? J’espère bien que non...
- un argument régulièrement ressorti par candide à l'encontre du langage C++ est la complexité (ou plutôt comme dit bluestorm "la quantité de complexité"). Sincèrement - sans avoir un bagage suffisamment sérieux pour m'estimer compétent, mais je pense pouvoir parler au nom d'apprenant -, j'estime que c'est assez surfait comme réputation. La somme de concepts à connaitre obligatoirement pour commencer à être productif en C++ n'est pas si effrayante.
Le problème est selon moi légèrement différent, et je rejoins plutôt le point de vue de nohar sur ce point : même avec le meilleur support d'apprentissage du monde, l'apprenant est vite confronté au choix d'approfondir ses connaissances en C++ ou en programmation.
En définitive donc, le problème n'est pas tant la somme de complexité à ingérer nécessaire pour programmer, mais plutôt l'imbrication intrinsèque de cette complexité avec jusqu'aux fondements du langage, qui pose problème. Je pense que c'est dû beaucoup à la façon dont ce langage a été créé (C with classes) et a évolué. Pour moi, le C++ est un langage de choix pour les professionnels, mais largement discutable dans un cadre d'apprentissage.
- la question de qualité du support d'apprentissage est aussi fondamentale. Je crois aujourd'hui que c'est l'une des grandes forces de Python : la doc y est excellente.
Il est clair que si envisager le C++ comme langage d'apprentissage est un choix défendable, c'est seulement avec un support adapté, ce qui est relativement rare vu la complexité du langage, et la quantité de cours disponibles qui datent de Mathusalem et qui enseignent des pratiques parfaitement suspectes.
- la dualité langage / paradigme me semble être une piste intéressante à explorer : doit on plus favoriser un langage multi-paradigmes, ou un langage plus spécifique, mais (donc ?) mieux conçu ?
Citation : lmghs
** C reste le pire choix (après un assembleur, ou feu(x) BASIC(s)), le débutant est obligatoirement confronté à des détails complexes, que même le C++ ne lui mets pas sous le nez.
Je ne sais pas ce que tu appelles complexe, mais le C++ n'a absolument rien à envier au C sur ce plan. Après, si tu as une préférence personnelle pour la complexité "haut-niveau", ça peut se comprendre bien sûr.
J'aime beaucoup vos dernières contributions. Je rejoins complètement le long laïus de bluestorm (et bravo pour l'énergie à revendre que tu as ; énergie que je n'ai plus pour me répéter sur ce sujet récurrent).
C'est d'ailleurs exactement ce que Bluestorm explique qui fait que je clame que le C++ est moins pire que le C pour commencer.
Pour répondre à ta question yoch, je mets en balance (mais @ache l'a déjà dit ici ; et moi moult fois ailleurs) :
- std::string vs strcpy, malloc, free, strcat, strlen, etc
- std::vector vs memcpy, malloc, free, etc
- std::cout vs printf et sa redondance faiblement typée (%s, %d, etc)
- std::cin vs scanf et ses pointeurs
Rien qu'avec ces éléments-ci, le C++ est plus simple pour débuter que le C.
En utilisation, RAII+exception vs SESE (et ses "goto error;")+return_codes font que je limite mon utilisation du C aux codes que l'on m'impose de maintenir. Je peste à chaque fois.
Concernant Python, vu que quelqu'un a rebondi sur ma remarque, je n'étais pas attiré initialement (a contrario de ruby que je ne connais pas mieux, ou que OCaml et Haskell qui m'intriguent), et cette histoire d'indentation non automatisable (use-case == refactoring comme je l'ai précisé ; ce n'est pas une histoire de goût sur la bonne taille pour indenter, ni de fainéantise (quoique mon éditeur est bon pour nous les fainéants)), fait que je trouve le langage encore moins sexy maintenant que j'ai eu à maintenir un petit script pour scons.
N.B.: je n'aime pas trop les langages de scripts au départ, ce que ne m'empêche pas de pratiquer très régulièrement, viml, perl et bash.
Maintenant, je pense que Python est un bien meilleur choix que le C++ pour démarrer, et a fortiori le C.
Pour répondre à ta question yoch, je mets en balance (mais @ache l'a déjà dit ici ; et moi moult fois ailleurs) :
- std::string vs strcpy, malloc, free, strcat, strlen, etc
- std::vector vs memcpy, malloc, free, etc
- std::cout vs printf et sa redondance faiblement typée (%s, %d, etc)
- std::cin vs scanf et ses pointeurs
Rien qu'avec ces éléments-ci, le C++ est plus simple pour débuter que le C.
Oui, mais là tu reviens sur d'autres arguments moult fois répétés, effectivement. Le C++ est plus confortable à utiliser que le C (confort tout relatif pour qui fais du Python, par exemple; moi les vector<blabla>:const_iterator, je trouve ça plutôt lassant à lire comme à écrire; Et surtout les rapports d'ereurs de compilation deviennent atroces dés qu'il y a un peu de templates, comme souligné ci-dessus par bluestorm), et j'ajouterai aussi brièvement un argument qui m'est cher : la libC est beaucoup trop pauvre à mon gout.
Ce n'est pas ce que j'appelle complexité: utiliser malloc à tour de bras, ce chi**t certes, mais pas spécialement complexe. En revanche, gérer correctement l'IO par exemple, en C comme en C++, reste assez technique et rebutant à apprendre. D'autres exemples ? Je reprends les tiens, ils sont très parlants :
Citation : lmghs
En utilisation, RAII+exception vs SESE (et ses "goto error;")+return_codes font que je limite mon utilisation du C aux codes que l'on m'impose de maintenir. Je peste à chaque fois.
Tout ça, c'est puissant, c'est parfait pour du développement professionnel, mais ça reste de la complexité ajoutée.
Là je ne disais pas qu'il était plus confortable à utiliser, mais plus simple à enseigner, parce que l'on esquive les pointeurs, les formats de printf, etc. (et c'est toujours de la redite)
Pour le RAII&exceptions, ce n'est pas de la complexité ajoutée, c'est de la complexité retirée. La complexité ajoutée pour le dev professionnel, c'est la bonne gestion des cas dégradés.
EDIT: concernant les erreurs sur la STL, je ne cesse de le dire (mais pas assez), il FAUT installer STLfilt. C'est aussi simple que cela. Ou utiliser clang. Pour les const_iterator, c'est de l'histoire bientôt ancienne -> auto it = v.begin(), ou for(e : v), ou utiliser les algo standards (maintenant utilisables sans avoir à recourir à des foncteurs)
1 et 2, facile (et re-re-re-re-re-dite): non* et non **.
Ah, tu réponds NON à la question 1°) ?
Citation : lmghs
* -> quoique, contre-exemple: /Je me Lance/ de Francis Glassborrow
Lequel ? il y en a deux, et assez anciens au demeurant.
Citation : lmghs
** C reste le pire choix
Je me serais inquiété pour ta santé mentale si tu nous avais dit le contraire
Citation : lmghs
le débutant est obligatoirement confronté à des détails complexes, que même le C++ ne lui mets pas sous le nez.
Ça mériterait un examen beaucoup plus détaillé car ça dépend de jusqu'où l'apprentissage se fait et ce qu'il permet de faire.
Citation : lmghs
3- je dirais probablement (même si le langage ne réussit pas à me convaincre -- le simple fait que V{moves}= (sous vim) ne permette pas de réindenter automatiquement un patté de code après refactoring (déplacement massifs de lignes) lui fait perdre beaucoup de points -- face aux autres langages de scripts)
C'est marrant ta phrase est incomplète, t'as pas donné de réponse oui ou non (ou s'attend à noui )
Mais sinon, tu proposes quel langage pour découvrir la programmation et si à terme on veut apprendre C++ ?
Citation : bluestorm
Pour moi le problème n'est pas tant la complexité dans l'absolu d'un langage dans son ensemble, mais plutôt la quantité de cette complexité qui est imposée aux gens, au lieu d'être seulement proposée.
Je suis en partie d'accord avec cette dichotomie même si dans la réalité de l'apprentissage sur plusieurs années, il s'agit plus d'un continuum. Le problème des documents d'apprentissage et même des cours faits par des enseignants est qu'ils ne savent pas filtrer les contenus (parce que souvent le lectorat ou le public sont tout simplement indéterminé ou hétérogène). Mais un point capital de ces enseignements est de savoir fixer des objectifs concrets (quoi programmer moins que comment «bien» programmer) et de donner les moyens minimaux de réaliser ces objectifs. Dans les cours, ce qu'il faut c'est plus retirer qu'ajouter (less is more comme on dit) quitte à recourir des pratiques non-orthodoxes.
Citation : bluestorm
Il y a des fonctionnalités qui respectent bien cette barrière. Par exemple, on n'a pas besoin de connaître toutes les finesses de la surcharge d'opérateur pour utiliser du code qui surcharge des opérateurs.
Oui, et c'est là que le tuteur a un rôle de filtrage en mettant en accord des objectifs et des moyens. Par ailleurs, il est tout à fait envisageable d'utiliser des fonctionnalités dans un cadre restreint, on utilise une boîte noire, les informaticiens devraient savoir ça, c'est ce qu'on appelle l'encapsulation, c'est juste la distinction entre interface (le tableau de bord) et implémentation (le moteur, thermique ou électrique, c'est indifférent).
Citation : bluestorm
mais on ne sait pas encore présenter à l'utilisateur débutant une signature simple et compréhensible qui "résume", pour un cas d'utilisation simple, la signature fine et compliquée qu'il a aujourd'hui sous les yeux.
Tu soulèves là la question du choix des exemples pour faire comprendre une notion (procédé inductif d'apprentissage). C'est un procédé qui n'est même pas admis universellement parmi les enseignants et les auteurs pour transmettre des connaissances (y compris même dans des tutoriels du sdz). D'autre part, il est à mon avis vain de vouloir présenter à des étudiants une notion X si l'enseignant est incapable de produire à son public un exemple microcosmique qui rende toute la sémantique de la notion X.
Citation : bluestorm
Pour moi C++ a trop de fonctionnalités qui envahissent l'utilisateur débutant pour être vraiment agréable pour commencer.
Toute la question est : commencer oui, mais, pour aller jusqu'où ?
Citation : bluestorm
Pour moi l'avantage principal de Python est sa syntaxe épurée et surtout le fait de forcer l'indentation.
Pour la syntaxe, je suis assez d'accord, pour l'indentation, c'est probablement un avantage de simplicité et de lisibilité mais avec quelques troubles quand même (quand dois-je passe à la ligne ? comment passer une ligne si ma ligne de code est trop longue ? notion d'instruction simple vs composée ; possibilité de passer des lignes de manière factice en ouvrant une parenthèse sans la refermer ; code troublant écrit sans indentation genre whiles>0:s-=1
Citation : bluestorm
Pour moi, python se définit plus par les erreurs qu'il ne fait pas que par ses qualités intrinsèques (sauf cette consistence de la syntaxe sur lequel les concepteurs ont fait un travail important). Il n'y a rien qui rend Python un choix excitant (au contraire de, par exemple, Scheme, OCaml ou Haskell, où on se dit qu'on va pouvoir faire de belles choses).
Il y a une part énorme de subjectivité dans l'«affection» que l'on peut ressentir pour un langage. Et puis, on n'a pas forcément le coup de foudre pour un langage, on le découvre petit à petit et on finit par l'apprécier, ou au contraire, on est tout excité au début par le langage et petit à petit l'excitation diminue et laisse pace à une certaine réserve, etc, je veux dire tous les cas sont possibles.
Citation : bluestorm
- Je pense qu'il y a de meilleurs choix que d'autres et j'espère avoir fourni des critères qui permettent de justifier objectivement ces décisions
Oui mais il faut parler du public (volontaire ou pas), de sa motivation et de ses objectifs, de son background en informatique et sur des questions conceptuelles.
Citation : bluestorm
- Malgré l'existence de bons et mauvais choix, je pense qu'un débutant motivé peut s'en sortir quoi qu'il fasse au début (les théories du style "on ne peut pas désapprendre
Sans doute pour les débutants (qui par définition ne seront pas trop imprégnés pour ne pas pouvoir désapprendre). Par contre, il est très difficile quand on sait et, pire, qu'on sait de façon automatisée, de faire semblant de ne pas savoir, et c'est ce qui peut rendre l'enseignement de la programmation si délicat.
Citation : bluestorm
- Candide précise qu'on ne peut pas découpler la question de l'apprentissage de celle de l'encadrant; j'insiste aussi qu'on doit se poser la question du support d'apprentissage. Un langage donné peut être un bon choix s'il est accompagné d'un bon livre/document, et un mauvais choix avec un mauvais document. En fait je pense que le cours/document suivi a plus d'importance que le langage choisi.
Je suis tout a fait d'accord avec ce point. La qualité du document est essentielle. j'ai envie de dire : il n'y a pas de langage difficile, il n'y a que des mauvais manuels Maintenant, reste la question la plus simple : qu'est-ce qu'un bon support d'apprentissage
Citation : bluestorm
Le SICP par exemple a une bonne réputation auprès d'un certain type d'étudiants (élèves motivés et éduqués scientifiquement) et je pense que ses qualités le placent au dessus du débat "Scheme ou pas".
Oui mais à mon avis ce n'est pas aussi simple. Par exemple, je n'ai aucune envie d'apprendre un langage fonctionnel et savoir qu'un manuel de qualité ne jouera pas directement sur moi. Néanmoins, si j'étais dans l'obligation d'apprendre un langage fonctionnel et que j'aie le choix du langage, cet argument pourrais jouer. Mais en réalité, si je devais un jour choisir tel ou tel langage fonctionnel, c'est tout simplement parce que j'ai un collègue qui le pratiquera.
Citation : bluestorm
- "Découvrir la programmation" est assez vague, la question de quoi faire, et en particulier quoi apprendre/enseigner, se pose assez vite. Pour ma part je pense que, quand on débute en programmation, de l'expérience pratique sur de petits programmes est plus utile au début qu'une vision large sur des concepts généraux d'ingénérie logicielle et d'études de gros programmes.
Je suis tout à fait d'accord mais je mettrais en cause certaines méthodes d'apprentissage qui privilégient
-- la vision top-down
-- la glose conceptuelle
et qui donnent des manuels totalement illisibles pour les débutants et même pour les débutants plus avancés.
Citation : bluestorm
Je suis donc tenté par les langages qui permettent facilement de faire un peu d'algorithmique, et j'attache moins d'importance aux fonctionnalités structurantes, en particulier à la programmation orientée objet qui a autant de défauts que de qualité (de la façon dont elle est habituellement enseignée, c'est à dire relativement mal).
Et hélas, nombreux sont les manuels qui enseignent des concepts de POO qui sont tellement décontextualisés qu'on ne sait même pas les appliquer à l'exercice le plus trivial.
Citation : yoch
- un argument (classique) en faveur de python est qu'il force l'indentation. Et c'est assez vrai dans un cadre d'apprentissage. Mais Imghs souligne qu'il est impossible d'utiliser l'indentation automatique, ce qu'à vrai dire j'ai aussi toujours trouvé assez énervant.
J'ai pas compris le problème : qu'est-ce qu'un indenteur va indenter automatiquement puisque l'indentation fait partie de la syntaxe et donc est obligatoirement choisie par le codeur ?
Citation : yoch
Alors quoi, va on dire Python serait réservé à l'apprentissage ? J’espère bien que non...
Pareil, comprends pas. Tu veux dire que Python est tellement simple qu'il serait réservé à l'apprentissage ?
Citation : yoch
La somme de concepts à connaitre obligatoirement pour commencer à être productif en C++ n'est pas si effrayante.
Ça dépend d'où tu mets le obligatoirement et le pas si effrayant.
Citation : yoch
même avec le meilleur support d'apprentissage du monde, l'apprenant est vite confronté au choix d'approfondir ses connaissances en C++ ou en programmation.
Je vois pas ce tu veux dire en opposant C++ et la programmation en général. Tu veux dire qu'à un certain moment, la personne qui apprend le C++ est amené
-- soit à approfondir le C++
-- soit à passer à un autre langage.
Bon si c'est ça, je vois pas en quoi c'est un problème lié à C++.
Citation : yoch
le problème n'est pas tant la somme de complexité à ingérer nécessaire pour programmer, mais plutôt l'imbrication intrinsèque de cette complexité avec jusqu'aux fondements du langage, qui pose problème.
En disant ça, tu ne fais que confirmer cette opinion selon laquelle C++ est un langage extrêmement complexe à dominer, ce que reconnaissent eux-mêmes les experts et certainement BEAUCOUP plus complexe à dominer que le C.
Cela peut poser problème si on ne sait pas se mettre de limites (mon cas ). Cela peut aussi poser un problème pour des professionnels du C++ parce que, dans beaucoup de cas, cela va les obliger à utiliser beaucoup de fonctionnalités du langage (rien que parce qu'ils doivent partager du code avec de plus experts qu'eux ou parce qu'il y a une nécessité à écrire du code idiomatique même s'il est compliqué et qu'il ne vous est pas naturel) dont des fonctionnalités délicates, ce qui augmente d'autant le temps de maîtrise du langage. Cela peut être excitant pour certains. Moi je trouve ça décourageant.
Citation : yoch
- la question de qualité du support d'apprentissage est aussi fondamentale. Je crois aujourd'hui que c'est l'une des grandes forces de Python : la doc y est excellente.
En valeur relative, elle est certainement meilleure que celle du C ISO (plus lisible, moins formelle). En valeur absolue, c'est inégal, c'est parfois correct mais hélas souvent très absconse, assez peu rigoureuse et exigente et très très perfectible.
Citation : yoch
Il est clair que si envisager le C++ comme langage d'apprentissage est un choix défendable, c'est seulement avec un support adapté,
Jamais rien lu sur C++ (sauf survolé de très très haut le tuto du sdz). En tous cas, je suis positivement étonné par l'intérêt que Bjarne Stroustrup accorde à la qualité et l'exigence de l'enseignement du langage C++ (cf. ses nombreux manuels), ça me donnerait presque l'envie de le lire.
Citation : yoch
- la dualité langage / paradigme me semble être une piste intéressante à explorer : doit on plus favoriser un langage multi-paradigmes,
Pas nécessairement. Mais le multi-paradigme présente un intérêt de réutilisation. Par exemple, le fait d'avoir appris, en partie au moins, les concepts basiques de POO et d'autres (les exceptions, les itérateurs, les mappings, les design patterns, etc) m'aiderait de façon non négligeable si je devais apprendre C++. Sinon, pour moi, le multiparadigme en Python est très déséquilibré : si tu regardes du code pro en Python, c'est presque toujours de la POO, très rarement de la programmation impérative pure.
Citation : yoch
Je ne sais pas ce que tu appelles complexe, mais le C++ n'a absolument rien à envier au C sur ce plan.
Si on dit que le C est complexe alors que dira-t-on du C++ ? En trois-quatre ans et en étant parti du grade de débutant absolu qui a peur quand il entend le mot processeur et étant d'intelligence assez limitée, je suis arrivé à être capable de comprendre, plus que dans les grandes lignes, pratiquement n'importe quel code pro écrit en C, genre le code source de gmp ou de la libc. Je doute énormément qu'il m'aurait fallu le même temps pour du C++ (par exemple, combien d'années avant de pouvoir lire en comprenant une implémentation C++ de la STL ?). Au contraire, je trouve le langage C remarquablement simple et dépouillé une fois qu'on a compris son esprit.
Citation : lmghs
je mets en balance (mais @ache l'a déjà dit ici ; et moi moult fois ailleurs) :
- std::string vs strcpy, malloc, free, strcat, strlen, etc
- std::vector vs memcpy, malloc, free, etc
- std::cout vs printf et sa redondance faiblement typée (%s, %d, etc)
- std::cin vs scanf et ses pointeurs
Rien qu'avec ces éléments-ci, le C++ est plus simple pour débuter que le C.
Absolument. Maintenant, il faudrait voir si on n'est pas rapidement limité. Les bibliothèques permettent-elles en général de se limiter à un contenu aussi restreint ?
Citation : lmghs
on esquive les pointeurs,
Le tuto site du zéro parle des pointeurs. Et si tu veux utiliser une bibliothèque C comme la SDL en C++, tu devras bien utiliser des pointeurs. Tu connais une bibliothèque C++ qui permette de faire du graphisme pour un petit jeu et qui ne fasse appel à aucun pointeur ?
Citation : lmghs
Pour le RAII&exceptions, ce n'est pas de la complexité ajoutée, c'est de la complexité retirée.
Je sais pas ce que c'est que RAII mais un petit tour sur l'article de Wikipedia me montre que conceptuellement ce n'est pas si immédiat. Finalement, la force de l'idiomatisme ne va-t-elle pas m'imposer d'utiliser un monstre comme RAII là ou en C je vais juste avoir besoin de free() et donc pratiquement aucun concept à comprendre ?
Citation : lmghs
EDIT: concernant les erreurs sur la STL, je ne cesse de le dire (mais pas assez), il FAUT installer STLfilt.
An STL Error Message Decryptor for C++ : C++ est tellement simple qu'il faut installer un outil spécial pour décrypter les messages d'erreurs de sa lib standard. Tu es en train de me confirmer ce que je pense : C++ : toujours PLUS et encore PLUS.
Citation : lmghs
C'est aussi simple que cela. Ou utiliser clang.
Le zen de Python dit un truc que j'aime beaucoup :
There should be one-- and preferably only one --obvious way to do it.
1 et 2, facile (et re-re-re-re-re-dite): non* et non **.
Ah, tu réponds NON à la question 1°) ?
b-
Citation : lmghs
* -> quoique, contre-exemple: /Je me Lance/ de Francis Glassborrow
Lequel ? il y en a deux, et assez anciens au demeurant.
c-
Citation : lmghs
le débutant est obligatoirement confronté à des détails complexes, que même le C++ ne lui mets pas sous le nez.
Ça mériterait un examen beaucoup plus détaillé car ça dépend de jusqu'où l'apprentissage se fait et ce qu'il permet de faire.
d-
Citation : lmghs
3- je dirais probablement (même si le langage ne réussit pas à me convaincre -- le simple fait que V{moves}= (sous vim) ne permette pas de réindenter automatiquement un patté de code après refactoring (déplacement massifs de lignes) lui fait perdre beaucoup de points -- face aux autres langages de scripts)
C'est marrant ta phrase est incomplète, t'as pas donné de réponse oui ou non (ou s'attend à noui )
e- Mais sinon, tu proposes quel langage pour découvrir la programmation et si à terme on veut apprendre C++ ?
f-
Citation : bluestorm
Pour moi C++ a trop de fonctionnalités qui envahissent l'utilisateur débutant pour être vraiment agréable pour commencer.
Toute la question est : commencer oui, mais, pour aller jusqu'où ?
g-
Citation : bluestorm
- Candide précise qu'on ne peut pas découpler la question de l'apprentissage de celle de l'encadrant; j'insiste aussi qu'on doit se poser la question du support d'apprentissage. Un langage donné peut être un bon choix s'il est accompagné d'un bon livre/document, et un mauvais choix avec un mauvais document. En fait je pense que le cours/document suivi a plus d'importance que le langage choisi.
Je suis tout a fait d'accord avec ce point. La qualité du document est essentielle. j'ai envie de dire : il n'y a pas de langage difficile, il n'y a que des mauvais manuels Maintenant, reste la question la plus simple : qu'est-ce qu'un bon support d'apprentissage
h-
Citation : yoch
La somme de concepts à connaitre obligatoirement pour commencer à être productif en C++ n'est pas si effrayante.
Ça dépend d'où tu mets le obligatoirement et le pas si effrayant.
i-
Citation : yoch
le problème n'est pas tant la somme de complexité à ingérer nécessaire pour programmer, mais plutôt l'imbrication intrinsèque de cette complexité avec jusqu'aux fondements du langage, qui pose problème.
En disant ça, tu ne fais que confirmer cette opinion selon laquelle C++ est un langage extrêmement complexe à dominer, ce que reconnaissent eux-mêmes les experts et certainement BEAUCOUP plus complexe à dominer que le C.
j-
Citation : yoch
Il est clair que si envisager le C++ comme langage d'apprentissage est un choix défendable, c'est seulement avec un support adapté,
Jamais rien lu sur C++ (sauf survolé de très très haut le tuto du sdz). En tous cas, je suis positivement étonné par l'intérêt que Bjarne Stroustrup accorde à la qualité et l'exigence de l'enseignement du langage C++ (cf. ses nombreux manuels), ça me donnerait presque l'envie de le lire.
k-
Citation : lmghs
je mets en balance (mais @ache l'a déjà dit ici ; et moi moult fois ailleurs) :
- std::string vs strcpy, malloc, free, strcat, strlen, etc
- std::vector vs memcpy, malloc, free, etc
- std::cout vs printf et sa redondance faiblement typée (%s, %d, etc)
- std::cin vs scanf et ses pointeurs
Rien qu'avec ces éléments-ci, le C++ est plus simple pour débuter que le C.
Absolument. Maintenant, il faudrait voir si on n'est pas rapidement limité. Les bibliothèques permettent-elles en général de se limiter à un contenu aussi restreint ?
l-
Citation : lmghs
on esquive les pointeurs,
Le tuto site du zéro parle des pointeurs. Et si tu veux utiliser une bibliothèque C comme la SDL en C++, tu devras bien utiliser des pointeurs. Tu connais une bibliothèque C++ qui permette de faire du graphisme pour un petit jeu et qui ne fasse appel à aucun pointeur ?
m-
Citation : lmghs
Pour le RAII&exceptions, ce n'est pas de la complexité ajoutée, c'est de la complexité retirée.
Je sais pas ce que c'est que RAII mais un petit tour sur l'article de Wikipedia me montre que conceptuellement ce n'est pas si immédiat. Finalement, la force de l'idiomatisme ne va-t-elle pas m'imposer d'utiliser un monstre comme RAII là ou en C je vais juste avoir besoin de free() et donc pratiquement aucun concept à comprendre ?
n-
Citation : lmghs
concernant les erreurs sur la STL, je ne cesse de le dire (mais pas assez), il FAUT installer STLfilt.
An STL Error Message Decryptor for C++ : C++ est tellement simple qu'il faut installer un outil spécial pour décrypter les messages d'erreurs de sa lib standard. Tu es en train de me confirmer ce que je pense : C++ : toujours PLUS et encore PLUS.
o-
Citation : lmghs
C'est aussi simple que cela. Ou utiliser clang.
Le zen de Python dit un truc que j'aime beaucoup : There should be one-- and preferably only one --obvious way to do it.
a- oui, c'est ça.
b- quoi ? Il n'existe qu'un seul Je me Lance de Francis Glassborrow.
Et si tu le trouves "ancien", compare à l'année de publication du standard et aux autres bouquins d'apprentissage du C++ qui sont loin d'être aussi modernes que lui. Ce n'était par exemple pas du tout le cas de la v1 du tuto du sdz.
c- apprentissage iso-fonctionnel p/r à ce que l'on aurait vu en C.
d- Non, non Pourtant cela m'arrive souvent.
J'ai juste oublié le point après la dernière parenthèse fermante. Ces dernières sont parfaitement équilibrées.
Il y a juste la parenthèse à la "--" qui peut être interprétée de deux façons, et vu que je suis d'accord avec les deux façons, j'ai laissé comme ça.
e- excellente question.
J'aurais laissé python (ce n'est pas parce qu'il ne branche pas que je lui reconnais pas un intérêt pédagogique).
Si l'objectif est le C++. Le quatuor Ada/Eiffel/lisp/prolog me parait bien -- la faute au fait qu'il s'agisse en partie de mon cheminement. Les 4 apportent un truc qui aide à comprendre le C++.
Maintenant est-ce que l'on peut passer directement au C++ ? Des expériences semblent dire que oui. Reste qu'il faut voir d'autres approches (fonctionnel, prolog) pour mieux appréhender certains détails très poussés.
Certains veulent du fonctionnel en premier, d'autres de l'OO, et les traditionalistes du procédural. Personnellement, je n'en ai pas la moindre idée. Enfin si: tous les élèves n'ont pas les mêmes facilités avec chaque paradigme/approche. Pour moi, il n'y a pas de bonne méthode universelle. Juste des mauvaises méthodes universelles.
f- Pourquoi critiquer que le C++ emmène jusqu'aux objets si on veut tout apprendre. Si on veut enseigner du procédural dans la famille C, le C++ est offre un sous-ensemble de lui-même plus simple à enseigner que l'équivalent C.
Pourquoi critiquer une berline sous prétexte qu'elle peut monter à 280 ? Oui et ? Perso je ne veux plus de caisses à savons qui ne tiennent encore moins bien la route.
g- Je prends la corrolaire de ce que dit Loic J., sur dvpz, c'est un support qui réussit à enseigner sans heurts (bonne pédagogie) des choses justes.
Un support pédagogue qui enseigne des grosses bêtises, c'est une catastrophe.
Un support incompréhensible, c'est moins pire. Juste totalement inexploitable.
h- Elle est inférieure à l'équivalent C. Elle est équivalente à ce que l'on avait en Pascal ou en Ada.
i- Mais le C++ est bien un des langages les plus complexes à dominer. C'est juste qu'il n'est pas nécessaire de savoir le dominer pour s'en servir, mais d'avoir été initié aux recettes qui le rendent abordable.
j- Bjarne Stroustrup n'a qu'un seul manuel d'enseignement. C'est avant tout de l'enseignement de l’ingénierie informatique (développement). Le langage de support est le C++.
Après il a plusieurs introduction + prologue du bouquin qui sont accessibles librement. Je trouve sa démarche très intéressante.
Son autre ouvrage (pertinent -- à contrario de l'ARM) est un manuel complet sur le langage qui est globalement imbuvable pour apprendre. C'est une excellente référence au demeurant.
k- En retardant les pointeurs pour le dernier chapitre du cours, c'est aussi limité que l'Ada et le Pascal pouvaient l'être. Et on en a faites des choses avec! Et dans ce plan, l'OO est esquivé, et les templates juste utilisés, pas développés (cf la dichotomie de BlueStorm)
C'est juste qu'il n'y a pas de risque d'indigestion sur les pointeurs au second chapitre du cours.
l- Tu ne veux pas utiliser le SDL en C++.
Accessoirement, /Je me Lance/, pour revenir à lui montre comment faire des petites IHM, et il n'y a pas un seul pointeur dans tout le cours!
Enfin, je ne parle pas de ne pas les voir. Cf mon k-.
m- En C, tu as besoin de comprendre ce qu'est un chemin non nominal, et comment les gérer. Et je te prie de croire que des chemins non nominals qui sont mal gérés parce que l'approche C est moins déroutante, mais trop complexe à utiliser correctement, j'en vois. Et un peu trop!
Un free et c'est réglé ? Arf! Etre rigoureux en C doit être une phobie pour les développeurs vu les codes qu'ils pondent. Je ne vois que ça : ils s'enfuient à toutes jambes, et ils corrigeront les problèmes quand les utilisateurs feront des fiches d'anomalie. (oui, j'ai un regard très noir sur notre profession)
n- la faute aux développeurs des compilos qui préfèrent écrire std::basic_string<char, std::char_traits<char> , std::allocator<char>>, au lieu de std::string.
o- ou comment faire des boucles de 3 façons différentes...
Et puis de toutes façons, j'ai été corrompu au perl, alors le "only one way"...
Je vais me permettre de répondre au sujet sans avoir lu tous vos messages
En retraçant très succinctement mon parcours dans l'apprentissage de la programmation, je vais essayer de répondre au titre du sujet.
(Il est important de préciser que je n'ai pas fait d'étude dans la programmation. Je ne suis pas (mais alors pas du tout) dans le milieu.)
(1)
- Le tout premier programme que j'ai fait était sur une CASIO.
- Ensuite quelques trucs en QBASIC, puis en Visual Basic
- Internet se répendant à vitesse grand V, je me suis intéressé à l'HTML et au PHP
(J'ai un peu zappé la programmation pendant quelques années)
- J'ai essayé de me (re)mettre sérieusement au PHP pour un projet perso.
- Comme j'avais besoin d'aide, j'ai découvert ce site, j'ai suivi les cours XHTML/CSS et PHP/MySql
(2)
- Je sais pas ce qu'il m'a pris, mais j'ai suivi les premiers chapitres du cours sur le langage C
- J'apprends actuellement le Java pour reprendre un vieux projet que j'avais en VB. Ce qui me permet en même temps d'apprendre "qu'est-ce que la POO".
Stop ! Revenons au sujet. J'ai écrit 2 étapes (1) et (2).
(1) Langages très haut niveau.
(2) C : langage un peu plus bas niveau, Java : le "tout est objet" m'a un peu perturbé au début
Quand j'ai commencé à lire les cours sur le C et à faire les exercices je me suis dit : "Putain (sorry...) ! Mais d'accord ! Les variables, la mémoire, l'intérêt de bien déclarer, le typage etc. Wahou ! Le PHP comment il fait pour qu'on puisse faire du typage dynamique !!! WTF ! Mais si j'avais su ça avant !"
Sur le coup je pensais que j'aurais dû commencer par le langage C et que j'aurais été moins en galère pour comprendre certaines choses.
Mais avec le recul je me demande si finalement c'est pas l'inverse. Si ce n'est pas le fait de savoir ce qu'est une variable, une fonction etc. qui me permet de lire les cours du langage C sans pleurer.
Donc en me basant sur ma propre expérience, je dirais que pour découvrir la programmation, en plus d'avoir envi et d'être dans le délire*, un langage simple (basic, vb...) c'est pas mal. Ensuite qu'importe le langage, tout dépend de ce qu'on veut faire. Si on est curieux ça permet d'évoluer aussi.
* Quand je dis avoir envi et d'être dans le délire, je pense qu'on programme parce-qu'on a envi naturellement. Pour délirer et faire des choses simples. Je vais encore parler de moi (je sais c'est moche) mais mon premier programme sur ma CASIO il servait à rien ! Il fallait saisir un nombre entre 87 et 108 et il donnait la ou les stations radios qu'on pouvait capter chez moi. En VB mon premier programme c'était un truc pour calculer le score d'un match de rugby : 2 parties, 2 boutons pour chaque partie (Pénalité/Drop ou Essai) et si on cliquait sur le bouton Essai une MsgBox demandait s'il était transformé ou non lol. Dans ma tête c'était magique de pouvoir faire ça. Il faut pas avoir peur de faire des programmes qui servent "à rien".
Je crois que j'ai dérapé en hors sujet (Comment découvrir la programmation plutôt que Quel langage pour découvrir la programmation).
M'enfin je crois que les deux débats sont liés et qu'il faut peut-être plutôt parler de "haut" ou "bas" niveau, de paradigme, de typage au lieu de parler d'un langage spécifique.
- un argument (classique) en faveur de python est qu'il force l'indentation. Et c'est assez vrai dans un cadre d'apprentissage. Mais Imghs souligne qu'il est impossible d'utiliser l'indentation automatique, ce qu'à vrai dire j'ai aussi toujours trouvé assez énervant.
J'ai pas compris le problème : qu'est-ce qu'un indenteur va indenter automatiquement puisque l'indentation fait partie de la syntaxe et donc est obligatoirement choisie par le codeur ?
Tout simplement, lorsque tu "retouche" ton code, en C / C++ tu es bien content d'avoir l'indentation automatique. En Python, rien à faire. Je ne dis pas que c'est un drame, mais c'est un désagrément.
Citation : candide
Citation : yoch
Alors quoi, va on dire Python serait réservé à l'apprentissage ? J’espère bien que non...
Pareil, comprends pas. Tu veux dire que Python est tellement simple qu'il serait réservé à l'apprentissage ?
Non. Je veux dire qu'il est vrai que le choix de Python d'imposer l'indentation est intéressant d'un point de vue éducatif, mais que la question de savoir si les choix doivent être dictés par des impératifs éducatifs ou non n'est pas tranchée. Si c'est gênant, moi je suis contre.
Citation : candide
Citation : yoch
même avec le meilleur support d'apprentissage du monde, l'apprenant est vite confronté au choix d'approfondir ses connaissances en C++ ou en programmation.
Je vois pas ce tu veux dire en opposant C++ et la programmation en général. Tu veux dire qu'à un certain moment, la personne qui apprend le C++ est amené
-- soit à approfondir le C++
-- soit à passer à un autre langage.
Bon si c'est ça, je vois pas en quoi c'est un problème lié à C++.
La programmation, ce n'est pas "passer à un autre langage", justement. La programmation, c'est savoir réaliser certaines chose avec un (des) langages(s). Plus l'apprentissage est tourné vers le "comment", moins grand sera le savoir faire acquis dans le "quoi".
Concrètement, tu ne trouve pas ça dommage qu'au lieu de se faire la main en développant de petites applis intéressante, un apprenant grille sa matière grise à comprendre certaines subtilités obscures d'un langage ? (et c'est valable tant pour le C que le C++).
EDIT :
Citation : niavlys87
Quand j'ai commencé à lire les cours sur le C et à faire les exercices je me suis dit : "Putain (sorry...) ! Mais d'accord ! Les variables, la mémoire, l'intérêt de bien déclarer, le typage etc. Wahou ! Le PHP comment il fait pour qu'on puisse faire du typage dynamique !!! WTF ! Mais si j'avais su ça avant !"
Sur le coup je pensais que j'aurais dû commencer par le langage C et que j'aurais été moins en galère pour comprendre certaines choses.
Mais avec le recul je me demande si finalement c'est pas l'inverse. Si ce n'est pas le fait de savoir ce qu'est une variable, une fonction etc. qui me permet de lire les cours du langage C sans pleurer.
A vrai dire, je me pose souvent la même question : qu'est ce qui serait advenu si j'avais commencé par le PHP : j'aurais détesté la programmation ? je n'aurais pas eu la même démarche ? ni le même niveau (meilleur / pire) ?
Perso, j'ai commencé par le C, qui donne assez vite une habitude de chercher à comprendre comment ça marche sous le capot. Ensuite, lorsque l'on passe à d'autres langages (C++, Python, Scheme par exemple), on se pose vite certaines question. D'un autre coté, difficile de dire si c'est bien ou non, mais cela inhibe effectivement la notion d'abstraction si chère aux développeurs...
Bref, il me parait très plausible de dire que le premier langage conditionne le parcours, surtout dans mon cas où la prog est un simple hobby, pas un métier. Le premier langage (et les premières expériences de codage, à divers degrés) donne ce que j'appellerai "l'intuition" de programmation, c'est une chose qui peut perdurer assez longtemps, voire toujours...
Bref, il me parait très plausible de dire que le premier langage conditionne le parcours, surtout dans mon cas où la prog est un simple hobby, pas un métier. Le premier langage (et les premières expériences de codage, à divers degrés) donne ce que j'appellerai "l'intuition" de programmation, c'est une chose qui peut perdurer assez longtemps, voire toujours...
Presque d'accord avec toi sur ce que j'ai cité !
Le premier langage :
- conditionne le parcours : oui. oui mais *1
- il donne "l'intuition" de programmation : à moité d'accord *2
*1 : Le premier langage conditionne le parcours. Oui mais je pense qu'il y a beaucoup d'autres paramètres (entourage, accès à des cours, projets, ...) qui peuvent conditionner un parcours.
Donc le parcours n'est conditionné qu'à moitié.
*2 : Là on touche à quelque chose de très subtil. J'ai la prétention de comprendre ce que tu veux dire par "l'intuition" de programmation. Je pense que justement, puisqu'il s'agit de quelque chose qui est difficile voire impossible à représenter, c'est propre à chacun. Et je crois que ça évolue.
b- quoi ? Il n'existe qu'un seul Je me Lance de Francis Glassborrow.
Exact, j'avais regardé ses deux livres en anglais.
Citation : lmghs
Le quatuor Ada/Eiffel/lisp/prolog me parait bien
Gloups
Citation : lmghs
f- Pourquoi critiquer que le C++ emmène jusqu'aux objets si on veut tout apprendre. Si on veut enseigner du procédural dans la famille C, le C++ est offre un sous-ensemble de lui-même plus simple à enseigner que l'équivalent C.
Mais ça je critique pas
Citation : lmghs
Pourquoi critiquer une berline sous prétexte qu'elle peut monter à 280 ? Oui et ? Perso je ne veux plus de caisses à savons qui ne tiennent encore moins bien la route.
Je critique pas, je dis juste qu'il faut avoir les moyens de se l'offrir, que ce n'est pas donné à tout le monde, que mon train de vie est modeste et que je préfère juste payer pour ce dont j'ai besoin.
Citation : niavlys87
Quand j'ai commencé à lire les cours sur le C et à faire les exercices je me suis dit : "Putain (sorry...) ! Mais d'accord ! Les variables, la mémoire, l'intérêt de bien déclarer, le typage etc. Wahou ! Le PHP comment il fait pour qu'on puisse faire du typage dynamique !!! WTF ! Mais si j'avais su ça avant !"
Sur le coup je pensais que j'aurais dû commencer par le langage C et que j'aurais été moins en galère pour comprendre certaines choses.
Mais avec le recul je me demande si finalement c'est pas l'inverse. Si ce n'est pas le fait de savoir ce qu'est une variable, une fonction etc. qui me permet de lire les cours du langage C sans pleurer.
Donc en me basant sur ma propre expérience, je dirais que pour découvrir la programmation, en plus d'avoir envi et d'être dans le délire*, un langage simple (basic, vb...) c'est pas mal. Ensuite qu'importe le langage, tout dépend de ce qu'on veut faire. Si on est curieux ça permet d'évoluer aussi.
Merci ne nous avoir rapporté ton expérience et qui montre combien les parcours sont variés pour se retrouver à lire les tutos du sdz. Il n'est pas exclu que ton xp en PHP t'ait aidé pour le C. Maintenant, on ne peut pas généraliser ton approche. Par exemple, ce que j'ai vraiment eu du mal à bouffer en C, c'est les pointeurs et j'aurais fait du PHP avant que ça ne m'aurait pas aidé.
Moi je me suis jamais posé autant de questions (pourquoi ?) sur le typage, la mémoire (question fondamentale pour bien comprendre le C) mais surtout je me suis posé des questions "comment ?". Je trouve que es cors avancés ont trop tendance à intellectualiser.
Pour ce qui est du «délire», je pense que c'est très particulier à toi, moi je n'agis pas du tout comme ça.
Citation : yoch
Tout simplement, lorsque tu "retouche" ton code, en C / C++ tu es bien content d'avoir l'indentation automatique.
Sauf que le C me laisse le loisir d'indenter là où j'ai envie ou presque. Python t'oblige à formater donc l'indenteur n'a plus de raison d'exister. Maintenant, plus que d'indentation, tu veux parler de beautifier, il en existe un qui s'appelle PythoTidy.
Citation : yoch
Non. Je veux dire qu'il est vrai que le choix de Python d'imposer l'indentation est intéressant d'un point de vue éducatif
Je ne pense pas que c'ait été directement dicté par un impératif éducatif. Même pour le programmeur chevronné, l'indentation apporte un énorme avantage de lisibilité et de structuration du code-source.
Citation : yoch
La programmation, ce n'est pas "passer à un autre langage", justement. La programmation, c'est savoir réaliser certaines chose avec un (des) langages(s). Plus l'apprentissage est tourné vers le "comment", moins grand sera le savoir faire acquis dans le "quoi".
Concrètement, tu ne trouve pas ça dommage qu'au lieu de se faire la main en développant de petites applis intéressante, un apprenant grille sa matière grise à comprendre certaines subtilités obscures d'un langage ? (et c'est valable tant pour le C que le C++).
Dans ces cas-là, il faut accepter d'écrire ces applis intéressantes de façon non idiomatique ce qui évite les désagréments des subtilités du langage.
Non. Je veux dire qu'il est vrai que le choix de Python d'imposer l'indentation est intéressant d'un point de vue éducatif
Je ne pense pas que c'ait été directement dicté par un impératif éducatif. Même pour le programmeur chevronné, l'indentation apporte un énorme avantage de lisibilité et de structuration du code-source.
Attention, je n'ai pas dit que l’intérêt de l'indentation est purement éducative (loin s'en faut), j'ai dit que forcer les gens à indenter est éducatif. Je ne vois pas d'autre raison pour justifier ce choix syntaxique : les programmeurs chevronnés indentent de toute façon...
Citation : candide
Citation : yoch
La programmation, ce n'est pas "passer à un autre langage", justement. La programmation, c'est savoir réaliser certaines chose avec un (des) langages(s). Plus l'apprentissage est tourné vers le "comment", moins grand sera le savoir faire acquis dans le "quoi".
Concrètement, tu ne trouve pas ça dommage qu'au lieu de se faire la main en développant de petites applis intéressante, un apprenant grille sa matière grise à comprendre certaines subtilités obscures d'un langage ? (et c'est valable tant pour le C que le C++).
Dans ces cas-là, il faut accepter d'écrire ces applis intéressantes de façon non idiomatique ce qui évite les désagréments des subtilités du langage.
Oui, c'est un peu comme ça que je vois les choses. L'apprentissage doit se faire en frontière entre rigueur et créativité. Sans quoi, l'une va inhiber l'autre et on se retrouve avec des codeurs crades qui écrivent des logiciels, et d'autres codeurs beaucoup plus pointus qui produisent peu.
N'oublions pas que généralement la finalité de l'apprentissage d'un langage est la programmation proprement dite, le langage n'est qu'un outil pour y parvenir. Les questions d'algorithmique sont pour moi nettement plus fondamentales que les questions de langage, et l'expressivité acquise par un novice dans un certain langage est surement plus importante que la rigueur absolue et le fait d’être idiomatique.
Je suis assez perfectionniste moi même, mais j'essaye de toujours garder en tête que le mieux est l'ennemi du bien...
Dans ces cas-là, il faut accepter d'écrire ces applis intéressantes de façon non idiomatique ce qui évite les désagréments des subtilités du langage.
C'est une erreur de croire que c'est une bonne idée de procéder ainsi.
L'idiomatique, c'est la conclusion de l'expérience de nos ainés. C'est grâce à ça que l'on n'ira jamais faire une entrecôte à la vapeur dans une cocotte minute -- jusqu'au jour où un égaré s'y tente et en convainc d'autres des bienfaits de son approche novatrice.
Quand le domaine est déjà compliqué, et que l'outil n'est pas plus simple, apprendre les bonnes recettes auprès des personnes qui sont déjà passées par là est ce qui permet de gagner du temps, sur tous les tableaux.
Pour moi, c'est un peu la différence entre le professionnalisme et le bidouillage.
Selon l'objectif l'une ou l'autre approche est bonne. Je n'ai pas de honte à admettre que pour mon fichier de compil scons, j'ai bidouillé en Python. Accessoirement, je pense que certains langages ne sont pas adaptés au bidouillage typiquement C et C++. Autant utiliser des outils qui conviendront mieux.
Dans ces cas-là, il faut accepter d'écrire ces applis intéressantes de façon non idiomatique ce qui évite les désagréments des subtilités du langage.
C'est une erreur de croire que c'est une bonne idée de procéder ainsi.
L'idiomatique, c'est la conclusion de l'expérience de nos ainés. C'est grâce à ça que l'on n'ira jamais faire une entrecôte à la vapeur dans une cocotte minute -- jusqu'au jour où un égaré s'y tente et en convainc d'autres des bienfaits de son approche novatrice.
Quand le domaine est déjà compliqué, et que l'outil n'est pas plus simple, apprendre les bonnes recettes auprès des personnes qui sont déjà passées par là est ce qui permet de gagner du temps, sur tous les tableaux.
Pour moi, c'est un peu la différence entre le professionnalisme et le bidouillage.
Oui, mais... je préfère apprendre d'abord les bonnes recettes de conception (patterns, etc), justement, plutôt que la façon la plus idiomatique de produire du code spécifique (C++ par exemple), ce qui n'est ni une démarche forcément pérenne (si tout le monde se mettait au Java / C#, à quoi servira tout cet investissement ?), ni une approche particulièrement pédagogique (si tu vise à former des développeurs dans un cadre général).
Et justement, la complexité de l'outil implique une plus grande dispersion dans l'apprentissage. Conclusion : un langage plus simple me parait être tout indiqué pour apprendre ces "recettes" dont tu parles.
Mais, c'est exactement la même chose patterns et idioms.
Les patterns sont des recettes/hacks limités à certains langages. Certains de ces patterns sont multi-langages. Mais pas tous.
Exemple type : le pattern commande qui devient de l'obfuscation dans les langages supportant le fonctionnel. Le visiteur qui perd un gros cas d'utilisation là où le dispatch multiple est supporté. etc.
Et certains patterns ne sont vraiment que des hacks locaux au fond, cf le relase-pattern de Java (transposable à d'autres langages comme le viml ou le python je soupçonne), qui se traduit en using-clause en C#, et en RAII en C++, et en SESE-goto en C. À la racine de tout ça, comprendre que les erreurs sont courantes et qu'il faut les traiter.
Avec les langages dépouillés comme le C, tu peux peut-être comprendre les fondements, mais aussi pourquoi les profs ne les systématisent pas : c'est trop complexe d'enseigner en ayant tous ses codes corrects en C. Seulement, sorti d'un cours bâclé, tu deviens fainéant et te refuse à apprendre les idiomes du langages que tu utilises pour produire des trucs robustes, parce que au fond, c'est comme ça que tu avais appris.
NON! Stop. Quand on apprend un outil complexe, il faut l'apprendre correctement et pas chouiner en rejetant le tord sur l'outil parce que l'on ne veut pas apprendre à l'utiliser correctement.
Ou apprendre d'autres trucs, oui.
Mais, on commence à parler dans le vide en perdant le sujet de la discussion.
Je ne vois pas d'autre raison pour justifier ce choix syntaxique : les programmeurs chevronnés indentent de toute façon...
Justement, autant économiser cette étape puisque finalement tout le monde est d'accord sur la nécessité d'y passer et avec l'avantage que ceux qui ne savent pas indenter (cf. les centaines de post sur le forum C) le font sans s'en rendre compte. Sans compter que ça évite les guerres de religions stériles sur les styles d'indentation (le défilé de mode : le style gnu, le style K&R, etc).
Citation : yoch
N'oublions pas que généralement la finalité de l'apprentissage d'un langage est la programmation proprement dite, le langage n'est qu'un outil pour y parvenir. Les questions d'algorithmique sont pour moi nettement plus fondamentales que les questions de langage, et l'expressivité acquise par un novice dans un certain langage est surement plus importante que la rigueur absolue et le fait d’être idiomatique.
Ça se discute. Pour moi, la finalité de programmer c'est de produire des applications, des outils logiciels, j'ai une vue utilitariste et pas du tout intellectualiste (je ne dis pas d'ailleurs que c'est ta vision). Donc, le langage a un rôle capital et moi je considère qu'un utilisateur qui veut écrire des applications avec toutes les qualités requises doit bien connaître le langage qu'il utilise car justement le langage ne doit pas freiner sa créativité et sa productivité et même, le programmeur doit connaître (à terme) toutes les ficelles qui lui permettent d'être plus efficace dans les implémentations des appli qu'il veut créer. A la limite, peu importe le langage mais au moins bien connaître le langage utilisé. Mais bon, je sais que c'est une vision un peu idéaliste. C'est aussi pour ça que personnellement je ne me lancerai jamais vraiment dans le C++ car le langage est vraiment trop riche, trop complexe pour que dans un temps raisonnable je sois capable d'en percevoir et d'en utiliser toutes les subtilités.
Citation : lmghs
C'est une erreur de croire que c'est une bonne idée de procéder ainsi.
L'idiomatique, c'est la conclusion de l'expérience de nos ainés. C'est grâce à ça que l'on n'ira jamais faire une entrecôte à la vapeur dans une cocotte minute -- jusqu'au jour où un égaré s'y tente et en convainc d'autres des bienfaits de son approche novatrice.
Je suis tout à fait d'accord avec toi, : l'idiomatisme est une accumulation d'expériences et il faut s'y plier. Le problème est que d'acquérir les idiomatismes est très long (un idiomatisme est propre à un locuteur natif donc celui qui est déjà fluent donc pas le débutant) et qu'il faut juste accepter au cours d'un apprentissage des entorses à la règle de l'idiomatisme. Contraindre une personne qui apprend a utiliser systématiquement les idiomatismes est contre-productif.
Citation : lmghs
Avec les langages dépouillés comme le C, tu peux peut-être comprendre les fondements,
les fondements de quoi ?
Citation : lmghs
mais aussi pourquoi les profs ne les systématisent pas : c'est trop complexe d'enseigner en ayant tous ses codes corrects en C.
J'ai du mal à comprendre ce que tu veux dire. Les prof de C ne systématisent pas les fondements, ça ne veut rien dire. Tu veux peut-être dire que les prof ne systématisent pas l'enseignement des fondements (je sais toujours pas de quels fondements tu parles) mais alors ensuite je ne vois pas du tout le rapport avec le fait que les codes C ne sont pas corrects, j'arrive pas à comprendre où tu veux en venir : si les profs de C sont incompétents ou si c'est carrément le langage C qui est, d'une certaine façon, inapte à produire des implémentations correctes.
Citation : lmghs
NON! Stop. Quand on apprend un outil complexe, il faut l'apprendre correctement et pas chouiner en rejetant le tord sur l'outil parce que l'on ne veut pas apprendre à l'utiliser correctement.
Oui mais, avec ta logique, apprendre l'outil complexe en question (le C++ je suppose puisque le C est irrécupérable) est un travail d'une vie entière.
Je me permet de répondre, car n'ayant jamais eu de cours de programmation, les questions de Candide sont clairement adaptées à ma situation.
Citation
1°) le C++ est-il un bon langage pour découvrir la programmation ?
Non !!! J'ai voulu, avant python, commencer par le C et le C++. Pour une personne n'ayant jamais vu ce qu'était la programmation, c'est totalement inadapté et incompréhensible (syntaxe) et là je ne parle même pas de l'algorithme, qui pour moi, est un autre sujet.
Mais je trouve que ce genre de question doit apporter différents points de vue, selon les différents bagages théoriques que l'on pourrait avoir. C'est donc de mon avis personnel dont je parlerais à la suite de ce post.
Citation
Le C est-il un meilleur langage que le C++ pour découvrir la programmation ?
Non !!! Là je parle avec le cœur et par expérience, car j'avais commencé par le C avant le C++.
Citation
Voilà trois bons sujets de dissertation (thèse, antithèse, synthèse)
Pas besoin c'est ultra visible (syntaxe), il suffit de l'avoir vécu!
Citation
Python est-il un bon langage pour découvrir la programmation et permet-il ensuite une approche plus aisée d'autres langages ?
Oui!!! C'est grâce à lui (le langage) que j'ai pu rentrer dans le monde de la programmation, et c'est grâce à lui que j'ai pu me mettre au C++ puis au C et enfin à Haskell.
Mieux vaut parler de son expérience que de parler pour les autres
Dans le débat il y a eu quelques malentendus, sur la notion de langage simple. Je crois qu'il y a une distinction importante à faire entre langage simple et langage facile.
Un langage est simple s'il contient un nombre de concepts assez limité, et qu'on peut apprendre tout ce qu'il y a à savoir sur le langage en lui-même (syntaxe, sémantique) en peu de temps. Cela ne veut pas dire qu'il est facile. Le brainfuck est un langage des plus difficiles, mais aussi l'un des plus simples. Le C est un langage relativement simple (plus simple que Python, en fait) mais aussi relativement difficile (plus difficile que Python).
Je pense qu'il vaut mieux commencer avec un langage facile, pour ne pas être frustré dès le départ. Mais l'autre question est : faut-il commencer par un langage simple ? Le problème est qu'un langage facile est souvent plus complexe, car la facilité d'utilisation est obtenue au prix de nombreux concepts et d'abstractions. Je vois deux solutions :
Apprendre un sous-ensemble simple d'un langage facile, en mettant provisoirement de côté la complexité sous-jacente du langage. Certains langages arrivent très bien à cacher la complexité à l'utilisateur (OCaml, Python), d'autres beaucoup moins (C++).
Apprendre un langage naturellement simple et (relativement) facile. Néanmoins ce genre de langage est assez rare.
Dans la deuxième optique, j'aime bien Scheme. Scheme est extrêmement minimaliste et simple au niveau des concepts employés, mais il permet malgré cela un très haut niveau d'abstraction. C'est certainement un bon langage pour débuter (mais pas seulement). Dans la première optique, OCaml est intéressant, Python également (ce dernier étant plus facile, mais moins adapté à l'apprentissage de l'algorithmique).
a- Je suis tout à fait d'accord avec toi, : l'idiomatisme est une accumulation d'expériences et il faut s'y plier. Le problème est que d'acquérir les idiomatismes est très long (un idiomatisme est propre à un locuteur natif donc celui qui est déjà fluent donc pas le débutant) et qu'il faut juste accepter au cours d'un apprentissage des entorses à la règle de l'idiomatisme. Contraindre une personne qui apprend a utiliser systématiquement les idiomatismes est contre-productif.
b-
Citation : lmghs
Avec les langages dépouillés comme le C, tu peux peut-être comprendre les fondements,
les fondements de quoi ?
c-
Citation : lmghs
mais aussi pourquoi les profs ne les systématisent pas : c'est trop complexe d'enseigner en ayant tous ses codes corrects en C.
J'ai du mal à comprendre ce que tu veux dire. Les prof de C ne systématisent pas les fondements, ça ne veut rien dire. Tu veux peut-être dire que les prof ne systématisent pas l'enseignement des fondements (je sais toujours pas de quels fondements tu parles) mais alors ensuite je ne vois pas du tout le rapport avec le fait que les codes C ne sont pas corrects, j'arrive pas à comprendre où tu veux en venir : si les profs de C sont incompétents ou si c'est carrément le langage C qui est, d'une certaine façon, inapte à produire des implémentations correctes.
Citation : lmghs
NON! Stop. Quand on apprend un outil complexe, il faut l'apprendre correctement et pas chouiner en rejetant le tord sur l'outil parce que l'on ne veut pas apprendre à l'utiliser correctement.
Oui mais, avec ta logique, apprendre l'outil complexe en question (le C++ je suppose puisque le C est irrécupérable) est un travail d'une vie entière.
a- ce ne sont pas les étudiants qu'il faut contraindre aux idiomatismes. Ce sont les enseignants! Commençons déjà par là.
Les conséquences ? Les étudiants apprennent les idiomatismes sans même s'en rendre compte. Et cerise sur le gâteau : le code que l'on utilise pour les former est plus simple et donc ils retiennent mieux les leçons.
C'est gagnant-gagnant sur toute la ligne.
b- Je suis dans la continuité de mon paragraphe précédent : les fondement de comment écrire des codes qui ne tournent pas au pays magique où tout va toujours bien.
c- [Fort de la réponse b-] As-tu déjà vu beaucoup de cours de C qui, dans leurs exemples systématisent, le test des codes de retour de toutes les fonctions qui peuvent échouer ? Et qui propagent les erreurs ? Et qui nettoient derrière eux ?
Regarde les tutos sur les listes chainées. Les échecs d'allocation se sont pas propagés jusqu'à l'utilisateur.. Ou encore le tuto sur les chaines à taille variables qui enseigne exit(FAILURE) sur les échecs d'allocation...
C'est un langage qui n'aide pas les profs à enseigner des choses correctes -- si tant est qu'ils sachent le faire.
Ou je voulais en venir ? Hum ... difficile de répondre car on s'étale et arguments/contre-arguments & cie sur 3-4 personnes et j'avoue perdre le fil ^^'
Voyons voir.
Après relecture. Ce que je critique : "un langage simple permet d'apprendre mieux". C'est faux.
Le C est plus simple que Python (pas d'exception, pas de fonctionnel, pas de structures de données évoluées, etc. Il n'y a guère que les assembleurs, mieux les micro-assembleurs à être plus rudimentaires -- dans les langages utiles). Mais Python permettra de mieux apprendre.
[Je m'éloigne du perpétuel C <-> C++ vu que vous connaissez mieux Python que C++ pour la plus part d'entre vous et qu'il y a confusion entre la compléxité du langage (et de tous les paradigmes qu'il embarque) et sa facilité d'utilisation. (je sens que fred a compris où je voulais en venir)]
Mais je trouve que ce genre de question doit apporter différents points de vue, selon les différents bagages théoriques que l'on pourrait avoir. C'est donc de mon avis personnel dont je parlerais à la suite de ce post.
Citation : fred1599
Mieux vaut parler de son expérience que de parler pour les autres
Je pense en effet très important pour pouvoir tirer des informations utiles de recevoir de vrais témoignages de parcours d'apprentissage plutôt qu'une glose des parcours possibles. Donc merci de ton témoignage.
Citation : fred1599
Citation
1°) le C++ est-il un bon langage pour découvrir la programmation ?
Non !!! J'ai voulu, avant python, commencer par le C et le C++.
Pourrais-tu être plus précis ? Tu as commencé par le C ou par le C++ ?
Citation : fred1599
Pour une personne n'ayant jamais vu ce qu'était la programmation, c'est totalement inadapté et incompréhensible (syntaxe)
Peux-tu être plus précis ? De quelle syntaxe incompréhensible parles-tu ? Moi j'avais trouvé que la syntaxe du C était compliquée à partir des pointeurs. Bon avant, y'avait des choses que j'avais pas trouvé totalement claires comme quand mettre un point virgule ou pas le mettre, en particulier avec les instructions composées (if, while, for). Un truc que j'ai eu un peu de mal à clarifier c'est où mettre les déclarations de fonctions, s'il fallait ou pas utiliser un prototype. J'ai eu aussi pas mal de difficulté à comprendre
-- le processus de programmation (édition, compilation, warning vs erreurs, exécution) et en particulier le couplage entre le code source et l'exécution réelle,
-- le rôle de la lib standard par rapport au C,
-- le processus de création de l'exécutable et le rôle des bibliothèques (surtout que le bouquin que javais parlais assez tôt de lib statiques vs lib dynamiques),
-- le rôle de la mémoire (au-delà des banalités habituelles que c'est dans la RAM, que c'est un graaaaaaannnnndddddd tableau numéroté avec des adresses auquelles on accède),
-- etc, etc,
Ce que je veux dire c'est que pour moi, les difficultés n'étaient pas du tout uniquement d'ordre syntaxique mais en fait à tous les niveaux.
Ce serait bien aussi si tu pouvais nous dire avec quel support tu avais essayé d'apprendre le C.
Citation : fred1599
Citation
Le C est-il un meilleur langage que le C++ pour découvrir la programmation ?
Non !!! Là je parle avec le cœur et par expérience, car j'avais commencé par le C avant le C++.
Je n'arrive pas à interpréter comme il faut ta réponse. Par définition, on ne commence qu'avec un seul langage. Après le C, tu as fait du C++ te disant que le C++ était différent du C et que son abord serait plus facile ou alors tu t'es lancé dans le C++ après avoir appris Python ? Ta réponse signifie t-elle que, rétrospectivement, tu considères que le C++ est encore plus compliqué pour débuter que le C ?
Citation : fred1599
Oui!!! C'est grâce à lui (le langage) que j'ai pu rentrer dans le monde de la programmation, et c'est grâce à lui que j'ai pu me mettre au C++ puis au C et enfin à Haskell.
OK mais là encore, ce serait bien si on avait quelques détails. Est-ce que Python a eu un effet juste psychologique libératoire (genre : oui, je suis capable de programmer et donc je peux me lancer dans d'autres langages) ou alors les connaissances en programmation Python sont, au moins en partie, transférables à l'apprentissage d'autres langages ?
Citation : anmee
Dans le débat il y a eu quelques malentendus, sur la notion de langage simple. Je crois qu'il y a une distinction importante à faire entre langage simple et langage facile.
Un langage est simple s'il contient un nombre de concepts assez limité, et qu'on peut apprendre tout ce qu'il y a à savoir sur le langage en lui-même (syntaxe, sémantique) en peu de temps. Cela ne veut pas dire qu'il est facile. Le brainfuck est un langage des plus difficiles, mais aussi l'un des plus simples. Le C est un langage relativement simple (plus simple que Python, en fait) mais aussi relativement difficile (plus difficile que Python).
Je ne suis pas convaincu par la pertinence de ta distinction. on peut apprendre tout ce qu'il y a à savoir sur le langage en lui-même (syntaxe, sémantique) en peu de temps pour le C ? je ne suis pas convaincu, quand tu vois le genre de nuances qu'il faut piger entre i++ et ++i, le langage a beau être simple (disons pauvre, par rapport au C++ en tous cas), je trouve qu'il faut beaucoup de temps pour tout comprendre si on part vraiment de zéro.
Citation : anmee
Je pense qu'il vaut mieux commencer avec un langage facile, pour ne pas être frustré dès le départ.
Ou en tous cas, il faut permettre un enseignement qui permette à celui qui apprend de produire et de ne pas être découragé.
Citation : anmee
Scheme est extrêmement minimaliste et simple au niveau des concepts employés, mais il permet malgré cela un très haut niveau d'abstraction. C'est certainement un bon langage pour débuter
C'est quoi ton critère pour être un bon langage pour débuter ?
Citation : lmghs
a- ce ne sont pas les étudiants qu'il faut contraindre aux idiomatismes. Ce sont les enseignants! Commençons déjà par là.
Ça c'est très possible en effet, surtout pour le C.
Citation : lmghs
Les conséquences ? Les étudiants apprennent les idiomatismes sans même s'en rendre compte. Et cerise sur le gâteau : le code que l'on utilise pour les former est plus simple et donc ils retiennent mieux les leçons.
C'est gagnant-gagnant sur toute la ligne.
Non, ça c'est une vue de l'esprit. Un idiomatisme, c'est un automatisme qui s'acquiert après un travail de répétition et compréhension (un idiomatisme est souvent -- pas toujours -- cryptique parce que justement il est propre à l'idiome et donc il n'a rien de naturel ; un idiomatisme doit être compris car on a souvent des idiomatismes paramétrés et si l'idiomatisme n'est pas compris, on reste à des versions restreintes de l'idiomatisme).
Citation : lmghs
b- Je suis dans la continuité de mon paragraphe précédent : les fondement de comment écrire des codes qui ne tournent pas au pays magique où tout va toujours bien.
OK, tu veux donc parler de connaissance approfondie, le prix fort de l'apprentissage.
Citation : lmghs
c- [Fort de la réponse b-] As-tu déjà vu beaucoup de cours de C qui, dans leurs exemples systématisent, le test des codes de retour de toutes les fonctions qui peuvent échouer ? Et qui propagent les erreurs ? Et qui nettoient derrière eux ?
Des cours de C qui enseignent ça, pas vraiment, et c'est normal, la gestion des exceptions ne fait pas partie du langage ni de sa bibliothèque standard (bon à part atexit ou errno), donc cette question est plus du ressort du "génie logiciel" que de l'apprentissage du langage. Sinon, le mécanisme de transmission via des codes d'erreur dont tu parles me semble digne de la simplicité du C. De toute façon, si j'en juge à ce que j'ai appris de Python, incorporer une gestion des exceptions dans un langage ajoute BEAUCOUP de complexité à l'apprentissage du langage et moi j'ai trouvé assez difficile de comprendre tous les mécanismes associés.
Citation : lmghs
Regarde les tutos sur les listes chainées. Les échecs d'allocation se sont pas propagés jusqu'à l'utilisateur.. Ou encore le tuto sur les chaines à taille variables qui enseigne exit(FAILURE) sur les échecs d'allocation...
Ça ne me choque pas plus que ça, c'est volontairement schématique, le but étant d'apprendre le concept de listes chaînées. Un enseignant doit masquer certaines connaissances pour éviter la surcharge.
Citation : lmghs
C'est un langage qui n'aide pas les profs à enseigner des choses correctes -- si tant est qu'ils sachent le faire.
On croit presque entendre que tu dis que c'est un langage qui ne permet pas de faire les choses correctement (ou alors avec un prix ...). De toutes façons, comme le C est assez rustique et assez enseigné, c'est parfois un petit peu n'importe qui l'enseigne. Et puis, en général, le C n'est pas enseigné à un niveau avancé (on n'enseigne plus le C en Master par exemple) donc si un programmeur doit coder du C propre et sûr c'est à lui de se renseigner par lui-même ou bien dans le sérail comment on s'y prend.
Je ne suis pas convaincu par la pertinence de ta distinction. on peut apprendre tout ce qu'il y a à savoir sur le langage en lui-même (syntaxe, sémantique) en peu de temps pour le C ? je ne suis pas convaincu, quand tu vois le genre de nuances qu'il faut piger entre i++ et ++i, le langage a beau être simple (disons pauvre, par rapport au C++ en tous cas), je trouve qu'il faut beaucoup de temps pour tout comprendre si on part vraiment de zéro.
Oui, bien sûr. Mais tout est relatif. S'il faut du temps pour connaître l'ensemble du C, il en faut encore plus pour connaître l'ensemble d'OCaml par exemple. Et la différence entre i++ et ++i, excuse-moi, mais c'est de la rigolade par rapport aux nuances qu'on peut trouver dans les autres langages (Haskell, C++ et tout). Je trouve que les langages hautement abstraits font semblant d'être simples, alors qu'ils ne le sont pas. Mais peut-être que mon usage du mot 'simple' est trompeur ? Mais je ne trouve pas d'autre mot ('pauvre' est un peu trop péjoratif à mon goût, alors que la simplicité n'est pas nécessairement un inconvénient, comme le sait tout programmeur Scheme).
Citation : candide
C'est quoi ton critère pour être un bon langage pour débuter ?
Je l'ai dit : globalement, un langage qui permette de produire des résultats rapidement (donc un langage facile, bien que le rapprochement soit un peu naïf), et qui est conceptuellement simple. Scheme est très simple conceptuellement et encore plus syntaxiquement (il n'y a pas vraiment de syntaxe...). De plus, il permet de produire du résultat assez rapidement.
Mais je comprends que quelqu'un de très pragmatique n'aurait pas très envie de faire du Scheme. D'un point de vue 'utilitariste' comme tu le dis, Python est supérieur. C'est tout là l'intérêt d'avoir le choix. Personnellement, je ne programme pas juste pour le produit lui-même (l'application), à vrai dire je m'en fous un peu de ça. C'est le chemin lui-même qui m'intéresse, pas ce qu'il y a au bout. Et heureusement, sinon je trouverais la programmation fatigante à force. Excusez-moi de m'écarter du sujet initial.
(Je réponds à un post en particulier mais ça ne veut pas dire que les autres ne m'ont pas intéressé, je les ai lus en détail)
Citation : anmee
Un langage est simple s'il contient un nombre de concepts assez limité, et qu'on peut apprendre tout ce qu'il y a à savoir sur le langage en lui-même (syntaxe, sémantique) en peu de temps. Cela ne veut pas dire qu'il est facile. [..]
Scheme est extrêmement minimaliste et simple au niveau des concepts employés, mais il permet malgré cela un très haut niveau d'abstraction. C'est certainement un bon langage pour débuter (mais pas seulement). [Si l'on se restreint à un sous-ensemble simple] OCaml est intéressant, Python également (ce dernier étant plus facile, mais moins adapté à l'apprentissage de l'algorithmique).
Cette vision raisonne assez bien avec mon propre avis sur la situation. Je suis globalement d'accord même si je trouve que les définitions pourraient être plus précises (d'ailleurs tu ne définis pas "facile").
Scheme est effectivement à la fois un langage construit sur une base simple, et qui permet de développer sans difficultés particulières des applications intéressantes. En pratique, même si Lisp/Scheme sont de très bons défenseurs de la simplicité et de l'orthogonalité des fonctionnalités, Scheme reste un langage "deuxième approche" pour l'apprentissage, au même niveau que Caml je dirais; tu ne vas pas présenter les macros aux débutants (en tout cas, pas comment en définir soi-même), et d'ailleurs ce sont des fonctionnalités qui ne sont pas "simples" (ou alors pas faciles, selon qu'on inclus l'hygiène ou non, etc.). Mais effectivement, "enseigner un sous-ensemble de Scheme/OCaml" me semble un bon choix; n'ayant pas d'expérience d'enseignement ou d'aide des débutants en Python, je n'ai pas vraiment d'avis sur la question.
Je reviens sur Python : je ne vois pas vraiment de raison de choisir Python, sinon la syntaxe avec indentation obligatoire et d'éventuelles bibliothèques logicielles qu'on a en vue pour la suite. Par exemple, on enseigne Python aux physiciens (sauf quand on leur enseigne C ou Fortran... gloups) parce que c'est de plus en plus le langage de glue entre les outils utilisés, ça fait sens. Pareil pour l'exemple des universités qui enseignent Python pour utiliser telle bibliothèque de robotique bien précise.
Pourrais-tu être plus précis ? Tu as commencé par le C ou par le C++ ?
Par le C, quelle expérience horrible quand j'y pense
Citation : candide
Moi j'avais trouvé que la syntaxe du C était compliquée à partir des pointeurs
Idem pour moi, à partir de là j'ai un peu abandonné, puis c'est passé au moins 1 an voir plus avant de revenir dessus et de comprendre le strict minimum, c'est à dire son intérêt et la syntaxe simple de son utilisation.
Citation : candide
De quelle syntaxe incompréhensible parles-tu ?
Les malloc, calloc, realloc, les pointeurs, free, fuites de mémoire et j'en passe...
En ce qui concerne tes difficultés sur les bases du C, je les ai connu aussi je te rassure...
On se préoccupe trop de la machine et pas suffisamment du code en lui-même.
Citation
Ce serait bien aussi si tu pouvais nous dire avec quel support tu avais essayé d'apprendre le C.
En fait pour les bases ce n'est pas très important, ce que je recherchais, c'est le fait de tester ligne par ligne mon code (un interpréteur quoi), car le fait de rentrer un minimum de code pour compiler ça me gavait.
Citation
Je n'arrive pas à interpréter comme il faut ta réponse. Par définition, on ne commence qu'avec un seul langage. Après le C, tu as fait du C++ te disant que le C++ était différent du C et que son abord serait plus facile ou alors tu t'es lancé dans le C++ après avoir appris Python ? Ta réponse signifie t-elle que, rétrospectivement, tu considères que le C++ est encore plus compliqué pour débuter que le C ?
En considérant que je n'ai appris plusieurs langage en même temps, voici l'ordre d'apprentissage
0) C (échec fatal, voir écœuré)
1) Python (le plus accessible en ce qui me concerne)
2) C (au bout de 3 ans de python quand même, et un mieux avec une petite compréhension basique des pointeurs)
3) C++ (au bout de 6 mois après le C pour apprendre l'interfaçage avec python), il m'a permis de progresser avec PyQt et me réconcilier avec sa documentation.
4) Haskell (pour le fun et rencontrer un langage fonctionnel, autre façon de penser, de voir les choses)
5) Scheme (on a pas été copain, catastrophe, pas du tout aimé, mauvaise expérience en ce qui me concerne)
6) PHP, XHTML, ... (je ne suis pas fais pour le langage web, mais alors pas du tout)
Citation
OK mais là encore, ce serait bien si on avait quelques détails. Est-ce que Python a eu un effet juste psychologique libératoire
Il y a du vrai, mais l'essentiel était surtout la capacité de programmer et de découvrir des concepts de la programmation.
Le fait qu'en C ou C++ tu dois déjà beaucoup te concentrer sur plusieurs concepts à la fois (syntaxe, mémoire, pointeurs) c'est trop pour quelqu'un qui n'a que l'envie de programmer un programme basic.
Citation
Ta réponse signifie t-elle que, rétrospectivement, tu considères que le C++ est encore plus compliqué pour débuter que le C
Ah eh bien effectivement tu n'as pas du me comprendre sur ce coup
Non, j'ai trouvé le C++ plus abordable, mais le contexte n'était pas le même (commencé par le C a été mortel pour moi). Cependant la notion de référence m'a beaucoup plus parlé que la notion de pointeur en C, depuis je n'utilise plus que le C++ et cette notion de référence.
Je ne répond pas à toutes tes questions car souvent on tomberait dans la redondance.
Plus ou moins bon langage pour découvrir la programmation
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.