4 ms·
While I agree to the use case / tiny arguments, it doesn't seem to work in practice. I am now using Scratch (https://scratch.mit.edu/ https://scratch.mit.edu/)
by patrickg 11y ago
While I agree to the use case / tiny arguments, it doesn't seem to work in practice. I am now using Scratch (https://scratch.mit.edu/ https://scratch.mit.edu/) to teach programming. Much better.
- j-pb 11y agoScratch has the advantage of making the limitations of the computer tangible. The block nature will show you what can be done and what can't. For example, newbies in procedural languages often try things like if(something){loop = while} else {loop=if} loop{print("hi")} and it's not immediately obvious why that isn't valid in text, while in scratch it is. I don't think its the language though that makes things easier.
- lmm 11y ago> if(something){loop = while} else {loop=if} loop{print("hi")} The only reason that wouldn't work is bad language design. In e.g. Smalltalk or TCL it's fine.
- j-pb 11y agoThats not relevant to the point. And even smalltalk wouldn't allow this, without reflection, since method handles aren't really first class objects.
- lmm 11y agoIt is exactly the point: the problem is real, but you don't have to throw the baby out with the bathwater. Instead you can use a simple, homoiconic, but still very "real" programming language for teaching.
- j-pb 11y ago> homoiconic I don't think it means what you think it means.
- lmm 11y agoIt's not strictly what I mean, but in practice there's a close correlation; homoiconic languages naturally lend themselves to metaprogramming and so it's more normal to implement e.g. control flow as ordinary functions in the language (where they might be dedicated syntax in other languages). But yes, I really mean a low-syntax language, and they're not all homoiconic.