Hest

I have a swirl of feelings and this is the only way I know to express them.

The story behind one of my songs, tracing its roots back through several failed career changes, through my life slowing to a crawl, how I got serious about programming, the damage it's done to me, and a recurring idea that informed Hest and, well, so many other things. Note that there's nothing new to learn about Hest here. This one is just a story.

This year in Hest: Amb Bi Omni d.ts & Switch

As promised at the end of the previous episode, this one breaks the format a little. Granted, if this is going to be a once-a-year affair, I think it's reasonable to have a bit of fun with it, mmm?

Seven months of inking and switching later, a novel saw has been seen by all. In what interesting ways does said saw differ from Hest? In what ways are they similar? What even is Hest anymore? Listen on, Macduff.

I'm going to change the format of this show, for the next few months at least if not longer. We'll see! But stick around. There'll be more to come. I think. Probably! Maybe. Wait, where are you going? Aww beans.

I'm not trying to invent a new genre, I'm just trying to be the Estradasphere of visual programming.

Why do all programming tools look so similar?

If I'm not able to build Hest as it's currently conceived, what will it end up looking like? What gets cut, what gets saved — and in what order?

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...

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 • hest@ivy.boo 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 c...

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?

Point, dot, position? Edge, wire, path? And, whence Hest?

Issues with floats, Conal Elliott's FRP, 3:2 Pulldown, quantization, keeping things consistent whether running at "full speed" or in super slow motion.

Yes, I know it's pronounced "bez-ee-ay" not "bez-ee-er" but old habits die hard.

In detail, here's how Hest's evaluator advances the simulation state. This episode covers the simple parts. Next week, we'll look at the emergent chaotic bits.

Most games, and game-like software, use a constantly-running main loop to handle input, update their internal state, and produce an ever-changing result for the user. With Hest I'm taking a different approach, designed to reduce the idle power consumption to a minimum.

Zdog: https://zzz.dog Also — looking back on this episode after the fact (a few weeks after recording it, having spend the past few weeks thinking more about rendering), my thoughts on what would make for the best approach have changed. I'm already trying a new prototype with a different approach. This should serve as a reminder to myself (and such constant reminders are needed) that I ought to be...