I'm a huge fan of Logo! I wrote a Logo Adventure for Terrapin Logo that they shipped on the C64, the point of which was to show off Logo's list processing and functional features, because most of the other examples were focused on turtle graphics. So I appreciate what you say about teaching the functional and abstract parts of Logo, as well as the procedural and graphical parts like turtle graphics.

https://donhopkins.medium.com/logo-adventure-for-c64-terrapi...

Blockly is actually a JavaScript library for rolling your own visual blocks based visual programming languages, from Google. They use it for App Inventor, but that's not all it's used for. It's not one particular language or execution model, but different applications can interpret or compile it into JavaScript or even shaders or WebAssembly.

Here's a wonderful example of a "Falling Sand Game" called "Sandspiel Studio" that uses Blockley for a specialized cellular automata oriented visual programming language, that let you define and play with your own sand/air/water/lava/seed/stem/leaf/flower/whatever particles:

https://studio.sandspiel.club/

Making Sandspiel HN Discussion (Max Bittker):

https://news.ycombinator.com/item?id=34555913

https://news.ycombinator.com/item?id=34561910

https://maxbittker.com/making-sandspiel

Making Alien Elements (with Todepond):

https://www.youtube.com/watch?v=48-9jjndb2k

The point that Sandspiel Studio so beautifully illustrates and Blockley so practically addresses is that there are many possible domains, execution models, data models, vocabularies, and user interfaces for visual programming languages: there is no universal VPL that's good for everything, but they're great for many different domains, so you need powerful flexible tools for rolling your own special purpose VPLs.

That's also why Blender supports generic "nodes" you can subclass and customize into all kinds of different domains like shader programing, 2d image composition, 3d content generation, animation, constraints, etc. There are third party and built-in Blender plug-ins that customize nodes into specialized visual languages for generating maps and cities, particle systems, and all kinds of other specialized uses.

Everything Nodes UX #67088:

https://projects.blender.org/blender/blender/issues/67088

Function & Particle Nodes:

https://wiki.blender.org/wiki/Source/Nodes

So Blockley and Blender Nodes are the visual equivalent of "yacc", for defining custom visual programming languages.

I'm also a huge fan of Snap!, which has all the advantages of Logo (Lisp without parenthesis) and Scratch / eToys / Squeak / App Inventor family of block based visual programming languages, but all the power of Scheme.

If you know Scheme, then it's easy to think about Snap!: it's just Scheme with a visual block syntax, but with some functions renamed to make them easier to learn, plus all the stage and turtle graphics stuff from Scratch, running in a web browser!

I didn't realize until watching in amazement as Jens Mönig used his own creation, that it also has full keyboard support, so you can create and edit programs without using the mouse!

It's much easier to teach Scheme to kids by teaching them Snap!, because the user interface is so much better than a text editor.

I attended Snap!Con2023 in Barcelona recently, and we discussed some interesting possible extensions to Snap:

Grammar defining blocks. Right now you can create your own custom vocabularies of blocks that fit together in particular constrained ways, by writing JavaScript Snap! extensions. Develop a set of blocks for visually defining new grammars and vocabularies of custom parameterizable blocks.

For example, a grammar for representing plants with seeds, roots, stems, leaves, flowers, petals, etc. You can assemble and edit them manually by dragging and dropping from a palette, or write programs that generated and interpret and transform them, and pass them around as data, for example as instructions to the embroidery machine to sew, or logo turtle to draw.

Turtlestitch - Coded Embroidery:

https://www.turtlestitch.org/page/about

Ken Kahn led a discussion about integrating LLMs like ChatGPT with Snap!. He's the developer of eCraft2Learn for teaching kids AI programming. Ken recently made some cool Snap! extensions for integrating LLMs with the speech synthesis and recognition system, and orchestrating conversations between different characters.

Snap!Con2023: Creative uses of Snap! blocks using large language models like GPT:

