I find the core position of the author unconvincing - that is, the author advocates for non-professional languages for beginners, instead using languages designed specifically for teaching. The main argument put forward in favor of professional languages is crossover: if a student learns a language in class, they may be able to use that language professionally. The author then argues against that main point.
I think students should be taught in "professional" languages, but crossover is not my main reason. Rather, it's that professional languages have an enormous corpus of examples that students can look up. If a student is learning on a teaching language without much adoption, there's just not much else a student can do but use the materials that part of the course. Teaching languages don't let students expand their universe of examples.
I agree with the author's point about real insight coming on learning the second (and third, etc.) language and systems. But I don't find it as a compelling point in favor of teaching languages - quite the opposite. To me it means there's no need to obsess over first languages.
Designing programming languages is fun. Designing a programming language which meets some platonic ideal of teachability is moreso because it feels possible to "solve" the design and craft the perfect jewel of a language. But I'm unconvinced it's useful research.
For the record, my first language was C++, and I'd default to teaching beginners in Python.
I also find it more useful to teach something real, not a toy.
Even PASCAL was never a toy, though it was designed motivated by teaching purpose, it became professional because it was capable of that.
When I told some friends I was going to teach 11-year-olds to program, and that I was considering some BASIC versus Python, they suggested Scratch. But 11-year-olds aren't babies. They can understand a lot, and they should be enabled to talk about their code (which textual representations enable, but not Scratch-style visual programs).
So I picked Python (with pyturtle for easy turtle graphics), and it worked well.
I actually think Scratch is fine for 10ish year olds, mainly because all of my above holds true: scratch.mit.edu is an online community where kids can copy, tweak and in general be inspired by and learn from what other kids have done. Your universe can expand with your curiosity. When my nephew was 10, he started with Scratch. My brother guided him towards using Python on a Raspberry Pi soon after.
For kids around 10, I think it's all about what the kid thinks is more fun.
exactly... just getting rid of boilerplate on syntax feels so friendly with the tiny humans
we should also don't forget that learning for its own sake, sometimes, is the meaning/end of pedagogy; not luring them to the professional path of computer science/programming
I would be surprised if your first program was C++? Specifically, getting a decent C++ toolchain that can produce a meaningful program is not a small thing?
I'm not sure where I feel about languages made for teaching and whatnot, yet; but I would be remiss if I didn't encourage my kids to use https://scratch.mit.edu/ for their early programming. I remember early computers would boot into a BASIC prompt and I could transcribe some programs to make screensavers and games. LOGO was not uncommon to explore fractals and general path finding ideas.
Even beyond games and screensavers, MS Access (or any similar offering, FoxPro, as an example) was easily more valuable for learning to program interfaces to data than I'm used to seeing from many lower level offerings. Our industries shunning of interface builders has done more to make it difficult to get kids programming than I think we admit.
Edit to add: Honestly, I think my kids learned more about game programming from Mario Builder at early ages than makes sense.
> I would be surprised if your first program was C++? Specifically, getting a decent C++ toolchain that can produce a meaningful program is not a small thing?
Visual C++ (some version) was in a book I received as a gift in high school, it was my second language after BASIC (some version on a Tandy running MS-DOS). It was not hard to set up. You ran the installer, you had the language set up. If someone had ended up in the same situation as me but without the BASIC experience, I could see it being an easy to set up (not easy to learn) first language.
Apologies for making you prove the statement. That wasn't my intention.
I was musing on how expensive a C++ capable setup was back when I was learning. I was probably closer to having it as an opportunity than I realize. But MS Access and the like was already something that was beyond my realistic budget for things. That was largely helping out with business software friends of the family were using.
I am probably also more sour on just how silly difficult it is to put pixels on a screen nowadays. Python's turtle graphics kind of works ok, if you are only doing turtle graphics. But just getting a sprite and moving it around can be surprisingly involved, it seems. I wanted my kids to learn with the Code the Classics book. May have them give that a try again, soon. First pass, they all have far more mileage with Scratch.
My first program was indeed C++. In 1998, my high school had a computer lab setup with Turbo C++, and I took a non-AP computer science class. In college, starting in 1999, after entering as a computer science major, we were guided to use Visual C++ on Windows. We got Visual C++ from our department - I can't remember if we paid or if it was just provided to us.
odd to publish such an article with so many undefended opinions.
for instance, that low-boilerplate is somehow worse than high-boilerplate languages because the boilerplate somehow builds character ("teaches important lessons ... from the start"). this insipidly assumes boilerplate is necessary for encapsulation and modularity. yes, the directness of Python does make it better than Java.
similarly, there seems to be a peculiar theory of learning here: both that learning many languages is a goal, and that you should Do It Right from the start. suppose the goal is to learn concepts, and it's perfectly fine to iteratively use a single language, starting with a simple subset.
Well, I'm still waiting for something to beat the MSWLogo which defined my childhood between 8 and 12 years old. By now I've tried quite a few things with my kids and most of them IMO display a complete lack of understanding of what can be good for a 8-10 year old child. E.g. typing "player.move_forward()" instead of "fw" (hi, codingforkids) is complete insanity: kids typically do not master touch typing by that age. Furthermore, with kids using tablets instead of PCs nowadays I doubt most of them will master touch typing at all. Nor do they care about the syntax of ".member" and "func()" for that matter, that's beyond the point when you're just trying to figure out what a procedural program even is.
I'm open to recommendations of programming languages and programming-related games for kids between 4 and 12 years old, for Android and PC. This is what I've tried so far:
* Scratch is interesting but simple programs like "add two numbers" require crazy levels of dedication of drawing sprites for every digit and programming a character for every decimal place (unless I got it wrong, open for advice). I think it will come handy later to teach about eventloops, signals and threads, but not as a first language.
* codingforkids.io -- "papa, but this sucks, you do it all day?" was hard to argue with that
* Human Resource Machine -- incredible game and does drill some good concepts but is too remote from programming (I still recommend it though)
* Mindustry -- also a good game but is even further away from what programming is compared to HRM
* Any other recommendations?
The abstract asks:
> Why do we not have a programming language that is designed for education and in widespread use across the world
It is important for a teacher to immediately demonstrate subject-matter mastery. If a student asks a question that goes beyond the planned lesson, you need to have an answer. You can't say, "I don't know how to do that." That would make you look incompetent.
When you're teaching programming, it is easiest to do this with a programming language that you know well and use everyday. That language is unlikely be a language designed explicitly for education.
I was a TA and instructor for several programming classes, usually in Java, with which I was moderately experienced but not an expert.
My students would frequently ask how to accomplish something, how syntax or keywords worked on q deeper level, whether there was a stl class for a purpose, or what caused an error, etc, that I didn't know about already. I didn't hide my ignorance even a little bit, but Idid help them find an answer. In lecture settings, if it wasn't too much of a digression, I'd demonstrate finding the answer. In one on one help, or one on group help, I'd lead them through finding the answer themselves. My students had a lot of respect for me as an authority on the language and still listened to my advice and came to me with questions frequently.
This is kinda important across all fields, but especially in programming, you don't need to know the right answer by rote so much as you need to be able to seek and identify the right answer with some independence using existing resources.
This article argues at considerable length that an "educational" language targeting complete novices should choose a keyword-heavy syntax like Wirth's Modula 2 as opposed to a terser one like C, prior to discussing more esoteric topics like structural editing, "frame"-like graphical representations of high-level syntax and such. Is there any significant evidence that the keyword-heavy syntax style may be easier to understand for novice coders, or is this just a matter of subjective preference?
I'm surprised the author doesn't mention LISP, despite recognizing at some point that programming also IS language design (without explicitly calling it meta-linguistic abstraction, unlike SICP).
LISP is the language/notation most easily/flexibly extended, and this is one of the reasons why it may never disappear as long as we still have programming languages around.
Counter view: there should be no such thing as an educational programming language. Some set of regular production languages that are sufficiently easy to learn that they can be used in education should exist. If not then collectively we're doing something wrong with language design.
Random data point: I "taught" a middle school coding class for a couple years using JS. Turned out ok.
I wanted the author to pick a winner among approaches, but he's surveying and inviting new research. Most recently, Kölling has supervised the development of Strype, a frame-based editor for python. https://strype.org/
Genuinely curious about how LLMs and tools like bolt.new will change programming education. (Not computer science education—that might not change much)