Scratch 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.

> 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.

Thats not relevant to the point. And even smalltalk wouldn't allow this, without reflection, since method handles aren't really first class objects.

It 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.

> homoiconic

I don't think it means what you think it means.

It'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.