L'apprentissage de la programmation et plus encore

Merci. Pour les fautes, je sais, ça toujours été mon cauchemar (du coup, je passe systématiquement mes articles au correcteur… mais comme le cours n'est pas fini, je ne l'ai pas encore fait. Et avec un QWERTY, cela n'aide pas)

Quel chapitre tu parles ? Pour le moment, je n'ai pas encore rédiger les exos, juste mis quelques idées.

Le but du cours n'est pas d'apprendre le C++. C'est d'apprendre à créer des applications en C++. La conception est une partie importante dans la création d'applications pro. Quand on se focalise sur l'apprentissage d'une syntaxe seule, il est impossible de comprendre réellement ce que cela implique quand on parle de "maintenabilité", "robustesse", "évolutivité".

Ce sont des choses qui ne peuvent être apprise que par la pratique. Et sur des projets conséquents (pour éviter le "j'efface tout et je recommence à zéro"). Je pense qu'il y a moyen de donner de vrais challenges sur lesquels bosser

Tu es dur, dès le "hello world", je montre la doc

Mais je suis d'accord avec toi. Je crois que j'en ai parlé dans la discussion de présentation sur SdZ, mais très clairement, pour moi, cela ne présente pas d'intérêt de présenter les algos de la STL un par un, alors que la documentation est très bien faite. Cela me semble plus pertinent de donner des travaux dirigés, qui nécessiterait de rechercher dans la doc l'algo a utiliser pour résoudre un problème donné. (et pour les utilisations avancées, cela sort d'un cours débutant. Et le Josuttis est très bien fait).

L'autre chose qu'il manque dans les cours, c'est étudier les messages d'erreur. Le compilateur est généralement vu comme celui qui fait planter les programmes, alors que c'est la première aide que l'on a pour résoudre les problèmes. Du coup, cela me semble intéressant de montrer quelques erreurs et les messages que cela produit.

(HS : c'est amusant que tu parles du C++ comme langage haut niveau, beaucoup le mette en bas niveau - a tort a mon sens)

Je connais pas trop python (il faut que je m'y mette) et encore moins ruby. Je préfère python, tout simplement parce qu'il est plus utilisé (il est assez courant d'écrire des scripts py pour les builds en C++)

Je trouve que l'assembleur à très très peu d'intérêt dans ton cas (trop domaine spécifique. Et je ne suis pas sûr que ce soit vitale de l'apprendre pour comprendre ton ordi). Par contre, je rajouterais un langage fonctionnel dans ta liste (haskell ?)

Pour moi, on ne peut pas vraiment juger un langage sur sa syntaxe^*. C'est clair que si tu utilises quotidiennement une syntaxe qui tu déplais, ce peut-être gênant. Moi non plus, je ne suis pas un grand fan de la syntaxe de Python. Mais au final, on fini par s'y habituer. Donc selon moi, la syntaxe ne devrait occuper qu'un très petit rôle dans le choix d'un langage.

^* Cela dépend également de la définition que vous donnez à la syntaxe d'un langage.

Comme dit plus haut, ce n'est pas obligatoire mais c'est un plus. Ce cours a l'air plutôt sympa. Il traite de l'apprentissage de l'algorithmie, avec des implémentations en Python. Si tu sélectionnes seulement les parties que tu comprends et qui t'intéressent, il pourrait t'être utile.

@Taurre J'ai bien conscience que ce ne sont que des conseils, mais je pense que ce sont des conseils avisés (qui plus est de professionnels du domaine pour la majorité j'imagine), dans mon intérêt et dans le but de me faire progresser, donc autant (au moins essayer) de faire les choses "correctement".
D'ailleurs il est vrai que j'ai déjà fait du PHP et que ça ne m'a jamais vraiment gêner même si je ne pense pas que ce soit totalement comparable.

Au passage, je serais curieux de connaître tes arguments/les avantages que tu trouves au C, mais comme ce n'est pas vraiment le sujet ici, on peut peut-être poursuivre en messages privés si ça ne te dérange pas évidemment.

@gbdivers Concernant les exercices il y en avait sur le compilateur (dans "Programme C++ minimal"), dans "Les chaînes de caractères" et celui sur lequel j'ai lamentablement bloqué à la fin de "Les nombres entiers".

Le but du cours n'est pas d'apprendre le C++. C'est d'apprendre à créer des applications en C++. La conception est une partie importante dans la création d'applications pro. Quand on se focalise sur l'apprentissage d'une syntaxe seule, il est impossible de comprendre réellement ce que cela implique quand on parle de "maintenabilité", "robustesse", "évolutivité".

Personnellement je suis "fan" de cette approche, j'ai presque envie de dire "Lance-toi dans l'enseignement !".

Effectivement, mais ce que je reproche ce n'est pas de ne pas avoir montré la documentation, c'est de ne pas nous guider, nous apprendre comment l'utiliser, c'est différent.
Autrement dit, expliquer comment elle est hiérarchisée, à quel endroit trouver telle chose.

Par exemple, dans ton cours tu dis "Si vous avez regardé un peu la documentation de std::cout, vous avez peut-être remarqué qu'il existe d'autres flux de sortie:[…]"
Or, suivant ma compréhension (qui est peut-être mauvaise) de la documentation, c'est dans la documentation de std::basic_ostream que je trouve les différents flux de sortie dans les "Global objects".

Ce qui me permet d'ailleurs de rebondir dans mon explication, dans ce cas ce sont des "Global objects" pourquoi, qu'est-ce que ça veut dire, en-dessous je vois "Member functions", "Member classes" et "Non-members function" à quoi ça correspond tout ça ? Pourquoi c'est là ?
Idem dans "l'onglet" Input/output library il y a un tant de termes étranges, qui ne sont d'ailleurs pas les mêmes selon "l'onglet sélectionné" d'après mes constatations pourquoi ?

Voilà, j'espère avoir été un peu plus clair sur le reproche, qui était d'ailleurs plus une remarque générale, que j'ai formulé.

En deux mots: "Totalement approuvé."

Autant je considère le C comme un langage bas niveau, autant il ne m'est pas venu à l'esprit de considérer le C++ comme tel, même si je ne saurais pas vraiment expliquer pourquoi dans l'immédiat. Pour l'assembleur, même si je me décide, ça ne sera de toute façon pas avant très longtemps, je verrai le moment venu s'il me semble utile ou non.

Pour ce qui est des langages fonctionnels dont j'ai déjà entendu parler, j'avoue ne pas avoir vraiment saisi leur utilité, c'est une notion très flou pour moi.

@Emeric Je ne juge pas un langage à sa syntaxe (Python en l'occurrence ici) j'exposais juste que je préférais la syntaxe de Ruby pour quelques choses qui peuvent paraître infimes, bêtes ou dérisoires.
Par exemple, en Ruby, quand on fait une boucle, que l'on parcourt un tableau, un "hash", on a le petit mot clé "end" qui délimite bien la fin, idem quand on crée une condition, une fonction, une classe, bref quelque chose qu'il faut délimiter clairement.
Aussi, j'aime beaucoup les "blocs" en Ruby, qui ressemblent à ça:

1
2
3
4

montableau = ['Zeste', 'de', 'Savoir']
montableau.each do |x|
  une instruction à appliquer sur chaque élément du tableau
end

Ou encore de manière plus anecdotique, le constructeur des classes en Ruby "def initialize" que je préfère à celui de Python "def init(self):" (il me semble, corrigez-moi si ce n'est pas ça ou qu'il y a une écriture alternative) que je trouve un peu "barbare" etc

Bref, quelques petites particularités qui font partie de la syntaxe, pas forcément très importantes de Ruby que j'aime bien (et je suis loin de tout avoir découvert !), que je trouve plus simple à retenir, intuitive et assez élégante dans l'ensemble, mais c'est vraiment une affaire de goût.
Pour finir, je pourrais sans doute m’accommoder de Python car après un nouveau coup d’œil il y a quand même un certain nombre de similitudes et assez peu d'éléments qui "ne me conviennent pas", en plus je pense que Python a une bibliothèque standard beaucoup plus fournie, ainsi qu'une plus grande communauté (toujours utile quand on rencontre un problème).

C'est tout de même un coup de théâtre, j'étais partie pour Ruby et ton commentaire me fait à nouveau hésiter, toutefois je pense tout de même suivre mon idée première (donc Ruby), et je changerai si vraiment je rencontre des problèmes majeurs (pas assez de ressources, pas assez de bibliothèques à jour, problème technique important et communauté absente etc)

Pour ce qui est du cours d'algorithmique, je l'ai survolé, et il a l'air effectivement très intéressant, complet, et surtout "axé débutant", je l'ai donc mis de côté pour le regarder plus attentivement par la suite.

Tu n'es pas le seul. Cf cette discussion pour des détails en plus : http://openclassrooms.com/forum/sujet/exercices-dans-le-cours-de-gbdivers.

Trop mal payé

Tres bonne remarque. Je mets les termes anglais entre parenthèses lorsque j'utilise des termes français (mais pas question que j'utilise "patron" ou "modèle" a la place de "template"…), parce qu'il me semble important que les personnes les connaissent (au moins pour faire des recherches). Mais il faudrait effectivement une petite intro pour la doc.

(En plus, template vient du vieux françois templet – quitte à traduire, déterrons nos vieux mots qui ont un rapport, à contrario de l'ignoble bogue qui confond châtaignes et bestiole insectoïde)

D'ailleurs, je propose que l'on utilise "insecte logiciel", plutot que "bug" ou "bogue"

Sinon, il y a : erreur, anomalie, problème, dysfonctionnement, coquille (qui, finalement, eu été mieux que « bogue » quitte à parler d'enveloppes), défaut, vice , tare, etc. Bref, ce ne sont pas les mots qui manquent. En revanche, pour debugger ou debugging, c'est plus pénible…

Déverminage !

Je l'avais vu, mais je suis pas franchement convaincu (comme pour déparasitage).

Comme plus personne ne semble avoir d'avis et que j'ai tout de même obtenu un certain nombre de réponses, je passe le sujet en "résolu".

J'en profite pour remercier une fois encore toutes les personnes qui ont participé.