Soyons cash: Je forcerai mes étudiants à coder à la main

Je veux juste partager un peu de mon agacement et ma théorie sur l'avenir du développement logiciel.

Je suis formateur de développement de logiciel dans une école d'informatique et j'ai pu remarquer qu'avec les progrès fulgurants des derniers modèles d'IA, on vois de plus en plus de personnes et d'élève se demander s'il est encore nécessaire d'apprendre à coder. En effet, l'IA permet de le faire bien plus vite donc le code manuel est "dépassé".

Cependant, coder à la main ne se résume pas seulement à créer des logiciels.

L'expression forge la pensée

On dit souvent que l'écriture forge la pensée et le code étant une forme d'écriture bénéficie de cette propriété. Cependant, je pousserai la réflexion plus loin en étendant ce concept à toute forme d'expression. En tant que francophone, apprendre une nouvelle langue comme l'anglais a aussi façonné ma façon de réfléchir et de formuler ma pensée. Parler, Écrire des dissertations ou des histoires, ou bien même des actes artistique comme dessiner ou faire de la musique sont toutes des manière de se forger car elles sont toutes expression.

Du moment qu'une idée reste dans la tête, elle demeure stérile. C'est quand on l'écrit sur papier ou qu'on la verbalise qu'on la force à prendre une forme et qu'on la transforme en objet d'étude améliorable. C'est quand j'écrit une idée ou que je dessine des diagrammes que je réalise les angles-morts de ma réflexion ou que je vois des incohérences. Le médium par lequel je concrétise mes pensées devient un miroir et me permet d'avoir un point de vu inédit.

Les sciences cognitives ont même un nom pour ça: la pensée distribuée. Ici, le cerveau n'est qu'une partie d'un système complexe où la pensée se développe. Si, par exemple, j'ai besoin de savoir combien de table je dois avoir pour installer une salle de 175 personnes à raison de 5 personnes par table, je pourrai sortir une feuille et un crayon pour faire mes calculs. Un amis à côté peut remarquer que j'ai oublié une retenu dans ma procédure et corriger la faute. Dans ce cas de figure, au moins 3 médiums ont étés utilisés pour ce processus de raffinement de la pensée: moi, le groupe papier-crayon ainsi que mon ami. La pensée a pris forme et a donnée un résultat concret (la réponse est 35 table si jamais).

La pensée distribuer dit que la réflexion et la construction d'une solution dépend de l'esprit de l'individu pensant, les outils qu'il utilise (crayon, calculatrice, internet, ou bien même un LLM), d'autres individus (par exemple le brainstorming), et le contexte. Toute activité artistique ou de résolution de problème marche dans ce principe.

Le danger de l'export de la pensée

Maintenant, la pensée distribuée nous permet, selon moi, d'identifier l'ennemi numéro un de la pensée à l'époque des LLMs: l'export de la réflexion. Ça arrive quand l'acteur principale délègue toute forme de réflexion aux autres médiums du système en donnant seulement l'entrant et en récupérant le sortant. On parle aujourd'hui de la dangerosité des IAs qui peuvent nous pondre des réponses toutes faites à nos questions, mais ce problème existait déjà depuis longtemps. On a déjà eu des cas d'étudiants refusant de comprendre les méchanismes de l'arithmétique sous réserve que cela se fait déjà avec des calculatrices. On a aussi des étudiants qui utilisaient déjà google, wikipédia et d'autres sites pour littéralement copier-coller des informations sans beaucoup plus de réflexion et de construction de leur part. Il arrivait même que des dissertations entières pouvaient être copié d'internet sans réflexion de la part de l'étudiant. Le plagiat n'est pas un context nouveau.

Le domaine du développement logiciel a aussi eu ses soucis. Par le passé, il y avait un groupe particulier de développeur qui, dans les forums (et surtout dans stack overflow) passaient le plus claire de leur temps à poser des questions à tout va, souvent mal formulées et sans context et attendais à être interroger par les membres de la communauté pour diagnostiquer le problème à leur place et recevoir une réponse toute faite. Je peux vous dire avec assurance que ce type de profil n'était pas qui ressortait avec de nouvelles connaissances. Surtout si leur plus grande prouesse était de copier-coller une réponse en ligne sans tout lire. C'est ce qui a empoisonné la chaleur des réponses des communautés comme stack overflow.