https://www.youtube.com/watch?v=d2rNGsbzkXI

Enabling children and beginning programmers to build AI programs:

https://ecraft2learn.github.io/ai/

But when it comes to LLMs, code generation, and code understanding, JavaScript has two huge insurmountable advantages over Snap! or any other block based visual programming languages:

1) First of all it's extremely well known, by both humans and LLMs.

2) And second of all, there's typically no efficient and faithful way to textually represent block based programs in a way that ChatGPT (or humans) can easily understand and generate.

Of course you could just dump out the XML or JSON save file, but that wastes your token budget, and doesn't work well, because the LLM doesn't inherently understand the syntax and semantics of save files the way it deeply groks JavaScript.

You need to define some equivalent text based language to serialize and deserialize your visual programs, or define some equivalency to an existing language, so you can translate back and forth without loss.

Like Relax/NG has an XML syntax and also a simple concise human readable syntax, both which can express the same things.

But no matter what equivalent language you come up with to serialize your block programs into, it'll never be as well known as JavaScript (unless it IS JavaScript).

I think Snap! could take advantage of its equivalency with Scheme, and you could just parse Scheme into Snap! blocks, and the other way around. And ChatGPT knows scheme pretty well, though it's not as ubiquitous and standard as JavaScript.

Logo would not be as good as Scheme, since it has ambiguities, because you need to know the number of parameters a function uses in order to parse it, since it's essentially Lisp without parens.

Back in 1989 I designed a visual PostScript programming and debugging interface for NeWS, that took the approach of not trying to change or redefine the PostScript language, just to present a visual directly manipulatable interface to what it actually was.

PSIBER Space Deck Demo:

https://www.youtube.com/watch?v=iuC_DDgQmsM

PSIBER Space Deck and Pseudo Scientific Visualizer Demo

https://www.youtube.com/watch?v=_fqCeuue5Ac

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989

https://donhopkins.medium.com/the-shape-of-psiber-space-octo...

>Abstract: The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS. [...]

>There is a text window onto a NeWS process, a PostScript interpreter with which you can interact (as with an “executive"). PostScript is a stack based language, so the window has a spike sticking up out of it, representing the process's operand stack. Objects on the process's stack are displayed in windows with their tabs pinned on the spike. (See figure 1) You can feed PostScript expressions to the interpreter by typing them with the keyboard, or pointing and clicking at them with the mouse, and the stack display will be dynamically updated to show the results.

>Not only can you examine and manipulate the objects on the stack, but you can also manipulate the stack directly with the mouse. You can drag the objects up and down the spike to change their order on the stack, and drag them on and off the spike to push and pop them; you can take objects off the spike and set them aside to refer to later, or close them into icons so they don’t take up as much screen space.

>NeWS processes running in the same window server can be debugged using the existing NeWS debug commands in harmony with the graphical stack and object display.

>The PSIBER Space Deck can be used as a hands on way to learn about programming in PostScript and NeWS. You can try out examples from cookbooks and manuals, and explore and enrich your understanding of the environment with the help of the interactive data structure display.

I like the way Kodable takes a similar approach of making an easy to use visual user interface to an existing, well defined, universal general purpose language, instead of trying to invent and teach something weird that nobody else uses and students will never see again.

Not to the exclusion of other block languages like Snap! and Blender nodes -- they all have their uses. Snap! is implemented in JavaScript, and lets you call JavaScript functions and integrate libraries with it, like eCraft2Learn.

There's a certain honesty and practical utility about starting simple but working your way towards an actual programming language that kids will encounter in the real world.

Of course I'm disappointed that language isn't PostScript, Lisp, Scheme, Logo, or ScriptX, but JavaScript won the popularity contest, and that's the world we live in.

Despite all its tragic flaws and questionable orientations, I think JavaScript is really a great language to teach kids early on. It's not going away, and it's not purely functional or object oriented, and there's nothing that comes close to it in terms of universality and LLM friendliness.