6 ms·

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

83 points by jarmitage 6y ago

dTal 6y ago
Disclaimer: I do not intend the following as a criticism. Can somebody explain why these Scratch-like GUI programming efforts always seem to invent their own language? Why not build ASTs of a "real language" with such a system, and take advantage of its ecosystem? Is there some reason why implementing drag-and-drop blocks is, at the very least, synergistic with building an entirely new VM? It seems to me that you should be able to build Lisp or Python very easily, and hence bridge the gap to "real programming".
- jaustin 6y ago
  I think there's room for both worlds. People have certainly done as you describe - just picking examples from the micro:bit ecosystem that I know well - Microsoft MakeCode is an example of something that takes a "block" world and maps to either JavaScript or Python. https://www.microsoft.com/en-us/makecode https://www.microsoft.com/en-us/makecode or as an example http://makecode.microbit.org/ http://makecode.microbit.org/. Edublocks does similar for Python (or specifically MicroPython) https://edublocks.org/ https://edublocks.org/. 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 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/ 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!
- mike_ivanov 6y ago
  Maybe because the VM needs to run on rather limited hardware, not capable of running any of those "real" languages -- that might be the reasoning behind it. On the other hand, ESP32 and similar boards can run not only Lua and JavaScript, but even ClojureScript, so it depends on where you draw the line.
  - monocasa 6y ago
    You can run those language on very small devices. MicroPython works great on the micro:bit for instance, which only has 16k of RAM. An Arduino might be pushing it though with 2k of RAM. Lisp was originally run on a system that had 4K 36bit words of memory for RAM, but no ROM (the IBM 704). There's a pretty long history of virtual machines on small memory systems, going back to the days of BASIC and SWEET16. They can actually make better use of memory in some cases, with the VM byte code sort of being a compression technique versus native code. https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16
  - pjmlp 6y ago
    It should be noted for younger generations that ESP32 is more powerful than typical 16 bit computers we used for MS-DOS.
- CyberDildonics 6y ago
  Or lua, or C. I think if you want to make the individual expressions be built out of blocks you need a lot of control and introspection of every atomic element of a language, but that doesn't seem impossible to me for a simple language. I agree that many times visual programming is hindered by not trying to exist in a real world ecosystem.
- jarmitage 6y ago
  MicroBlocks is based on the GP language: http://gpblocks.org/ http://gpblocks.org/ 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-a-general-purpose-block-language/ https://computinged.wordpress.com/2016/06/13/introducing-gp-...
- rjsw 6y ago
  Blockly [1] works with "real" languages. [1] http://developers.google.com/blockly http://developers.google.com/blockly
- pjmlp 6y ago
  Microsoft's MakeCode uses a subset of TypeScript with support for AOT compilation via transpilation to C++ as intermediate step. https://www.microsoft.com/en-us/makecode https://www.microsoft.com/en-us/makecode https://github.com/microsoft/pxt https://github.com/microsoft/pxt
- brudgers 6y ago
  Many "real languages" don't have a formal specification, just an implementation...or rather implementations. Scratch is one. Squeak on which it was based is another. It's only down at Smalltalk which inspired Squeak that there's a standard (ANSI 1988). 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.
jarmitage 6y ago
Make Zine article: https://makezine.com/2020/07/31/microcontrollers-meet-microblocks/ https://makezine.com/2020/07/31/microcontrollers-meet-microb... Podcast: https://kidslab.dev/2020/08/03/microblocks-with-bernat-romagosa/ https://kidslab.dev/2020/08/03/microblocks-with-bernat-romag... May 2020 keynote from John Maloney: https://www.youtube.com/watch?v=Iq4fOv64CfQ https://www.youtube.com/watch?v=Iq4fOv64CfQ
bromagosa 6y ago
Glad to see MicroBlocks on the front page of HN! I'm one of the project devs. Feel free to AMA :)
- thomasqbrady 6y ago
  Something that seems to always be missing from project pages like this: why? There are plenty of other similar projects that accomplish this, and in the case of the microbit, I can’t even tell the difference between your IDE and the one that comes with it. I don’t mean this in a critical way–I literally mean, “tell me why you. Hilt this. What’s better or at least different about your project? Why might I want to use this instead of the others?”
  - bromagosa 6y ago
    Actually, there are no similar projects that I can tell of. MakeCode, the "one that comes with the micro:bit", as you say, is not a live language and only works for a couple of boards. It's not even a language, it's a façade for an underlying text language. To sum up what's different about MicroBlocks: * It is blocks based. * It is live. That means you can change scripts in real time while they're running. You can see the result of running any block in real time. You don't have to wait for any compilation/upload cycles. * It is autonomous. You can disconnect the board at any point, and the program will keep running in it. * It is parallel. You can run multiple tasks at the same time. * It is portable. It runs in several boards thanks to our VM approach. There was no language that did all these, so we made our own :)
    - thomasqbrady 6y ago
      "Similar" in terms of the job-to-be-done I had in mind—a Scratch-like interface for programming most if not all of the boards mentioned. These features you've outlined did not jump out at me at all on first glance, which is a shame! I somehow totally missed the live aspect. That's super exciting (and impressive). And parallel!?!? A WYSIWYG parallel code editor for microcontrollers? How is that not the headline? I'm glad I asked! This is quite interesting to me now. Thanks for your reply!
chriswarbo 6y ago
Very nice. Reminds me of Physical EToys https://en.wikipedia.org/wiki/Physical_Etoys https://en.wikipedia.org/wiki/Physical_Etoys
vmchale 6y ago
born to click