Donc l'IA, n'a pas inventé l'export de la réflexion. Elle l'a juste rendu plus accessible, touchant une plus grande partie de la population des développeur car la tentation est plus grande. Elle peut se substituer sournoisement au endroits où la charge cognitive peut-être un peu trop élevée pour un étudiant. Et c'est, là le rôle de l'enseignant(e) de pouvoir mettre en place un cours qui travail la zone proximal de développement (=ni trop dur, ni trop facile mais challengeant et fait grandir) de l'étudiant pour favoriser son apprentissage.

C'est pourquoi le fameux "rubber duck" (canard en plastique) marche toujours etest souvent plus efficace que le LLM en terme d'instrument pédagogique. En effet, le canard n'est pas un technicien et force la personne qui développe à simplifier et à mieux formaliser son raisonnement. Ce qui conduit assez souvent à une solution par compréhension plutôt que ex nihilo.

Une étude mennée par les chercheurs du MIT et de l'Université de Pennsylvanie a prouvé que les étudiants qui ont utilisé l'IA pour les exercices d'entraînement ont été moins performant durant l'examen final que les étudiants qui n'ont pas utilisé l'IA. Ce phénomène n'est pas là pour dire que les LLMs sont de mauvais outils pédagogiques mais qu'ils peuvent devenir problèmatique selon la manière dont on les utilise.

Conclusion

Bien sûr, les LLMs peuvent être l'outil le plus puissant d'apprentissage s'ils sont bien paramètrés. On peut par exemple obtenir un effet Rubber Duck en prenant des modèles moins puissant et en raisonnant avec eux. On peut aussi interdir au modèle de construire des solutions sur mesure mais de seulement donner des réponses similaire à celles d'une recherche google (Bien sûr sans Gemini). L'élément le plus important selon moi est le challenge. Il faut explicitement forcer l'IA à chercher les failles et les angles-morts de notre raisonnement, challenger certaines certitudes qui n'ont pas de preuve réelle et vraiment s'opposer à notre modèle de raisonnement s'il ne va pas. C'est là que l'IA devient un compilateur pour la pensée. C'est par là que l'IA peut nous pousser à des solutions innovantes et qui viennent de nous.

Voila pourquoi je pense que apprendre à coder reste essentiel aujourd'hui et que tout le monde devrait le faire dans une certaine mesure, peu importe leur tôt d'utilisation des LLMs.

J'ai envie de connaître vos avis.

reddit.com
u/Spirited-Sir8426 — 5 days ago

Soyons cash: je forcerai mes étudiants à coder à la main

Je veux juste partager un peu de mon agacement et ma théorie sur l'avenir du développement logiciel.

Je suis formateur de développement de logiciel dans une école d'informatique et j'ai pu remarquer qu'avec les progrès fulgurants des derniers modèles d'IA, on vois de plus en plus de personnes et d'élève se demander s'il est encore nécessaire d'apprendre à coder. En effet, l'IA permet de le faire bien plus vite donc le code manuel est "dépassé".

Cependant, coder à la main ne se résume pas seulement à créer des logiciels. Et la pédago risque d'être dramatique si on ne fait pas attention à ce que les étudiants font derrière notre dos.

L'expression forge la pensée

On dit souvent que l'écriture forge la pensée et le code étant une forme d'écriture bénéficie de cette propriété. Cependant, je pousserai la réflexion plus loin en étendant ce concept à toute forme d'expression. En tant que francophone, apprendre une nouvelle langue comme l'anglais a aussi façonné ma façon de réfléchir et de formuler ma pensée. Parler, Écrire des dissertations ou des histoires, ou bien même des actes artistique comme dessiner ou faire de la musique sont toutes des manière de se forger car elles sont toutes expression.

Du moment qu'une idée reste dans la tête, elle demeure stérile. C'est quand on l'écrit sur papier ou qu'on la verbalise qu'on la force à prendre une forme et qu'on la transforme en objet d'étude améliorable. C'est quand j'écrit une idée ou que je dessine des diagrammes que je réalise les angles-morts de ma réflexion ou que je vois des incohérences. Le médium par lequel je concrétise mes pensées devient un miroir et me permet d'avoir un point de vu inédit.

