5 ms·
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 l
by 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 agoI 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 agoMaybe 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 agoYou 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 agoIt should be noted for younger generations that ESP32 is more powerful than typical 16 bit computers we used for MS-DOS.
- CyberDildonics 6y agoOr 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 agoMicroBlocks 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 agoBlockly [1] works with "real" languages. [1] http://developers.google.com/blockly http://developers.google.com/blockly
- pjmlp 6y agoMicrosoft'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 agoMany "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.