83 points by jarmitage 6y ago

dTal 6y ago

Disclaimer: I do not intend the following as a criticism. Can somebody explain why these Scratch-like GUI programming efforts always seem to invent their own language? Why not build ASTs of a "real language" with such a system, and take advantage of its ecosystem? Is there some reason why implementing drag-and-drop blocks is, at the very least, synergistic with building an entirely new VM? It seems to me that you should be able to build Lisp or Python very easily, and hence bridge the gap to "real programming".

jaustin 6y ago
I think there's room for both worlds. People have certainly done as you describe - just picking examples from the micro:bit ecosystem that I know well - Microsoft MakeCode is an example of something that takes a "block" world and maps to either JavaScript or Python. https://www.microsoft.com/en-us/makecode https://www.microsoft.com/en-us/makecode or as an example http://makecode.microbit.org/ http://makecode.microbit.org/. Edublocks does similar for Python (or specifically MicroPython) https://edublocks.org/ https://edublocks.org/. 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 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/ 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!
mike_ivanov 6y ago
Maybe because the VM needs to run on rather limited hardware, not capable of running any of those "real" languages -- that might be the reasoning behind it. On the other hand, ESP32 and similar boards can run not only Lua and JavaScript, but even ClojureScript, so it depends on where you draw the line.
- monocasa 6y ago
  You can run those language on very small devices. MicroPython works great on the micro:bit for instance, which only has 16k of RAM. An Arduino might be pushing it though with 2k of RAM. Lisp was originally run on a system that had 4K 36bit words of memory for RAM, but no ROM (the IBM 704). There's a pretty long history of virtual machines on small memory systems, going back to the days of BASIC and SWEET16. They can actually make better use of memory in some cases, with the VM byte code sort of being a compression technique versus native code. https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16
- pjmlp 6y ago
  It should be noted for younger generations that ESP32 is more powerful than typical 16 bit computers we used for MS-DOS.
CyberDildonics 6y ago
Or lua, or C. I think if you want to make the individual expressions be built out of blocks you need a lot of control and introspection of every atomic element of a language, but that doesn't seem impossible to me for a simple language. I agree that many times visual programming is hindered by not trying to exist in a real world ecosystem.
jarmitage 6y ago
MicroBlocks is based on the GP language: http://gpblocks.org/ http://gpblocks.org/ 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-a-general-purpose-block-language/ https://computinged.wordpress.com/2016/06/13/introducing-gp-...
rjsw 6y ago
Blockly [1] works with "real" languages. [1] http://developers.google.com/blockly http://developers.google.com/blockly
pjmlp 6y ago
Microsoft's MakeCode uses a subset of TypeScript with support for AOT compilation via transpilation to C++ as intermediate step. https://www.microsoft.com/en-us/makecode https://www.microsoft.com/en-us/makecode https://github.com/microsoft/pxt https://github.com/microsoft/pxt
brudgers 6y ago
Many "real languages" don't have a formal specification, just an implementation...or rather implementations. Scratch is one. Squeak on which it was based is another. It's only down at Smalltalk which inspired Squeak that there's a standard (ANSI 1988). 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.

jarmitage 6y ago

Make Zine article: https://makezine.com/2020/07/31/microcontrollers-meet-microblocks/ https://makezine.com/2020/07/31/microcontrollers-meet-microb... Podcast: https://kidslab.dev/2020/08/03/microblocks-with-bernat-romagosa/ https://kidslab.dev/2020/08/03/microblocks-with-bernat-romag... May 2020 keynote from John Maloney: https://www.youtube.com/watch?v=Iq4fOv64CfQ https://www.youtube.com/watch?v=Iq4fOv64CfQ

bromagosa 6y ago

Glad to see MicroBlocks on the front page of HN! I'm one of the project devs. Feel free to AMA :)

thomasqbrady 6y ago
Something that seems to always be missing from project pages like this: why? There are plenty of other similar projects that accomplish this, and in the case of the microbit, I can’t even tell the difference between your IDE and the one that comes with it. I don’t mean this in a critical way–I literally mean, “tell me why you. Hilt this. What’s better or at least different about your project? Why might I want to use this instead of the others?”
- bromagosa 6y ago
  Actually, there are no similar projects that I can tell of. MakeCode, the "one that comes with the micro:bit", as you say, is not a live language and only works for a couple of boards. It's not even a language, it's a façade for an underlying text language. To sum up what's different about MicroBlocks: * It is blocks based. * It is live. That means you can change scripts in real time while they're running. You can see the result of running any block in real time. You don't have to wait for any compilation/upload cycles. * It is autonomous. You can disconnect the board at any point, and the program will keep running in it. * It is parallel. You can run multiple tasks at the same time. * It is portable. It runs in several boards thanks to our VM approach. There was no language that did all these, so we made our own :)
  - thomasqbrady 6y ago
    "Similar" in terms of the job-to-be-done I had in mind—a Scratch-like interface for programming most if not all of the boards mentioned. These features you've outlined did not jump out at me at all on first glance, which is a shame! I somehow totally missed the live aspect. That's super exciting (and impressive). And parallel!?!? A WYSIWYG parallel code editor for microcontrollers? How is that not the headline? I'm glad I asked! This is quite interesting to me now. Thanks for your reply!

chriswarbo 6y ago

Very nice. Reminds me of Physical EToys https://en.wikipedia.org/wiki/Physical_Etoys https://en.wikipedia.org/wiki/Physical_Etoys

vmchale 6y ago

born to click