Les sciences cognitives ont même un nom pour ça: la pensée distribuée. Ici, le cerveau n'est qu'une partie d'un système complexe où la pensée se développe. Si, par exemple, j'ai besoin de savoir combien de table je dois avoir pour installer une salle de 175 personnes à raison de 5 personnes par table, je pourrai sortir une feuille et un crayon pour faire mes calculs. Un amis à côté peut remarquer que j'ai oublié une retenu dans ma procédure et corriger la faute. Dans ce cas de figure, au moins 3 médiums ont étés utilisés pour ce processus de raffinement de la pensée: moi, le groupe papier-crayon ainsi que mon ami. La pensée a pris forme et a donnée un résultat concret (la réponse est 35 table si jamais).

La pensée distribuer dit que la réflexion et la construction d'une solution dépend de l'esprit de l'individu pensant, les outils qu'il utilise (crayon, calculatrice, internet, ou bien même un LLM), d'autres individus (par exemple le brainstorming), et le contexte. Toute activité artistique ou de résolution de problème marche dans ce principe.

L'export de la réflexion

Maintenant, la pensée distribuée nous permet, selon moi, d'identifier l'ennemi numéro un de la pensée à l'époque des LLMs: l'export de la réflexion. Ça arrive quand l'acteur principale délègue toute forme de réflexion aux autres médiums du système en donnant seulement l'entrant et en récupérant le sortant. On parle aujourd'hui de la dangerosité des IAs qui peuvent nous pondre des réponses toutes faites à nos questions, mais ce problème existait déjà depuis longtemps. On a déjà eu des cas d'étudiants refusant de comprendre les méchanismes de l'arithmétique sous réserve que cela se fait déjà avec des calculatrices. On a aussi des étudiants qui utilisaient déjà google, wikipédia et d'autres sites pour littéralement copier-coller des informations sans beaucoup plus de réflexion et de construction de leur part. Il arrivait même que des dissertations entières pouvaient être copié d'internet sans réflexion de la part de l'étudiant. Le plagiat n'est pas un context nouveau.

Le domaine du développement logiciel a aussi eu ses soucis. Par le passé, il y avait un groupe particulier de développeur qui, dans les forums (et surtout dans stack overflow) passaient le plus claire de leur temps à poser des questions à tout va, souvent mal formulées et sans context et attendais à être interroger par les membres de la communauté pour diagnostiquer le problème à leur place et recevoir une réponse toute faite. Je peux vous dire avec assurance que ce type de profil n'était pas qui ressortait avec de nouvelles connaissances. Surtout si leur plus grande prouesse était de copier-coller une réponse en ligne sans tout lire. C'est ce qui a empoisonné la chaleur des réponses des communautés comme stack overflow.

Donc l'IA, n'a pas inventé l'export de la réflexion. Elle l'a juste rendu plus accessible, touchant une plus grande partie de la population des développeur car la tentation est plus grande. Elle peut se substituer sournoisement au endroits où la charge cognitive peut-être un peu trop élevée pour un étudiant. Et c'est, là le rôle de l'enseignant(e) de pouvoir mettre en place un cours qui travail la zone proximal de développement (=ni trop dur, ni trop facile mais challengeant et fait grandir) de l'étudiant pour favoriser son apprentissage.

C'est pourquoi le fameux "rubber duck" (canard en plastique) marche toujours etest souvent plus efficace que le LLM en terme d'instrument pédagogique. En effet, le canard n'est pas un technicien et force la personne qui développe à simplifier et à mieux formaliser son raisonnement. Ce qui conduit assez souvent à une solution par compréhension plutôt que ex nihilo.

Une étude mennée par les chercheurs du MIT et de l'Université de Pennsylvanie a prouvé que les étudiants qui ont utilisé l'IA pour les exercices d'entraînement ont été moins performant durant l'examen final que les étudiants qui n'ont pas utilisé l'IA. Ce phénomène n'est pas là pour dire que les LLMs sont de mauvais outils pédagogiques mais qu'ils peuvent devenir problèmatique selon la manière dont on les utilise.

Conclusion

