Despite the criticism in the older HN thread, I actually found this talk pretty compelling. In particular, the idea that you start with a language level that is missing capabilities so that you directly experience the problem and then understand the motivation for the additional complexity of the next level.
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.
Felienne Hermans, who seems to be leading this research effort, is also writing "The Programmer's Brain". It has a sort-of "early access" version that I've been reading as chapters have been coming out. From what I've read so far she has been doing her homework in terms of what science really knows about learning, memory and so on. What I really appreciate is that she also looks outside of the field of programming for answers to questions surrounding how learning and thinking "works".
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).
I long for the day when Manning runs out of those terrible, unrelated genetic portraits for their cover art. There is nothing I associate less with new technology and software than pictures of people from antiquity.
the idea that you start with a language level that is missing capabilities so that you directly experience the problem and then understand the motivation for the additional complexity of the next level.
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.
This is commonly referred to as a "rationale" document. It exists for some languages, but not all, and helps to establish both why something has been done and why something else has not.
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).
I pretty much never use Python. I've false started on getting into it a couple times, but never quite got enough fun or dollars out of it to stick with it.
That said, whenever an interesting or controversial PEP starts making the rounds in forums like this one, I almost always wind up reading the whole thing on account of how well thought-out they are.
I try to do something this when I'm teaching classes. Do the "why should I listen to this? What's it going to get me?" bit right at the start.
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.
Last time I tried introduction to programming classes I introduced concepts in the following order: variables (store results!), if-else (actually get interesting results!), then arrays (lists of variables!), for-loops (iterate over your lists!), which seemed to make sense.
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.
She's talking about delaying the fundamental concept of a function, and using the absence of the function syntax in order to motivate the need for it.
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.
Your first paragraph is exactly why Lua is so good for beginners. You want arrays? Implement them. You want classes? Implement them! On the other hand, the one built-in data structure is powerful and can do a lot without implementing these other things.
Python is just for playing with strings, which is a contrived problem brought about by UNIX-style OS. And other confusing non-fundamental, stuff that just leads to months of cognitive dissonance when one inevitably philosophizes over it: objects, classes, exceptions, the ability to modify global variables from other modules, metaclasses, etc.
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.
Comments
Despite the criticism in the older HN thread, I actually found this talk pretty compelling. In particular, the idea that you start with a language level that is missing capabilities so that you directly experience the problem and then understand the motivation for the additional complexity of the next level.
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.
Felienne Hermans, who seems to be leading this research effort, is also writing "The Programmer's Brain". It has a sort-of "early access" version that I've been reading as chapters have been coming out. From what I've read so far she has been doing her homework in terms of what science really knows about learning, memory and so on. What I really appreciate is that she also looks outside of the field of programming for answers to questions surrounding how learning and thinking "works".
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).
https://www.manning.com/books/the-programmers-brain
I long for the day when Manning runs out of those terrible, unrelated genetic portraits for their cover art. There is nothing I associate less with new technology and software than pictures of people from antiquity.
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.
This is commonly referred to as a "rationale" document. It exists for some languages, but not all, and helps to establish both why something has been done and why something else has not.
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).
Python Enhancement Proposals (PEPs) are very good at this in my opinion.
I pretty much never use Python. I've false started on getting into it a couple times, but never quite got enough fun or dollars out of it to stick with it.
That said, whenever an interesting or controversial PEP starts making the rounds in forums like this one, I almost always wind up reading the whole thing on account of how well thought-out they are.
I try to do something this when I'm teaching classes. Do the "why should I listen to this? What's it going to get me?" bit right at the start.
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.
Last time I tried introduction to programming classes I introduced concepts in the following order: variables (store results!), if-else (actually get interesting results!), then arrays (lists of variables!), for-loops (iterate over your lists!), which seemed to make sense.
Do you have any more suggestions?
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.
She's talking about delaying the fundamental concept of a function, and using the absence of the function syntax in order to motivate the need for it.
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.
Beginners typically use "print" before they know what a function is.
Your first paragraph is exactly why Lua is so good for beginners. You want arrays? Implement them. You want classes? Implement them! On the other hand, the one built-in data structure is powerful and can do a lot without implementing these other things.
Python is just for playing with strings, which is a contrived problem brought about by UNIX-style OS. And other confusing non-fundamental, stuff that just leads to months of cognitive dissonance when one inevitably philosophizes over it: objects, classes, exceptions, the ability to modify global variables from other modules, metaclasses, etc.
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.
Tell me brother, tell me the thoughts on the outside of this San Franciscan echo chamber.