Le ZdS est-il déjà mort ?

C’est pas tout récent, ça avait occasionné des frictions, mais ça avait été fait, non ?

Certes, mais ça vaudrait le coup de dépoussiérer le sujet pour voir ce qu’il en est aujourd’hui, trois ans plus tard. Ce qui a bougé, ce qui s’est amélioré, ce qui a empiré…

Accessoirement, si le thread a fini en engueulade, il n’est pas étonnant que les gens l’aient laissé croupir au fond du forum. (Edit: au temps pour moi je croyais que c’était un autre sujet).

Déjà, y’a une synthèse. Voir ce qui a évolué ou non, ça serait une bonne idée.

Il y a quand même très peu de points qui n’ont pas été mis en place. Je pense pas qu’on puisse par exemple continuer à dire que la validation est lente ou bien que les articles sont trop techniques

ah je vois, enfin quand même c’est triste qu’on ne trouve pas de tutoriel sur le HTML ou le PHP, ça fait un peu "bancal"…

Puisque ce sujet, c’est un peu du troll, j’en profite pour placer une remarque qui me semble pertinente ici alors qu’elle est plus difficile à placer ailleurs.

Personellement je pense que PHP est une technologie obsolète, et qu’il vaut mieux encourager les nouveaux arrivants sur la scène du web à utiliser n’importe quoi d’autre avec une communauté de taille raisonnable (Python/Django, Ruby/RoR, NodeJS, Elixir, etc.).

Ça a toujours été un mauvais langage mais avant il était incontournable du côté de l’hébergement et des bibliothèques logicielles pour le web, ce monopole s’est écroulé et on peut le fêter en oubliant le sens du terme "variable variable".

Hé, puisqu’on en est à remettre en question les canons du passé, il me vient également une réflexion qui m’a plusieurs fois traversé l’esprit.

La plupart des tutos du SdZ s’intitulaient "Apprenez à programmer en [langage]". Jusqu’à présent on s’est dit que ce serait bien de "factoriser" la partie "apprendre à programmer" pour ne plus avoir à écrire que "apprendre les spécificités de [langage]".

À la réflexion, je pense que ce n’est pas vraiment une approche séduisante pour les débutants que de les renvoyer vers un tuto qui ne saurait être que théorique, comme prérequis d’un second tuto qui va leur apprendre la pratique.¹

Je remarque également que beaucoup de technos modernes viennent avec des "batteries inclues". Je pense notamment (pour celles que je connais) à Python (pip, black, la bibliothèque standard, setuptools, virtualenv…), à Golang (et sa commande go qui fait le café, go init, go get, go test, go bench, go fmt…), et même à Rust (avec cargo : cargo install, cargo init, cargo fmt, cargo build…). Je pense que personne ne me contredirait si je disais que ces outils devraient faire partie de l’apprentissage de base du langage : pour qu’un cours serve à quelque chose, il faut non seulement connaître le langage mais aussi ses outils associés.

J’aimerais pousser ce raisonnement encore plus loin : qu’en serait-il d’un cours pour apprendre à développer avec une techno donnée plutôt qu’à simplement "programmer" avec ce langage. C’est-à-dire qu’au bout d’un moment (raisonnable, hein) dans le plan, le tuto commencerait à parler de choses qui font partie de la réalité du développement, mais qu’on n’apprend dans aucun cours.

On y parlerait donc non seulement de bonnes pratiques (ce que font presque tous les tutos), mais on en profiterait aussi pour armer le lecteur en lui montrant :

• comment on écrit des tests,
• comment on commite,
• comment on pousse son code sur un repo GitHub,
• comment on devrait documenter son code et générer sa doc,
• comment on devrait packager son projet pour que les gens puissent l’installer,

Typiquement, ça ressemble pas mal à l’approche du Rust book depuis qu’il a été complètement refait. J’ai trouvé ça hyper raffraîchissant à la lecture.

Alors clairement, c’est un surcroît de boulot (en fait ça demande de penser son tuto différemment), mais pour moi, un tuto qui prendrait le lecteur par la main et qui lui ferait faire un tour d’horizon de la réalité du développement dans telle ou telle techno (plus que seulement le langage), aurait une valeur ajoutée inestimable par rapport à la "concurrence".

Amen.

@nohar : ça ressemble quand même à ce que j’avais envie de faire pour mon cours de PHP, du moins c’est ce que j’ai fait avec mes étudiants. Le plus dur, c’est de mettre ça sous forme de texte digeste, accessible, agréable et motivant.

Vu la plus-value que représenteraient ce genre de chapitres, peut-être que c’est par eux qu’il faudrait commencer à travailler, pour combler ce manque avant d’attaquer le reste (toute la partie programmation pure).

Ouaip.

Autant la partie programmation, on sait faire. Autant écrire un mini-tuto ou moyen-tuto surcomment développer dans la pratique, en attendant d’avoir le reste (qui existe ailleurs) et de le fusionner avec, ça semble une bonne idée.

