Hacker News new | ask | show | jobs
by themodelplumber 1035 days ago
That's pretty fun to think about. I'd love to see node/graph operations in general become more commonplace and standardized.

Unfortunately, I think my node/graph dopamine pathways have been forever altered by node/graph QoL[1] issues that, while native to, and applicable to, every node/graph design system, almost never seem to be addressed before they become gigantic workflow speedbumps. And when they are addressed, they are still, in 2023, treated as awesome new features.

I think an applicable comparison might be e.g. a programming environment which locks you into its own text editor, and while initially excited by the language features, you soon find that the text editor doesn't support copy/paste, let alone duplicate-line, or any other fancy stuff that's really no longer fancy.

Still, I'd be interested to learn about other similar languages, in the case that FMJ might no longer be under development...

1. https://info.e-onsoftware.com/vue/new_features (just an example in there)

1 comments

In principle, one can go back and forth between a visual node/graph dataflow representation and a textual expression-oriented dataflow representation. From an expression (better yet, an expression with either where clauses or labelled subexpressions) to the node/graph is pretty clear. The opposite direction is not as obvious, but still easy (cf Knuth Vol.4)

Once upon a time I had thought it might be worthwhile to use this correspondence to automatically structure definitions for human consumption, but currently I believe practicing programmers prefer to work with "definition soup" ...and leave the structuring to their optimising compilers.

> go back and forth between a visual node/graph dataflow representation and a textual expression-oriented dataflow representation

Fascinating! I would LOVE to see that done well. (QoL PTSD adding the "well" in there for me. Haha)