Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Effectivement, nous avons actuellement des cours d'algo sur les listes, listes circulaires, piles, les files, les arbres binaires, les recherches, ... et c'est très bien. Mais je crois que l'objectif du topic était plutôt centré sur l'apprentissage du C++, comment il était enseigné ce qui entraînait justement des cas de personnes faisant du C with classes.Parce que, si c'était le cas, ca justifierait les cours de C et d'algorithmes de l'école citée précédemment...
Dieux sait que j'adore écrire, que ce soit du code ou de longues proses...
Cependant, un des cours que j'ai eu s'attachait principalement aux représentations algorithmiques et aux différentes structures dynamique (tableau, pile, liste, file, ...) de manière tout à fait indépendante de tout langage de programmation.
Au final, j'en suis donc à considérer le langage de programmation comme... un "moyen de faire comprendre ce que l'on veut à quelque chose d'aussi bête que l'ordinateur" et comme un "long et fastidieux travail de dactylographie" tant j'estime que tout le travail réellement intéressant doit (devrait) avoir été fait bien avant d'avoir écrit la première ligne de code (ou refait avant d'écrire la suite).
Je suis aussi persuadé qu'une bonne implémentation d'un bon algorithme dans un "mauvais" (comprenez: lent à l'exécution, quelle que soit la raison de cette lenteur) sera toujours bien plus efficace que la mauvaise implémentation d'un bon algorithme ou que la bonne implémentation d'un mauvais algorithme dans un "bon" (comprenez: rapide à l'exécution) langage.
On rencontre en effet des choses immuables:
Et donc, au risque d'étendre le débat, je dirais que l'apprentissage devrait effectivement être très "segmenté":
- une comparaison entre deux chaines prendra immanquablement plus de temps que la comparaison entre deux entier
- la recherche dans une liste prendra immanquablement plus de temps que la recherche dans un tableau trié ou dans un arbre binaire (qui autorisent la dichotomie)
- l'ajout, l'insertion et la suppression d'élément sera immanquablement plus rapide dans une liste que dans un tableau ou dans un arbre binaire, surtout si l'abre binaire doit rester "trié" (dichotomie oblige)
- Il ne sert à rien de faire N fois une action au sein d'une boucle si l'on peut se contenter de la faire une unique fois soit avant soit après la boucle
- Il ne sert à rien de faire N fois et sans distinction une action qui pourrait n'être effectuée que de manière conditionnelle
- Et nous pourrions continuer la liste...
Éventuellement, pour ne pas devoir attendre le milieu de la troisième année de cours pour écrire ses premières lignes de code, on *peut* envisager d'utiliser l'un ou l'autre langage en "support" des cours théoriques: pourquoi pas le C pour les principes de la programmation procédurale et C++ ou java pour les principes de la programmation OO), mais, quoi qu'il en soit, si C++ doit être chois, en évitant l'écueil de faire apprendre du C with class...
- ce que j'appellerai les "principes" de la programmation procédurale, associés à l'algorithmie d'un coté, et en préliminaire à tout le reste (mais sans aborder de langage particulier)
- Les principes de conception OO, fatalement, après les principes de la programmation procédurale
- Puis, les différents langages, chacun étant vu de manière autonome, après avoir assimilé les principes qui les régissent
A méditer: La solution la plus simple est toujours la moins compliquée
Oui, la question que je me pose va dans ce sens... Et si l'apprentissage du C était nécessaire, pour empêcher que les programmeurs C++, s'appuyant exclusivement sur des librairies haut niveau dont ils ne comprennent pas les tenants et aboutissants, perdent de vue la principale force de ce langage, par rapport à d'autre langages (interprétés) de haut niveau: la capacité de produire du code très rapide?Envoyé par Bakura
Francois
Non, pas celle du C... Celle des principes propres à la programmation...
En gros, en continuant la liste, ceux que je viens de résumer très succintement
J'entends bien, mais, dans la mesure où le C et le C++ partagent des grands bouts de syntaxe, sont très souvent interopérable, et où le C est un langage assez courant, n'est il pas logique d'apprendre le C avec le C++?
Au final, ceci reviendrait à dire que l'association C et C++ dans l'enseignement, (et probablement l'ordre de cette association, C d'abord) est légitime. Mais qu'il faut faire attention à bien préciser, au début de l'enseignement du C++, en quoi le C++ n'est pas juste du C ... ++...
Personnellement, je crois que renommer le langage serait la meilleure chose que l'on pourrait faire... Parce que, sérieusement, ce nom de C++ n'aide pas...
Si demain je lance une marque de moutarde appelée Confiture++, je pense que plus d'un acheteur va me hair quand il mange ses tartines le matin...
Francois
Effectivement, C++ est surement "déservi" par son nom...
Car, bien sur, j'admets que la syntaxe est fort proche entre le C et le C++, mais, en définitive, qu'est-ce que la syntaxe
Il ne viendrait à l'idée de personne d'imposer la connaissance de COBOL avant d'apprendre C ou inversément, alors, pourquoi faudrait il mettre la connaissance (meme partielle) de C comme prérequis à l'apprentissage de... C++
En dehors de la syntaxe, C et C++ sont deux langages totalement différents (l'un étant exclusivement procédural et l'autre étant multi paradigmes) qui, "par chance" s'interfacent relativement bien...
Une fois les grands principes de la programmation procédurale et de la POO acquis, tu pourrais très bien envisager l'apprentissage de C++ en priorité (les gens aiment l'OO) et celui de C "en sus" ou "en parallèle" (mais réellement en parallèle: c'est à dire sans faire, lors de l'apprentissage d'un des langages référence à ce que l'on pourrait avoir appris dans l'autre), quitte à occasionner des redites
Mais, une chose est sure, c'est que lorsque tu souhaite apprendre à conduire, tu dois, avant de poser tes fesses derrière un volant, avoir démontré que tu connaissait les grands principes qui régissent la conduite d'un véhicule à moteur sur la voie publique et que l'on appelle "code de la route".
Pourquoi n'en est-il pas de même en ce qui concerne l'apprentissage de la programmation
Pourquoi a-t-on toujours cette impression, lorsque l'on parle de programmation, qu'il s'agit d'un "truc" basé sur le "feeling" ou tout à fait instinctif
Une grande partie du processus de programmation tient au fait d'appliquer de manière sensée (avec une certaine capacité d'adaptation) un certain nombre de principes immuables, non
Maintenant, je suis peut être le seul à envisager les choses sous cet angle...
Tu parles des développeurs qui viennent de java/C#? (je sors).
Plus sérieusement, je suis d'accord avec ton approche, ok pour utiliser la STL a fond, mais intelligemment, c'est à dire en la connaissant et donc savoir utiliser les bons outils au bons endroits.
Mais finalement tout ça revient à dire ce qu'a dit screetch, un code de débutant est un code de débutant, ça se voit plus en C parce qu'il va se taper une segfault, en C++ c'est des perfs minables. (parmis d'autre chose comme des segfault hein, je grossie le trait).
J'ai déjà (hélas) rencontré des développeurs C++ qui avaient exactement le même défaut... Tu n'as pas le temps de leur expliquer le problèmes qu'ils sont déjà en train de chercher la fonction "préfabriquée" de leur librairie favorite qui fait ca "nativement".
Après...
1- on commence par perdre trois jours à installer ladite librairie
2- on en perd ensuite trois autres à comprendre les paramètres de la fonction magique,
3- pour se rendre compte que finalement, ce n'était pas ce qu'on voulait (c'est normal, on n'a pas écouté toute la spec, on cherchait la fonction)
4- mais heureusement, on a découvert une autre librairie, qui, elle...
etc. ad nauseam...
en novlangue, on appelle cela "ne pas réinventer la roue", mais, ironiquement, ca évoque furieusement un hamster dans une roue..
Oui, c'est peut être d'ailleurs ce que reprochent les puristes du C au C++ (et aux langages de haut niveau en général).
En C, si tu programmes mal, ca ne s'exécute pas, si tu programmes bien, ca va vite, et il n'y a pas trop de place entre les deux (il y en a un peu, bien sur, je force le trait moi aussi).
Du coup, le C c'est comme le corps des marines dans les films de guerre: les mauvais l'abandonnent au bout de quelques semaines, et à la fin, y'a que des bons, qui disposent d'un outil très puissant (enfin, c'est ce que les fanboys du C aiment à penser, peut être pour se consoler du fait qu'en général ils n'ont pas trop l'air de marines, dans la vraie vie).
Le C++, ca permet la médiocrité, parce que les programmes tourneront quand même... Et comme la nature a horreur du vide, on se retrouve avec des armées de pas toujours bons, qui produisent du code horriblement lent, mais "moderne". Mais, promis, sur la prochaine génération de machines, ca ne se verra pas.
Heureusement, la crème de la crème va vers Java... (ouais, moi aussi je sors)
Francois
Pour réagir à ce que disais Bakura, je suis actuellement en 3ème année de fac... de physique. Toujours est-il qu'on apprend nous aussi la programmation.
En première année, on a les mêmes cours qu'on soit en math, en physique ou en info : "Initiation à l'informatique et l'algorithmique". C'est très semblable à ce que tu décris : d'abord de l'algo "pure" en pseudo code procédural (avec les TDs sur feuille, eh oui nous aussi...), puis on nous introduit un langage pour faire tourner le tout sur un ordinateur. Quand j'étais en L1, la mode c'était le Pascal... Bon soit. Les étudiants des années suivantes ont eu "plus de chance", la mode est passée au C.
Les années suivantes, j'ai donc dû faire du C moi aussi (à mon grand dam, puisque je n'avais jusqu'alors programmé qu'en C++, voir C with classes).
Mais pour nous les physiciens, le C++ n'est pas au programme
A mon avis, le gros soucis qu'ont les gens à appréhender le C++, c'est que la plupart ne connaissent pas la programmation objet.
On leur a déjà enseigné le C (ou autre langage procédural) avant, donc quand on va leur apprendre un nouveau langage, ils vont déjà se poser la question : "à quoi ça sert ?", puis ils vont essayer de faire coller ce qu'ils ont appris en C avec ce qu'ils viennent d'apprendre.
Et ça donne le C with classes.
Je pense (mais ça n'engage que moi) que c'est une erreur de commencer par un langage procédural trop bas niveau.
Mieux vaudrait commencer par du C++ allégé (c'est à dire sans parler de l'héritage et des templates, juste histoire de profiter de std::string, std::vector et des classes), puis introduire le reste sans trop tarder (pour éviter l'effet C with classes).
Mais alors, le passage à un langage purement procédural devient plus difficile.
Du coup l'idée serait de présenter le C++ sous ses deux aspects (paradigmes on dit ?) : objet et procédural.
Il faudrait présenter un problème, le résoudre avec les deux méthodes puis décrire les avantages/inconvénients de chacune des versions (vitesse d'exécution vs vitesse d'écriture, maintenabilité, lisibilité...).
Mais mon point de vue est sans doute biaisé par mon affection pour le C++ (je ne trouve aucun avantage au C, mis à par l'absence d'exceptions qui peut être appréciable dans certaines situations).
Ne vaudrait-il pas apprendre la programmation objet avec autre chose que le C++, d'autant plus quand on débute en programmation tout court ?
Les vtables, le early/late binding, les [rv]values, tout ça vient complexifier les concepts OOP. Commencer par java, C# ou même python me parait être un meilleur choix. Par contre, je reconnais que maitriser la prog objet en C++ permet de mieux appréhender les autres langages aux concepts OOP similaires (basés sur les classes), et ceci parce que les programmeurs C++ ont en tête certains détails qui font toute la différence.
Je ne suis pas certain de comprendre ce que tu veux dire, mais les vtables sont un détail d'implémentation qu'il n'est pas plus utile de connaitre en C++ que dans d'autres langages, le early/late binding existe aussi dans d'autres langages orientés objet, la notion de [rl]value (est-ce ce que tu as voulu dire ?) aussi.
Tu aurais parlé de l'absence de GC, du passage d'arguments par copie/référence,/rvalue reference, des autres paradigmes supportés par le C++ (encore que certains de ces paradigmes reçoivent désormais un support partiel en java/c#), de l'héritage multiple... là j'aurais effectivement dit qu'il s'agissait de différences entre le C++ et les langages genre Java/C# (différence qui gène ou pas pour l'apprentissage ? C'est une autre question).
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Objectivement, je crois que non, au contraire...
Ne serait-ce que parce que l'apprentissage "théorique" que l'on a de l'OO est, souvent, basé sur merise ou UML et que C++ ne présente, à peu près, aucune restriction quant à l'implémentation d'un diagramme de classe UML:
En java ou C#, toute classe dérive implicitement d'une classe Object (ou similaire), on n'a pas droit à l'héritage multiple et il est difficile d'implémenter une "classe paramétrée", alors que C++ autorise tout cela de manière native.
Par contre, je n'ai, à titre personnel, jamais entendu parler de demeter ou de LSP (ou d'autre principes / lois "classiques")dans mes cours OO et, si mon cas avait tendance à se généraliser (ce que je crains), je trouverais que cela représente un réel problème.
Par exemple, je ne sais pas si c'est du à java lui-même ou si c'est du à eclipse, mais, si tu ne place pas explicitement un accesseur et un mutateur nommés respectivement getXXX et setXXX sur les différents membre d'une classe, tu obtiens un joli avertissement sur l'absence des mutateurs/accesseurs.
Les développeurs (de java ou de eclipse) ont ils simplement "oublié" demeter, ont ils volontairement décidé de l'ignorer, ou n'en ont-ils carrément jamais entendu parler
Les concepts OOP seront présentés aux néophytes mais la "complexité" du C++ viendra surcharger l'apprentissage au moment de passer aux exercices pratiques. Prenons le cas des vtables: un détail d'implémentation qui compte quand il va falloir construire les objets dans une hiérarchie, ne pas appeler des methodes virtuelles dans les constructeurs, d'ailleurs pourquoi "virtuelles" ?... etc etc.
Effectivement, il faut rajouter ces points à la liste des notions à aborder! Ca conforte mon idée que si le but est de "simplement" apprendre les principes de l'OOP, alors le C++ n'est probablement pas le meilleur choix.
Cependant, si l'auditoire est motivé, réellement motivé (donc probablement pas le cas d'une classe hétérogène d'une année lambda d'un cursus alpha), et que l'on a du temps et des moyens, alors aborder l'OOP par le C++ est une chance et fera gagner beaucoup de temps quand il s'agira de passer à d'autres langages.
Je ne voit pas trop en quoi il compte ? Je ne fais jamais attention à ça quand je design une hiérarchie de classe.
Pour l'appel des fonctions virtuelles dans le constructeur je ne vois pas le rapport. Ce qui se passe n'est pas lié aux vtables, mais uniquement au fait qu'il n'y a pas construction en deux temps des objets. Le comportement est un choix de design, pas une contrainte des vtables (d'ailleurs, les autres langages ont aussi des vtables, et l'utilisateur peut là aussi totalement l'ignorer.
Parce qu'il me semble essentiel de définir dans une classe quels sont les points fixes et quels sont les points de variation. En C++ ou C#, tout est fixe par défaut, d'où virtual, en Java tout est variable par défaut, d'où final. Le C++ ne dépare pas trop dans ce cas, et présenter cette notion me semble essentiel à la POO.
Par contre, les autres langages ont aussi des particularités qui rendent leur apprentissage difficile, et éloigné de la POO "pure" (c'est quoi le boxing ? pourquoi la notion d'interface et de classe, quelle est la différence ? pourquoi tout dérive-t-il d'object ?...)
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Au fur et à mesure que les jours avance, ce topic s'étend, s'élargit et se peaufine; et j'espère que comme moi, tout le monde en profite !
La question qui n'est que, à l'origine, de savoir si le C++ doit être appris "avec" le C ou pas sous-entend bien d'autre question apparemment !
Je vais essayer une auto-interview, juste pour le fun (non, je ne me prend pas pour une star); et surtout pour m'aider à organiser un peu tous ça...
Selon vous...
Qu'est ce que la programmation ?
Je dirai que c'est l'art d'assembler sémentiquement la syntaxe, afin de respecter une conception, dans le but d'aider le compilateur à faire se qu'on veut. Car notre interprète, c'est bien lui : le compilateur...
Est-ce que le C++ est un bon langage pour commencer la POO ?
Pas nécessairement, mais pourquoi pas.
Quels sont les relations entre le C et le C++ ?
Le nom, malheureusement. Le passé, hélas. L'interfaçage pour notre bien ! Certains bas-fond du fonctionnement si on y tiens vraiment (pointeur, pile, syntaxe, quelques opérateur, etc...).
Faudrait-il apprendre le C++ d'après le C ?
Oui, j'en distinguerai trois étapes ou quatre: C, C orienté objet, C With Classes (qui ne sera, si possible, pas présentez comme du C++) et enfin C++.
Qu'est-ce qui justifie cette approche ?
L'héritage commun et la trop grande ressemblance aux yeux novices. Dans un future idéal, les cases intermédiaire pourrait-être enlevé. Mais si on ne fait pas l'effort d'y passer pédagogiquement pour l'instant, j'ai bien peur que l'étudiant fasse seul cette amalgame.
Toutefois, j'insiste sur le fait d'arriver à un point ou les seuls liens du C et du C++ sont l'interfaçage et quelques points cités plus haut.
Et pourquoi ne pas imaginer notre étudiant qui aurait eu des cours de python, pascal ou whatever avant, mais pas de C?
Pourquoi ne pas prendre l'approche : on commence par le C++, toute les features qui sont cool et qui le rende agréable (mais qui peuvent être piégeur, sinon jvais me faire taper sur les doigts par fcharton :p), puis quand l'étudiant a des bases assez solide lui montrez que oui il existe des détails plus bas niveau, et faire un lien avec le C?
En gros reprendre l'approche proposez par AC++ (on voit le memory management qu'a partir du 10 éme chapitre il me semble) ou encore du tout dernier BS qui suit la même approche, encore plus poussé.
A vrai dire, j'aurais eu des réponses un peu différentes:
Qu'est ce que la programmation ?
L'art de faire comprendre à l'ordinateur ce que l'on attend de lui, en lui fournissant une logique aussi exempte de défaut que possible
Est-ce que le C++ est un bon langage pour commencer la POO ?
Oui, car c'est un des rares langages OO (ou permettant le paradigme OO) qui ne place aucune restriction par rapport à ce que l'on peut rencontrer en phase de conception
Quels sont les relations entre le C et le C++ ?
Ta réponse me convient
Faudrait-il apprendre le C++ d'après le C ?
Cela n'a pas d'importance, mais, de manière générale, l'apprentissage du C et du C++ devraient être clairement distincts, et il ne faudrait jamais faire référence aux connaissances du C qu'on les récipiendaires.
Le principal étant de disposer des concepts qui régissent chacun des langages:
Avant d'apprendre le C, il me semble indispensable de disposer des concepts communs à l'ensemble des langages procéduraux. Il est possible d'apprendre une partie du C++ avec ces seules bases.
Par contre, pour tirer pleinement parti du C++, il est bon de rajouter les concepts communs à la POO, et, idéalement, ceux de la programmation générique.
Qu'est-ce qui justifie cette approche ?
Malgré le tronc commun indéniable qui existe entre le C et le C++, il s'agit de deux langages clairement différents.
Si nous basons trop l'apprentissage du C++ sur ce tronc commun, nous retardons beaucoup trop le moment où les récipiendaires apprendront les possibilités propres au C++ qui sont, justement, de nature à faciliter leur vie de programmeur en leur évitant les écueils inhérents au C.
Or, une fois les "mauvaises" habitudes prises, il sera particulièrement difficile de les perdre au profit de celles qui consistent à utiliser les possibilités propre au C++ et qui sont, rappelons le, de nature à simplifier énormément la vie du programmeur.
Fais gaffe à tes doigts, Goten...
Personnellement, je pense que ce serait comme ca que j'enseignerais le C++ si j'avais à le faire. D'abord montrer comment il permet d'écrire, sans trop d'effort, des programmes utiles. Essayer de se limiter à quelques choses simples (les stream, les vector) en résistant à la tentation de la liste de toutes les fonctions de la librairie standard...
Mais aller assez vite dans les coins... parce que, l'air de rien, AC++ aborde des aspects assez pointus (notamment les uninitialized fill et les choses comme ca), et les auteurs insistent régulièrement sur l'efficacité du code.
Ceci dit, j'ai quand même trouvé que AC++ n'était pas un livre de débutant. Même s'il présente les choses de façon simple, il demande une certaine culture informatique, et, si possible, une expérience de la programmation.
Face à de vrais débutants, disons au lycée, je ne sais pas si cela marcherait si bien... En école d'ingénieurs, en revanche...
Francois
Ouai mais là la question est : est ce que le C++ est un langage adapté pour commencer la programmation? (en partant du principe qu'au lycée on a rien vu d'autres, excepté ceux qui ont cherché par eux même mais ça compte pas).
Ce à quoi plus ça va plus j'ai tendance à répondre que non. Récemment j'ai pensé que les langages fonctionnels pouvaient être une réponse à par quoi commencer la programmation, on m'a rétorqué que c'était mon côté matheux qui ressortait et que la pensée humaine était procédurale, ce qui n'est pas faux. (Luc si tu nous lis :p)
Donc pourquoi pas python? il me semble être un candidat idéal pour commencer, pascal aussi mais ça date, et je connais pas forcément bien donc j'ai pas d'avis.
Sinon oui AC++ est assez poussé, et surtout condensé, c'est ce qui fait sa "difficulté", note qu'on voit aussi les templates (classe et fonction générique), même si ils rentrent pas dans les détails.
Je ne pense personnellement pas que C++ soit moins adapté qu'un autre langage pour l'apprentissage...
Par contre, quel que soit le langage envisagé pour l'apprentissage, je persiste dans le sens où il y a des prérequis "théoriques" à avoir:
Pour mener à l'apprentissage d'un langage procédural, commençons par expliquer ce que sont les variables, les constantes, le boucles (les trois types différents et leurs particularités), les tests (vrai / faux et à choix multiple), les fonctions et les types définis par l'utilisateur et comment s'en servir
Arrangeons nous ensuite pour que l'étudiant prenne conscience de la différence qui existe entre les différents types qu'il peut rencontrer
Continuons enfin sur les structures que je qualifierai de dynamiques (tableaux, piles, files, listes, ...) en mettant en évidence leurs qualités et leur défauts et les algorithmes à mettre en oeuvre pour les gérer correctement.
Un étudiant qui connait déjà cela aura finalement très facile à apprendre n'importe quel langage procédural... il n'y aura au pire que quelques "particularités"
Si la finalité est de les amener à apprendre un langage OO, insistons sur le fait qu'il faut penser en terme de comportements / de services rendus, les concepts d'encapsulation, de composition / agrégation, d'héritage et de polymorphisme, en n'oubliant pas de mettre en évidence les principes généraux (LSP et demeter en tête, mais pas seulement).
Une fois que cette théorie est correctement assimilée, l'apprentissage de base d'un langage OO se résume en définitive à peu de chose:
On n'est même pas obligé de s'attarder sur les 130 fonctions membres des différentes classes que l'on présente: il existe suffisamment de documentation disponible pour ceux qui voudront aller "plus loin", mais il y a, effectivement, quelques fonctions "incontournables" pour chacune des classes
- La syntaxe à utiliser
- Quelques mots clé
- Quelques classes "utilitaires" fournies par le langage lui-même (chaines de caractères, classes d'entrées/sorties et collections en tete de liste)
- Quelques particularités propres au langage
- ...
En suivant un schéma similaire, il est tout à fait possible de donner de saines bases concernant n'importe quel langage en quelques mois à peine (à coup de deux ou trois heures de cours par semaine).
Il est en effet à mon avis tout à fait impensable d'envisager que tout étudiant en informatique terminant son cycle maitrise l'ensemble des langages qui lui seront présentés, ne serait-ce parce qu'il y a un phénomène d'affinités qui intervient (à titre personnel, meme si je connais COBOL, java et C#(entre autres), je ne nie absolument pas avoir plus d'affinités avec C++
Mais, en suivant ce schéma, l'étudiant en saura assez pour trouver le langage avec lequel il a le plus d'affinité, et pourra décider (ou non) d'approfondir ses connaissances sur le sujet
Répondre avec citation
Partager