When I taught Python, beginning students would spend a huge amount of time just struggling with how to quote strings. Why do strings show up with \n in them sometimes and actual line breaks sometimes? Why are there sometimes backslashes that appear and disappear in front of other backslashes or quotation marks? Why does the output of typing "print x" give you something different from "x" (which actually shows you repr(x))? There are very good reasons for all of this, but it's a lot to try to explain and absorb at once.
Quoting strings is second nature to me. But to understand why it's necessary, you have to imagine what happens when you don't quote strings and then you run into trouble like "how do I write a quotation mark?" It's just harder to imagine encountering that problem and then imagine how you would solve it and what might work or not work, than it is to actually experience the problem and work with a concrete instance of it.
The switch from print as a statement (no parentheses) to print as a function in Python 3 (parentheses required) feels like a problem with some similarities. To the beginner, Python 3 syntax has just added some superflous extra punctuation to print(). To experienced programmers, it makes sense to treat print as a function because then you can pass it to other functions, re-assign it, and so on — so we underestimated its impact on beginners. To see "print(3)" and answer "why did you have to write (3) instead of 3?" you have to explain higher-order functions or monkey-patching or something that a beginner doesn't know about, and they have to imagine the hypothetical situation in which that would be necessary. That takes a lot more work and abstract reasoning than having the situation right in front of you and discussing what to do about it. It's not much of a leap from there to postponing the extra syntax until we have the concepts to talk about why we need it.
If she has the same approach to Hedy (and I have no reason to doubt that) then I hope that the research being done with this project will bring in some new insights from outside of programming (and ideally also come up with some of their own, but I have a hunch that there's a ton of low-hanging fruit outside of the programming world that could be useful here).
This is how I want documentation written for features added to a language.
For example, why were arrow functions added to JavaScript? The documentation should explain the problem and motivation for why it was added to the language with demo code so someone can directly experience the problem.
I want this for every single feature added after the 1.0 release. Not just for JS, but for every language, library, and framework.
http://www.ada-auth.org/standards/12rat/html/Rat12-TOC.html
That is the Ada 2012 Rationale, for example. It details changes to the language standard with examples and explanations, as well (in the Epilogue sections) as things that were dropped. It would definitely be nice to have this for more languages, especially as it can help you grok what's changed in a specific version/edition/whatever (not just a full Language X rationale, but Language X 2.0's rationale for changes over Language X 1.0).
Give some examples so folks can decide if it's relevant to them, then show them how to do it (with follow-along coding or a hands-on lab if at all possible), and only at the end dive into how it works.
That way, even if people zone out partway through, they may have learned something useful.
This question does not get asked if print is presented as a function from the get-go.
I can see where you're coming from about letting students/children experience the problem themselves before being fed a solution, but in this case the problem only arises due to your having been taught something some way. It is not inherent.
Do you have kids? My nephew has been learning math. He won't be told about f(x) until he reaches algebra. Until then the presence of parentheses would just be arbitrary added complexity. In fact he hasn't even been shown parentheses in the context of application order yet.
I agree with you that you could start with that syntax. I also think you could start with = instead of "is". In both of those cases though we've introduced distinct concepts - function application and operators - and her entire approach is based on introducing one concept per learning step.
> There are very good reasons for all of this, but it's a lot to try to explain and absorb at once.
The reason is because you're embedding strings into the program, which is just a string. There's no reason languages have to be like this. The ironic part is that developers are just like children and do not understand the significance of this either, which is why string injection vulns still exist today.
Plus it is just really boring to struggle with syntax and typing. It is much more interesting to think about how to get a program to work, and kids are only really going to learn things well if they find it interesting. At least my kids.
I could be totally wrong, but I've never seen an instance where kids exposed to dumbed-down "reduced complexity" material outperform those that weren't, except in sports and art. You can teach the mechanics of a tennis swing with small racquets and oversized balls, but can you really teach pointers with an iPad environment?
Simon Peyton Jones gave a great lecture on this topic at Strange Loop a few years ago. Basically, "computer science" can be reframed as the study of information, computation and communication. Thinking about these subjects rigorously and solving the problems surrounding them is a foundational skill that is much more broadly applicable than just in programming, and really does not need to involve computers at all (as he shows in his lecture.
> I could be totally wrong, but I've never seen an instance where kids exposed to dumbed-down "reduced complexity" material outperform those that weren't, except in sports and art.
I'm not sure I follow. I mean, that's how children learn to read and write, it is not? Or how they learn maths at school: one step at a time.
I'm not entirely joking either; a lot of these "teach kids to code" efforts either start far too high-level and don't really help to dispel the myth that computers are magic, or border on outright corporate indoctrination ("use this locked-down environment, don't even think of trying to go outside it".)
Isn't literally every subject taught exactly this way? Books for toddlers don't have chapters for a reason. Practicing basics as early as possible, means that you don't have to think about little things when you move on to more complex subjects. You spent a long time practicing addition before anybody even told you about the concept of multiplication.
I think the simplicity and limitations of computers at the time had a lot to do with them being accessible to a second grader.
So if you don't come into it already knowing how to think, you will be written off as "not technical type" or some such. And you will write yourself off too.
Pointers don't matter at all. Loops and ifs matter a lot.
It's a shame that his vision of tech education isn't shared by hardware manufacturers. There was the OLPC project, which didn't seem to gain much traction. The iPad could easily fulfill this role, yet the OS still limits the device to media consumption and any programming on it is cumbersome. There's an iPad Scratch app that might be worth a try: https://apps.apple.com/us/app/scratchjr/id895485086
Why be US-centric?
> Things like using a cursor in a multi-line text input are not natural for kids in early grades
Sure it is. In past decades, many children start working their family computer at ages 6-10. Maybe they started with games like Space Invaders or Digger or Xonix, but soon enough they were editing text files.
> it is just really boring to struggle with syntax and typing
Yeah, so let's not teach children to express themselves in writing... that stuff is boring.
I would still lean on one of the modern Logo's to learn kids or non-technical people to program, such as MSWLogo or NetLogo (I used to teach programming to people from Social Sciences using Netlogo).
It says something that Python has grown so complex as to need a new intro version.
This might seem a little far afield, but I've been playing a lot of Baba Is You lately. For a game that's all about rewriting rules, a lot of logic is completely arbitrary. Why does "Stop" take precedence over "Defeat", and why does "Rock is Rock" take precedence over "Rock is Water"? In the end, it doesn't matter, because the game is consistent, so you learn the rules once and can rely on that behavior.
(I'm blindly assuming that it was named after her, haven't checked)