J’aime ton idée @nohar. Mais autant si pour les tests, la documentation, le packaging etc je suis d’accord, autant pousser sur GitHub et commit, ça c’est assez indépendant, et ça aurait plus sa place dans un tutoriel à part. À moins que tu ne pense à quelque chose qui m’échappe.

Autre point : pense-tu que le tutoriel d’introduction à la programmation est inutile ? C’est sûr qu’il est un peu théorique, mais il se lit en une vingtaine de minutes et ensuite le lecteur pratique avec le tutoriel derrière. Bon après je suis partie prenante, donc forcément je suis un peu attaché.

Ça me semble une bonne idée mais par ailleurs il me semble que c’est plutôt la norme. Beaucoup de documents sur les langages de programmation ou de cours sur la programmation contiennent des présentations du workflow, des tests, des outils, des pratiques et conventions de la communauté, de la gestion de version, etc. Ça me semble naturel. Un exemple que j’ai vu passer récemment est le cours de Noel Dubray pour la programmation scientifique, qui est un contenu libre (licence MIT), réutilisable et modifiable, qui parle d’outils de programmation (scientifique) et aussi de bonnes pratiques.

Du coup j’en profite, @nohar ou les autres, pour qu’on fasse un test réel grandeur nature. Comme vous le savez, le cours C++ est toujours en rédaction et il laisse une marge large pour intégrer tout ce dont vous parlez.

Si donc vous pensez à des aspects, des choses, des éléments que vous souhaiteriez voir dans un cours C++, n’hésitez pas à m’en faire part sur la bêta. Par exemple, les tests unitaires basiques sont déjà au programme, mais peut-être que vous avez d’autres idées.

À moins que tu ne pense à quelque chose qui m’échappe.

Eh bien, pour être honnête, je ne code quasiment jamais sans versionner ce que je fais avec git. Du moment qu’on commence à faire des petits projets, soit un peu complexes (qu’on veut faire évoluer), soit à plusieurs, utiliser un SCM devient indispensable. Même si c’est indépendant, ça devrait s’apprendre en même temps. Et donc au même endroit.

Autre point : pense-tu que le tutoriel d’introduction à la programmation est inutile ?

Je n’ai pas dit ça. En fait cette approche sera bonne pour certains, mais j’ai des réserves sur son utilité pour les plus grands débutants.

Ça me semble une bonne idée mais par ailleurs il me semble que c’est plutôt la norme.

Dans les tutoriels pour débutants complets (qui partent "de zéro") ? Si c’est le cas je ne dois sûrement pas être à la page, mais j’ai l’impression que ça ne l’est pas pour tous les publics : typiquement le Rust Book que je mentionne plus haut s’adresse à des gens qui savent déjà programmer, et qui connaissent ces problematiques suffisamment bien pour apprécier tout ce que fait cargo pour eux.

En même temps je comprends, mais au même endroit, est-ce qu’on ne risque pas une redite des mêmes informations, réparties sur plusieurs cours, avec les risques inhérants (information pas présentée pareil, erreur pas corrigée partout en même temps, etc) ?

Même avec drone ou gitlab, c’est possible d’exécuter la CI en local et donc faire un tutoriel qui intégrerait les tests, plusieurs façons de commiter et la CI serait top. Je le vois pas trop en approche complète dans un de programmation, mais plutôt une approche guidée «on a finit ça, on va le commiter avec cette commande». D’autant que ça complexifie beaucoup si on veut faire windows/mac/linux.

En même temps je comprends, mais au même endroit, est-ce qu’on ne risque pas une redite des mêmes informations, réparties sur plusieurs cours,

Je pense que l’on peut se le permettre si le tuto de développement se contente de le faire superficiellement, quitte à pointer vers un autre tuto dédié pour rentrer dans les détails.

Je suis pas vraiment convaincu, je pense que c’est le rôle d’autres tutos genre une série "par la pratique" ou "par l’exemple" montrant toute la stack de développement, mais pas dans les tutos de base, ceux-là (dont le big tuto C++ d’informaticienzero) je les vois dans une philosophie KISS, il peut y avoir des mentions sur les pistes à suivre avec éventuellement des liens, mais je vois pas une section sur ça.
D’autant plus que si tu fais une partie sur git, ça ne reste qu’un exemple de VCS, pourquoi ce n’est pas pijul ou mercurial ?
Pour moi ça revient au même que de faire une section IDE décrivant l’utilisation de Visual Studio, c’est bien, un débutant va avoir besoin d’installer son environnement avant de faire quoi que ce soit, mais c’est pas le sujet d’un tuto C++, et il y a plein d’alternatives qui ne sont pas plus farfelues

Et je ne pense pas que The Rust Book soit un bon parallèle, c’est une documentation pas un cours ou un tuto, la priorité est sur la précision plus que sur la pédagogie (même si je suis d’accord pour dire qu’il est très bien fait)
Là où je suis dubitatif sur ma cohérence, c’est que je me fais la même réflexion dans le sens inverse, le cours est fait pour être pédagogique, c’est pas une doc, donc faire un cours sur le C++ n’est pas nécessairement précis (il y a la doc pour ça), donc ça fait sens de digresser un peu sur les outils …

Pour Rust, le truc c’est qu’ils peuvent faire ça : cargo crée un dépôt git et s’utilise en ligne de commande de base.

Pour moi ca a du sens qu’un tuto pour débutants soit "opinionated", c’est-à-dire qu’il fasse des choix à la place du lecteur pour le bien de son apprentissage, en lui laissant évidemment la possibilité de "désobéir" si le lecteur a déjà des connaissances et des outils qu’il maîtrise.

Maintenant, "pourquoi git" ? Ben quand on parle de Rust et de Go, sachant que les deux tools savent gérer automatiquememt les dépendances sur github, je ne vois pas quel autre choix serait plus intelligent : c’est le choix standard, et celui que le lecteur a le plus de chances d’utiliser par la suite.

N’oublions pas non plus le reste. Par exemple :

• Je n’ai jamais lu un seul tuto de programmation pour débutants qui parle de tests (mais je n’en ai pas non plus lu des centaines), et là j’anticipe même un peu : typiquement pour Python, il serait bon de parler de pytest (qui est un module externe) plutot que le module standard unittest qui est désuet et finalement peu utilisé. Si je parle de ça, c’est aussi parce que pes tests aident à se faire une idée sur la façon dont le code devrait être conçu derrière : c’est autant un outil de design et de developpement que de qualité.
• Je pense que le débutant devrait être guidé sur la façon idiomatique d’organiser ses projets (pour Rust, cargo le fait tout seul, mais pas pour Python par exemple), c’est-à-dire la façon la plus communément adoptée.
• Je n’ai jamais vu de tuto de programmation qui enseigne comment un projet doit être documenté, en dehors de deux-trois remarques sur la syntaxe des commentaires. Ces considérations dependent aussi de la techno utilisée. Pourtant c’est important.

Après, je ne suis vraiment pas d’accord pour qualifier le Rust Book de "documentation" : pour moi c’est clairement un ouvrage didactique qui amène les notions au fur et à mesure, quitte à revisiter certains chapitres du début par la suite, et dont le but est d’expliquer comment le langage a été pensé pour que le lecteur en tire une bonne intuition.

La première édition ressemblait beaucoup à une doc, par contre.

PS : On est bien d’accord que c’est plus facile, quand on est auteur, de bien tout ranger dans des petites cases, et de se focaliser sur un seul sujet. Mais du coup, si on considère qu’un débutant n’est plus un débutant du moment qu’il est capable de réaliser un petit projet, et donc qu’il faut qu’il apprenne tout dans des tutos séparés, tu crois vraiment que lui en envoyer une demi-douzaine dans la tronche (pour la programmation de base, le langage, le VCS, l’art d’écrire des tests, réussir sa conception, son IDE, et j’en passe) ne va pas bêtement le décourager ? Et en supposant qu’il n’ait pas déjà abandonné et qu’il suit ces tutos en parallèle, quel moyen a-t’il de prioriser ses lectures ? Faut-il qu’il sache en premier utiliser git rebase -i, écrire des fixtures, ou bien comprendre le polymorphisme ? Comment pourrait-il le savoir ?

Du côté des sceptiques, on peut quand même remarquer que beaucoup de méthodes de travail en programmation font plus de sens quand on a déjà été confronté, dans sa pratique, aux problèmes qu’elles attaquent. Quand on commence tout juste, on ne ressent pas le besoin d’un outil de gestion de version, on travaille dans un fichier, éventuellement on fait des copies (code_1, code_2 etc.) quand on veut des sauvegardes. Pareil pour le build system, on peut appeler le compilateur/l’interpréteur à la main au début, etc. Les tests unitaires, on comprend vraiment l’intérêt quand on voit sa première régression dans un projet, au début on fait juste des tests sur le moment et on les efface.

Du coup, montrer tout ça à quelqu’un qui vient tout juste de programmer, il y a un risque de le dérouter avec ce protocole et cette complexité dont il ne voit pas l’intérêt. J’aurais plutôt tendance à apprendre aux gens le minimum pour être productifs pour faire de petites expériences, coder un vrai petit projet de leur côté, et ensuite dans un second temps introduire plus d’outils et de méthodes. Tout cela peut se faire au sein d’un même cours (avec un chapitre "vrai projet" au milieu, guidé ou non), mais c’est aussi naturel de séparer en plusieurs cours.

(Pour l’algorithmique aussi je suis personnellement de l’avis que ça vient plus naturellement après une pratique basique de la programmation, et que ça peut se faire en donnant des exemples dans plusieurs langages de programmation différents, en évitant le pseucode qui ne s’exécute pas.)