40 • Live as in Alive
I have a swirl of feelings and this is the only way I know to express them.
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 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 bu...
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 very careful about speaking with undue certainty. I like to say that something *will* happen, when ...
• Glamorous Toolkit's One Rendering Tree: https://medium.com/feenk/one-rendering-tree-918eae49bcff • Natto: https://natto.dev
Why not just make all data points take the same amount of time to convey along every path?
My blog post about different approaches to rewind: https://ivanish.ca/hest/time-travel Enso: https://enso.org Places to contact me with feedback: https://ivanish.ca#contact
Caution: This episode may qualify as ASMR content. It might also qualify as irritating, sophmoric philosophizing. But as the previous few episodes have run aground on the muddy bank of the design space, I'm marking the occasion by establishing firmly that WHILST PERFECT IS NOT THE POINT, NOR IS GOOD. And now that that's out of my system, we're going to (in the upcoming episodes) jump back to the center and venture outward along an entirely new axis. Though that Ira Glass quote is fucking fire, h...
Each part of the whole can have different philosophies.