MicroBlocks: Scratch and Smalltalk-inspired MCU VM for live embedded programming

When you start working directly with kids watching them use programming environments, though, it's often amazing how quickly things like the details of parallelism, events, sequencing, start having an impact on programs and making simple things feel 'broken'. I can quite imagine that when trying to achieve specific goals in education, the details and semantics of a language can get you into trouble. Sometimes in order to ensure kids don't get frustrated early, it's necessary to pare back some of the complexity until their understanding of computing is developed enough to bring complexity back... (have a look at https://makecode.microbit.org/device/reactive as an example of how MakeCode deals with this on the micro:bit).

Another example that comes to mind on this topic is https://stride-lang.net/ - this is very Java-derived, but as I understand it form their publications, the changes away from Java were necessary in order to allow some of the graphical/scaffolding features to work well without entering an 'uncanny valley'.

Hopefully some of the MicroBlocks team will also chime in on this though!

You might want to read Mark Guzdial's blog for more on that:

> What makes GP remarkable is that it aims to be a general purpose language. John’s vision for GP is to be the language that students might move to after Scratch, with the highest possible ceilings. Think about GP as Python or Smalltalk in blocks — and even more the latter than the former. From the virtual machine (VM) on which it runs to the class browser, GP feels like a blocks-based form of Smalltalk. Because GP is VM-based, it’s portable — there are versions for Mac, Windows, iOS, and even a JavaScript implementation of the VM so that GP runs in the browser.

– https://computinged.wordpress.com/2016/06/13/introducing-gp-...

[1] http://developers.google.com/blockly

https://www.microsoft.com/en-us/makecode

https://github.com/microsoft/pxt

Practically speaking, the alternatives are invent your own language or boil the ocean reverse engineering the behavior of an implementation. And boiling the ocean is a constant effort because implementation based "standards" tend to change without a formal consensus process.

Since you mention Lisp and Python, these illustrate the difference. Common Lisp has a consensus standard. So does Scheme. Python does not have a consensus standard. A consensus standard process might have made the adoption of Python 3 less painful.