Bien sûr, les LLMs peuvent être l'outil le plus puissant d'apprentissage s'ils sont bien paramètrés. On peut par exemple obtenir un effet Rubber Duck en prenant des modèles moins puissant et en raisonnant avec eux. On peut aussi interdir au modèle de construire des solutions sur mesure mais de seulement donner des réponses similaire à celles d'une recherche google (Bien sûr sans Gemini). L'élément le plus important selon moi est le challenge. Il faut explicitement forcer l'IA à chercher les failles et les angles-morts de notre raisonnement, challenger certaines certitudes qui n'ont pas de preuve réelle et vraiment s'opposer à notre modèle de raisonnement s'il ne va pas. C'est là que l'IA devient un compilateur pour la pensée. C'est par là que l'IA peut nous pousser à des solutions innovantes et qui viennent de nous.

Voila pourquoi je pense que apprendre à coder reste essentiel aujourd'hui et que tout le monde devrait le faire dans une certaine mesure, peu importe leur tôt d'utilisation des LLMs.

J'ai envie de connaître vos avis sur la question. Comment vous vivez ça en tant qu'étudiant ou enseignant?

reddit.com
u/Spirited-Sir8426 — 5 days ago

Ce qui m'a fait quitter Python (et pourquoi je préfère maintenant R, Rust… et mon propre langage)

​

Une fois je me suis sérieusement demandé pourquoi les gens aiment Python alors que je le trouve pas incroyable en terme de design du langage. 

C'est vrai qu'il a un ecosystème poussé et un communauté nombreuses mais j'ai trouvé la syntaxe un peu éclaté au sol.

Il y a pas mal de choses que j'aime pas mais je pourrais ressortir la syntaxe, le nesting, la POO, la programmation fonctionnelle, le système de types. Mais j'ai grave comparé avec R, Rust et TypR (mon langage) en vrai.

Je dirai même que mon langage est diamétralement l'opposé de python dans son design.

Bref, je sais que j'ouvre une guerre de clan mais je voulais juste montrer pourquoi Python ne correspond pas à ma philosophie du code.

youtu.be
u/Spirited-Sir8426 — 13 days ago

[Vidéo pédagogique] Les langages de programmations à l'air de l'IA

Bonjour, je suis formateur de développement logiciel dans une école d'informatique et il m'est déjà arrivé qu'un étudiant me pose la question de la nécessité d'apprendre un langage de programmation à l'ère de l'IA.

Au delà de la réponse que les principes de programmation restent d'actualité ainsi que le fait que un prompte en language humain sera toujours plus ambiguë que du code. Je voulais mettre en avant le problème que "Le langage parfait n'existe pas".

