Hest

Marcin Ignac asked me the following on Twitter:

"We are actually starting to think of abstractions/groups/sub-graphs in Nodes just now. Would you have any pointers to environments doing it well or wishes for a better way of doing it?"

Yep, I've got wishes.

Speaking of Marcin's Nodes project, this is essential reading: https://nodes.io/story/

Every visual programming language should have that depth of thought put into it, and should share that thinking out loud. Beautiful stuff.

Similar to the one about SpaceChem, this episode looks at another piece of prior art I'm drawing on for the design of Hest: the Live Schematic simulations built by my company, which are so much like a "Future of Technical Documentation" tool that it seems obvious to me that we need something similar for software development.

The only thing easier than making better tools for working with wires… is insisting that it'd be easy to make better tools for working with wires.

Listener question: What's the current plan for functions in Hest?

How ideas solidify as you think about them.

• A strange kind of not invented here.

• "Easy to reason about" — quarter in the swear jar.

Listener questions? Send 'um in!

• @spiralganglion

• [email protected]

Hest's data model is simple, very simple, but not so simple as to avoid a digression into AoS vs SoA. Properties are our springboard into the main topic: what is to be done about the interface? A sidebar is a recipe for spooky action, and I don't like spooky action, and I definitely don't like meat.

I have an idea for a feature called "accelerator functions", which are functions that define behaviour both within Hest itself and within the underlying runtime Hest sits atop (JavaScript, maybe someday "et al" too). Accelerators give you a way to write some heavily-constrained code that can run extra fast (directly against JS), but that can still be viewed and debugged as full-on Hest graphical code (which normally has a ton of overhead). This episode only discusses the feature in brief. The bulk of the episode uses accelerator functions as a lens to examine Hest's approach to static type checking, correctness guarantees, and the footguns you run into in their absence.

Speculating on nice affordances for programmers to hook into Hest's editor features.

Should nice, fun, playful tools and capabilities be built directly in the editor now? Or should those things be held back, waiting until the language model is robust enough to build them within it?