|
Yeah, this is a really tricky space to delve into because the people who are most familiar with it are working on mathematical models and have very strong opinions about the "kind" of graph you're making, or what you're actually doing with the underlying data. Which is all definitely important for a node library maker to know, but the whole purpose of the library is that an implementing dev shouldn't have to know any of that stuff. So you really have to dig through a lot of irrelevant stuff about graph theory and whatnot to get to any relevant programming knowledge on the topic. What's galling to me is that nodes map 1-1 to function calls. I can't even think of a scenario where a program that can be written as functions and objects couldn't be represented as a node graph. I can certainly shudder at the horrific types of graphs most programs would make, but they can all be mapped out. And, on the flip side, every single program I've written in visual scripting could easily be written as functions and objects. So, with that in mind, it's frustrating to go looking for information about node graphs and getting a bunch of muck about why they're 'not good', and why they don't handle certain things well, and why they aren't suited for x or y, when - in my head - I'm literally just asking for a well-formed API, and I'm getting a bunch of pushback about how APIs aren't really a good way to program. -_- But because it's so hard to get good comparative information on visual scripting, I've also wrestled with what makes for good abstractions vs what is too broad. And that's what I think the Node Red stuff is: just too broad. Abstracting away everything breaks the value of the abstraction. So it's always about finding a balance, which is why I appreciate Epic's maintenance of Blueprints. A good API abstracts concepts you don't need to understand behind concepts you already understand. "GetDistance()" is a great abstraction because I don't care about the vector math underneath. But "Login()" is a terrible abstraction because a library shouldn't have the intimate details of my login process (meaning that it should be abstracted into more modular parts that I can more easily inject my business logic/keys into). So a node, or a library of nodes, or a node library system - they're all only as good as their abstractions. And Node Red is just way too abstracted to be "good". And, of course, the irony there is that if it were only a little more flexible, it could even be abstracted, itself, into something more use-able! If you could write a node that DID accept two inputs, you could abstract away all of the setting and swapping and trading. But since even that node could only ever be kick started by a single node, you would have to come up with some kind of hacky scheme to make any kind of utility actually function. So it's the one type of abstraction that they don't allow (their node model) which I find to be fundamental to successful visual scripting languages. Honestly, though, I think there are some fundamental designs that visual scripting languages just need to implement, but I have a very hard time describing those designs with rigor. I would naively say that they need nodes, edges, a variable deck, a node discovery utility, and a good variable property manager. But that's just because that's what I'm used to. I think once someone really serious sits down to formalize these things, we'll have a much richer environment. I just hope they do it soon! |