En effet, non seulement la nécessité d'apprendre un langage de programmation restera importante, mais nous verrons encore naître des langages de programmation plus spécifique. Ça ouvre aussi le débat de la possibilité d'avoir des IA spécialisées dans des domaines spécifiques au lieu de poursuivre cette course effrainée sur l'obtention de l'AGI (en plus ça risque pas d'arriver de si tôt et certainement pas avec le model des LLMs).

J'aimerai connaître votre avis sur cette thématique et ce qui serait important de transmettre au étudiants qui seront les ingénieurs de demain. Merci d'avance!

youtube.com
u/Spirited-Sir8426 — 27 days ago
▲ 2 r/AIcodingProfessionals+2 crossposts

I didn't build TypR for AI — but it turns out a type-checked layer over R is a surprisingly good fit for reviewing AI-generated code. Some thoughts, and I'd like your pushback.

Some of you have followed my earlier posts on TypR here. This one's less "what's new" and more the reasoning behind the design — I'd like your pushback on the thinking itself.

The honest origin story: I didn't build TypR for AI. I built it because I care about type systems (academic background) and about code that survives production (industry background) — verifiability, basically.

What clicked more recently is that the property making code cheap for a human to verify is the same one that matters when a machine wrote it.

As AI writes more of the code, the expensive part stops being writing it and becomes trusting it — reviewing, validating, maintaining. A strict type system becomes a free automatic checker on whatever got generated; concise syntax means less to misread.

So the fit with the AI era isn't something I designed for — it's the same property suddenly mattering a lot more. That's the accidental discovery I wanted to share here.

A small taste — this R (no needs to read it fully):

#' Create a button widget
#'
#' @param color \code{char}
#' @param height \code{int}
#' @param text \code{char}
#' @param width \code{int}
#' @return \code{Button}
#' @export
Button <- function(color, height, text, width, .spread = NULL) {
  explicit <- list()
  if (!missing(color)) explicit[["color"]] <- color
  if (!missing(height)) explicit[["height"]] <- height
  if (!missing(text)) explicit[["text"]] <- text
  if (!missing(width)) explicit[["width"]] <- width
  x <- typr_spread_record(explicit, .spread)
  as.Button(x)
}

as.Button <- function(x) {
  if (!inherits(x, "Button")) class(x) <- c("Button", "list")
  x <- validate_Button(x)
  x <- validate(x)
  x
}

validate_Button <- function(x) {
  required_fields <- c("color", "height", "text", "width")
  missing_fields <- setdiff(required_fields, names(x))

  if (length(missing\_fields) > 0) {
stop(paste0("Validation failed for type Button: missing fields: ", paste(missing_fields, collapse = ", ")))
  }

  if (!inherits(x[["color"]], "character")) stop("Validation failed for type Button: field 'color' must be of class character")

  if (!inherits(x[["height"]], "integer")) stop("Validation failed for type Button: field 'height' must be of class integer")

  if (!inherits(x[["text"]], "character")) stop("Validation failed for type Button: field 'text' must be of class character")

  if (!inherits(x[["width"]], "integer")) stop("Validation failed for type Button: field 'width' must be of class integer")

  x
}

# constructor for a red button
#' @export
#' @method red_button
`red_button` <- (function(height, width, text) Button(height = height, width = width, text = text, color = "#FF000000" |> as.Character())) |> as.Generic()

# add an "on click" callback function
#' @export
#' @method on_click Button
`on_click.Button` <- (function(self, f) {
NA
} |> as.Empty0()) |> as.Generic()

becomes this TypR:

# Create a button widget
@export
type Button <- list {
	text: char,
	color: char,
	width: int,
	height: int
};

# constructor for a red button
@export
let red_button <- \Button:{ color: "#FF000000" };

# add an "on click" callback function
@export

let on_click <- fn(self: Button, f: (T) -> U): Empty {
	...
};

The way TypeScript sits on top of JavaScript's runtime, TypR sits on top of R's: you write something concise and type-checked, and it compiles down to standard, S3-based R that runs anywhere R runs and installs like any other package — no new runtime, no exotic dependencies.

To be clear, it's not trying to replace R. R is excellent for interactive stats and lab work, and TypR deliberately gives some of that up in exchange for the other end of the curve: robust packages, deployable apps, code that has to survive production. Different point on the trade-off, different job.

On the engineering side you get pattern matching, partial currying, union/intersection types, structural subtyping, row polymorphism — the machinery that keeps a growing codebase honest. Written in Rust, developed in the open.

Honest questions for this sub: does a typed layer over R solve a problem you actually hit, or is this a solution looking for one? And does the "verifiability matters more when AI writes the code" argument hold up, or am I reaching?

Discussion: https://github.com/we-data-ch/typr/discussions

Github: https://github.com/we-data-ch/typr

Website: https://we-data-ch.github.io/typr.github.io/

u/Spirited-Sir8426 — 29 days ago
▲ 5 r/rstats

TypR now integrates with Rd and pkgdown documentation

I've been working on a new documentation feature for TypR that I thought the r/rstats community might find interesting.

TypR can now automatically inject types, modules, and examples into Rd documentation, with support for pkgdown as well.

A few things I'm particularly happy with:

- Automatic links between documented types, making it easier to navigate package documentation.

- Type aliases can have their own documentation page.

- Type aliases can also have their own documented constructor when appropriate.

The motivation is to reduce duplication and make package documentation more consistent and easier to maintain, especially as projects grow.

I'd be interested to know:

- Would this be useful in your workflow?

- Are there documentation pain points in R that you think tools should address?

I'd really appreciate any feedback or suggestions!

Github: https://github.com/we-data-ch/typr

Website: https://we-data-ch.github.io/typr.github.io/

u/Spirited-Sir8426 — 1 month ago

Je détestais la documentation de code jusqu'au "documentation as code"

Pour être honnête, je suis le type de personne qui boude la documentation. Or, c'est ce qui permet aux personnes d'utiliser les modules/packages dont on a besoin.

Il y a 3-4 ans, j'ai découvert la beauté de la "documentation as code". C'est exactement ce dont j'avais besoin. J'aime tellement ce concept que je l'ai ajouté à l'écosystème de R, un langage de programmation pour les statistiques.

Ma plus grande satisfaction a été de découvrir que les types aident grandement à documenter du code.

Je ne suis pas un expert dans la matière. C'est pourquoi je vous invite à regarder la vidéo que j'ai récemment sortie et de me faire un retour sur les trucs que je manque ou que je fais faux

youtu.be
u/Spirited-Sir8426 — 1 month ago

J'ai essayé de refaire Manim avec R

À la base, je voulais juste comprendre deux choses :  

  1. pourquoi Manim impose autant de restrictions techniques,  

  2. jusqu’où je pouvais pousser TypR (version typée de R) dans un vrai projet.

Manim est brillant…  

mais entre les dépendances Python, l’OOP obligatoire et la complexité du framework, j’avais l’impression de devoir complètement changer mon workflow pour animer un cercle...

Alors j’ai tenté l'expérience de refaire Manim en R.

Et c’est là que TypR m’a surpris.  

Pas seulement pour ses features modernes, mais pour sa capacité à me laisser construire une grammaire propre, expressive et formellement définissable. Il me permet de faire une connexion plus directe entre les données et les animations.

C'est s'imple car TypR s'occupe du compliqué:

- structural typing (définir des mobjects sans hiérarchie rigide),  

- row polymorphism (étendre les objets sans casser le modèle),  

- partial application explicite (composer des animations comme des fonctions),  

- constructeurs par défaut + validateurs (définir une "grammaire formelle" pour les mobjects),  

- uniform function call syntax (une API lisible, déclarative, naturelle), 

… j’ai pu designer un moteur d’animation beaucoup plus facilement que prévu.

Résultat :  

- un modèle de mobjects simple, typé et extensible,  

- une timeline efficace

- un format JSON stable et prévisible,  

- un runtime JavaScript minimaliste,  

- une API R qui ressemble plus à une "grammaire" qu’à un framework.

Dans la vidéo, je raconte comment la frustration de Manim m’a poussé à explorer TypR…  

et comment TypR a transformé cette exploration en un moteur d’animation fonctionnel, propre, et étonnamment élégant.

Dans le future je me lancerai pleinement dans l'implémentation du package.

N'hésitez pas à regarder la vidéo et de me faire un retour!

youtu.be
u/Spirited-Sir8426 — 2 months ago

Les limites des types en data science (et pourquoi j’ai voulu explorer une autre approche)

J'ai remarqué qu'en data science on a plein de donnée vastes:
structures imbriquées, données partielles, formats hétérogènes, validations silencieuses, etc.

Et pourtant, la plupart des workflows reposent encore sur des dataframes “magiques” ou des listes non typées.
Ça marche… jusqu’au jour où ça casse, et souvent sans prévenir.

Je me suis demandé :
Est‑ce qu’on peut apporter un vrai système de types aux données réelles, sans rendre R inutilisable ?

C’est ce qui m’a poussé à travailler sur TypR, un système de types pensé pour la data science :

  • alias de type
  • constructeurs automatiques
  • validateurs/refined types
  • typage de structures complexes
  • génération de code R clair et robuste

J’ai fait une vidéo pour montrer comment ça fonctionne et ouvrir la discussion sur le sujet :
👉 https://www.youtube.com/watch?v=1VM2mCUofAU

Je serais vraiment curieux d’avoir vos retours, surtout sur :

  • les limites que vous rencontrez avec les types en data science
  • ce que vous aimeriez voir dans un système de types pour R
  • les approches que vous utilisez déjà (S3, S4, R6, vctrs, dataclasses maison…)

Bref, discussion ouverte.
Je suis preneur de critiques, d’idées, de contre‑exemples, tout ce qui peut faire avancer le sujet.

u/Spirited-Sir8426 — 3 months ago