Comment by _pmf_ | Hacker News Reader

Comment by _pmf_ | Hacker News Reader

Parent Full thread

There are visual languages that basically do "functions as boxes", lines as calls". These are useless.

There are visual languages that look the same as above, but lines are actually dataflow instead of function calls / control flow and the boxes are not opaque functions but introspectable data flow descriptions themselves. These offer some unique benefits, like transitive optimization and code elimination, that operate at a higher level than even full program optimization can achieve. (The latter being Simulink, for example.)

Then there are state charts (which are the big cousin of cumbersome non-hierarchical state diagrams as most people know them). These are, to me, practically a silver bullet regarding real-time systems. I went into automotive software development being very skeptical of Stateflow (coming from a classic C and Java background), but it has transformed the way I work with real time systems (even if not using it). It requires a huge upfront investment in analysis and thinking things through very thoroughly, which is why it is not particularly suited for systems with very volatile requirements, but it leaves you basically at state "done" after the design phase.

That's an interesting observation, in that games are often real-time systems. Makes sense to me as I work in audio DSP where you've got to have your buffer processed in time or you wreck the hapless user's mix.

Where do you see Godot relative to this? I know I was interested in Unreal Engine's blueprints, but unconvinced (also, I was working with my coder brother, who hated blueprints on sight). I've also been exploring the open synth hardware Axoloti, which likewise uses a node-based system for its design.

Godot 3 actually has some built in DSP effects and send buses: https://godotengine.org/article/godot-30-new-internals-progr...

Regarding visual editing, those tools are of direct interest to any signal processing work(which for games means audio, visual effects, and in some cases asset dependency resolution). They don't work well once your task is too fine-grained. Graphs of finite state are also extremely useful for game AI and concurrently scripted logic, so tools that formalize those concepts and give them visual UI are also commonplace.

In audio work, a FSM is a good starting place to conceptualize processes like key state tracking and envelope triggers. Games have more shifting requirements so the design process of the FSM is given much more emphasis.

Welp, now I'll HAVE to choose MIT when my own opensourcing gets underway. They say they didn't have much audio DSP code under MIT license they could use. I was leaning to MIT anyhow, but if they need specifically that…

> There are visual languages that look the same as above, but lines are actually dataflow instead of function calls / control flow and the boxes are not opaque functions but introspectable data flow descriptions themselves. These offer some unique benefits...

I've only had a brief (few months) experience with Max/MSP, although I've played around with other visual languages too (SynthMaker and others) and have been interested in the topic of both visual and dataflow languages for a long time. So, with that bit of context, I completely agree with your observation!

Reply on news.ycombinator.com