Related to the idea of "Notional Machines" (§4) I recently realised that what I'm calling "denotational strategies" can be vastly more efficient for learning than "operational strategies". For example, learning recursion via an operational semantics / abstract machine model can make recursion seem very complex. Maintaining the stack and tracing through the control flow is hard. Alternatively one can use structural recursion patterns (think proof by induction) in which case you don't have to think through the control flow. The correctness is guaranteed if the individual cases are correct.
Probably this statement isn't so understandable from the above description. It really needs a blog post of its own.
My guess is that "denotational strategies" (from what I can guess you mean) just move the cognitive load around in other places. That doesn't make them worse, but it depends on which kind of cognitive load the learner best copes with.
Agreed that the lack of evidence makes any of my claims not much more than hot air. It's something I'm interested in rectifying but I'm not sure how to do in our context (professional training and free intro to programming).
I think that's true for anyone who's comfortable with proofs by induction, but most people aren't until well past the point where they'd normally learn to program.
You don't need to understand proof by induction to use these techniques. It's more than I have the energy to explain in a comment here, but the chapter on "Structural Recursion" at http://www.creativescala.org/creative-scala.pdf shows some of my thinking (though it has evolved a bit since that written.)
But more importantly, I can tell you that the design recipe isn't enough. That's why we set out to study the notional machine question (paper cited in another response). We most definitely need it too; what we're trying to figure out is what form of notional machine matches best.
Just want to say I really enjoyed your chapter on “Visuals and Blocked Languages”.
My career got started programming Flash. Mostly because I loved the visuals and wanted to code it. Even though there is scratch, and other block based languages it seems text is still the king.
Text as you’ve identified is not the most new comer friendly.
I still think the holy grail of visual programming is still to come. Most of coding is describing abstract syntax trees. A nice visual tree/graph manipulation editor has yet to be invented. Being able to have a hybrid text and visual seems like a good place to be.
I’ve spent many years thinking and obsessed about this concept. Especially around the ideas of code completion/intellisense.
What are your opinions on how kids in a decade will code?
I think we'll find that there are a dozen different _reasons_ kids will need/want to code, and each of those will lead to dramatically different environments and ways. For instance, do kids need intellisense? Yes, if they're trying to accomplish a particular application goal, whereas maybe it's a bad idea if they're still learning the basics of programming.
Good read. I feel the title should be "Teaching Programming Paradigms and Beyond" since the text assumes familiarity with complete CS landscape and comments on success of several teaching methods.
I would recommend (also misleadingly titled) talk The Future of Programming by Bret Victor [1] which goes over some groundbreaking paradigms that have since become mostly forgotten.
It's in a Handbook of Computing Education, so everything in the book is about "teaching". It would therefore have been especially odd to put that in the title.
I think they're referring to the Racket programming language [0].
Shriram also authored "Programming Languages: Application and Interpretation" [1] and co-authored "How to Design Programs" [2] with Matthias Felleisen, Robby Findler, and Matthew Flatt. Both books use Racket as a base (well, PLAI uses PLAI/typed, which is built from Racket and utilized the DrRacket interpreter... close enough).
I’m sad that such extensive research on paradigms and behavior doesn’t mention any of the very important and truly innovative work of Dr Harel such as “Statecharts: A visual formalism for complex systems” (1986) and “Behavioral programming” (2012)
Author here. I have great respect for Harel's statechart work, but it wasn't mentioned because it's not particularly germane to the topic at hand — the chapter is part of a computing education handbook. There are indeed other such chapters where one could imagine these references making a lot of sense.
I think DRAKON (https://en.wikipedia.org/wiki/DRAKON) worth mentioning in Visual Programming. It is very different from other visual programming systems and had clearness for complex algorithms that other visual systems lack (no line intersections, skews and other).
Thank you for post... Wondering if you can recommend any further reading? (Besides your forthcoming book :-) ) I am very interested in this topic, especially how one might make a easy-for-novices programming language. (I am sure there are many existing examples as well.)
Not MY forthcoming book (-: — "Handbook" means the chapters are written by many different people. The main chapter that deals with PLs is this one, though. What do you think it's lacking? (Did you actually read it? <-;)
Attended a talk about teaching programming to kids by the first author that was well attended by programmers and teachers. It was a very enriching experience. I'm definitely going to read this through.
So after a bit of digging I found this free iOS app “Foxit reader”. It has a “re-flow” mode that allows making font sizes larger, responsive widths, and reading pdfs on a phone much more accessible.
Probably this statement isn't so understandable from the above description. It really needs a blog post of its own.
My guess is that "denotational strategies" (from what I can guess you mean) just move the cognitive load around in other places. That doesn't make them worse, but it depends on which kind of cognitive load the learner best copes with.
But more importantly, I can tell you that the design recipe isn't enough. That's why we set out to study the notional machine question (paper cited in another response). We most definitely need it too; what we're trying to figure out is what form of notional machine matches best.
And thanks for mentioning the paper. I'll give it a read.
My career got started programming Flash. Mostly because I loved the visuals and wanted to code it. Even though there is scratch, and other block based languages it seems text is still the king.
Text as you’ve identified is not the most new comer friendly.
I still think the holy grail of visual programming is still to come. Most of coding is describing abstract syntax trees. A nice visual tree/graph manipulation editor has yet to be invented. Being able to have a hybrid text and visual seems like a good place to be.
I’ve spent many years thinking and obsessed about this concept. Especially around the ideas of code completion/intellisense.
What are your opinions on how kids in a decade will code?
I would recommend (also misleadingly titled) talk The Future of Programming by Bret Victor [1] which goes over some groundbreaking paradigms that have since become mostly forgotten.
[1] https://www.youtube.com/watch?v=8pTEmbeENF4
Programming Language education blind spots and opportunities for research. Recommended for anyone who teaches, learns or writes programming languages.
Shriram also authored "Programming Languages: Application and Interpretation" [1] and co-authored "How to Design Programs" [2] with Matthias Felleisen, Robby Findler, and Matthew Flatt. Both books use Racket as a base (well, PLAI uses PLAI/typed, which is built from Racket and utilized the DrRacket interpreter... close enough).
[0] https://racket-lang.org
[1] http://cs.brown.edu/~sk/Publications/Books/ProgLangs/
[2] http://www.htdp.org
https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf