The approach of incrementally introducing language features is what Matthias Felleisen advocates: https://felleisen.org/matthias/Thoughts/Developing_Developer... Felleisen's argument is that all general-purpose languages are too big to be appropriate for teaching, and you should use specialized teaching languages. In Northeastern University's introductory programming class, students start with a minimal Scheme called Beginning Student Language (which has primitives, function application, if, cond, and top-level define), then move up to Intermediate Student Language (which adds local), then Intermediate Student Language with Lambda (which adds function literals). Each addition is given a motivation (locals let you avoid repeat computations, local functions let you capture the environment, lambdas let you use local functions without giving them a name).
But Hedy seems to make the mistake that many curriculums do of focusing on the minutiae of syntax. Don't do that! Northeastern's course emphasizes broad concepts such as abstraction, accumulators, and generative recursion. Meanwhile, it uses simple s-expr syntax.
I wonder if a way to make a language gradual is to keep it primitive, but easy to build the more advanced features by composing them from primitive features. I mean, that's ultimately how all interesting programming is done, but it could be introduced at a much earlier and more basic level so it's not fearsome.
As an aside, I think that these online courses are a valuable resource, but it still helps to provide some human supervision, to make sure that a student hasn't fallen into a rut and given up.
I said this in my other reply, but if you can implement a language feature as a local rewrite, it does not add expressiveness. Features that add expressiveness must involve some sort of non-local transformation. A language feature adds expressiveness iff two programs that are equivalent in the base language in all evaluation contexts are not equivalent in the extended language. Felleisen came up with this idea in a paper, which Shriram Krishnamurthi explains in this video: https://pwlconf.org/2019/shriram-krishnamurthi/
This is an interesting approach (and also raises interesting questions concerning the relative power of languages, i.e. how adding various features relates to moving from binary logic -> regular languages -> ... -> turing complete, but I'm overthinking it...), but isn't it a tad too limiting? You at least need recursion to do anything that isn't completely trivial in Scheme, even for a CS 101 course.
Wouldn't you outgrow them so quickly that you'd end up with "just Scheme, but more annoying" within a couple lessons?
You can have recursion right from Beginning Student Language (which lets you define top-level functions and call them recursively). Structural is taught early, together with lists. Structural recursion is explained together with recursive data: To unpack the data (any data, not just recursive), unpack the inner members, and therefore the structure of the program follows the structure of the data.
As someone who is taking the accelerated version of this course right now, but had prior functional programming experience, I did feel limited at first. Some other people responded negatively to the student languages because they weren't "mainstream."
As for the expressive power of languages, as a matter of fact, Felleisen wrote a paper that rigorously defines this idea. Here is a talk by Shriram Krishnamurthi that discusses it: https://pwlconf.org/2019/shriram-krishnamurthi/ It turns out that local transformations (macros) do not add expressive power. A language feature adds expressive power if you can find two programs that are observationally equivalent in the base language, but not the extended language.
It might feel limited for students with prior programming experience. However, my first programming course (in high-school) used BSL & co, taught from “How To Design Prgrams” (1), and it didn’t feel restrictive. Having to manually recurse, construct lists, &c. made clear exactly what later abstractions and syntactic sugar did. Rather than feeling that my hands had been tied before being introduced to, for example, higher order function, I felt I’d been granted superpowers once i had: nearly every function we’d previously struggled to write could now be written in one or two lines, and we even understood fully what those lines meant! Admittedly, this excitement was that of an absolute beginner.
As someone who gives programming courses at an art university I always like to teach programming languages that they can use for "serious stuff" afterwards. Python turned out to be a good choice, because the syntax is beginner friendly, problems can be googled and there are a lot of good libraries included.
I think the biggest challenge in teaching someone programming is to teach them the way you have to "speak" to a computer and in what it differs to speaking e.g. to a waiter in a Cafe. Many people who teach programming sort of just assume this (they probably forgot how long it took themselves initially to get to the point where they could from this).
I can corroborate your experience. When I was a college student, I also used to earn a bit of extra pocket money teaching art students to program.
We used Flash and ActionScript 2.0.
It was amazing how quickly it could be used to create interactive stuff. And since almost every new concept allowed students to make more interesting stuff, they were incredibly motivated to learn.
I’m confused. Perhaps because I can not unlearn what I knew but it does not make it easier for me, it makes even harder! The syntax is changing, subtlties (one dot or 3 dots?) not specific mentioned etc. all that makes things more confused. Maybe it’ll be easier for kids who will write in their natural English way. I don’t know. But I can not see why Hedy should be better suitable than Scratch for teaching programming for children. The visual, direct manipuable approach of Scratch is very powerful and intuitive at the same time. I’ve seen very smooth transitions from Scratch to other “serious” programming language. I don’t expect that kind of smooth transition by Hedy.
Nice idea, but the “rules” change between levels - I imagine that’d be super confusing to the learners. Given this is from a university and it has hopefully gone through some form of user research, the fact this works is quite surprising. (Imagine if you were learning English but what you learned last week no longer works)
My experience is that people of any level who say "can you teach me to code" will not learn by brute force. I try to start with the most basic of basics - but there's just WAY too many concepts there. No one even makes it to functions. Even most programmers take a long time to realize that the syntax they learned was as abstraction over the hardware... there's so so much to learn.
This idea of "gradual changes" is surely worth a test. Yeah, the rules might change - but at that level, the "rules" are just meaningless symbols anyway. If the ideas stick - and you truly understand them, not just memorize them - adapting will be a lot easier than recalling "oh yeah, for some reason there needs to be a semi-colon here".
I think it's really clever - I'm going to test-drive it on some unsuspecting nephews and neices.
I'm not sure there is a big enough market gap between something like Scratch, and Python to justify teaching this.
I remember learning programming using Pascal in middle school, and while I really liked the language (in many ways I still prefer it to C), my first lesson began by the teacher mentioning that Pascal is a language designed for learning programming in contrast to 'real' languages used in the industry.
This immediately made me think 2 things:
- If I want to be a cool kid, I'll have to move on to a 'big-boy' language like C.
- Any effort invested into learning Pascal is wasted, since it's only a tutorial for a 'real' language
I don't particularly like the syntax, I find it really hard to mentally "parse" the program and I wonder what's the takeaway from someone who can't already say "hey, they're trying to teach for-loops here". It's almost the opposite approach as the legendary SICP.
Also, by the love of god, disable that freaking popup. IT. LOADS. ON. EVERY. PAGE. 100,000th visitor? Seriously? Is this time-travel spam from 2002?
It's fine to be critical but can you please not do it like this? I love SICP too, but snarky putdowns are not a fair way to treat anyone's work, and when you do it this way, you're patterning the community on behaving this way—which unfortunately the internet is already wont to do. If we don't want a toxic culture, we all need to work at it.
Also, "Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized."
Appreciated—and I believe you of course. The trouble, as you know, is that intent doesn't communicate itself very well on the internet. Objects in the rear-view mirror are snarkier than they appear, or something like that.
The forum thread is such an intimate conversational genre that we're all inclined to wing it in the comments (and so we should), and at the same time it's common for people to see their own work discussed here, plus HN threads tend to rank high in search results, so the impact can go far beyond the room.
But Hedy seems to make the mistake that many curriculums do of focusing on the minutiae of syntax. Don't do that! Northeastern's course emphasizes broad concepts such as abstraction, accumulators, and generative recursion. Meanwhile, it uses simple s-expr syntax.