How is this different from “drawing is better than writing a book”?
Some people write, others draw. Each method has its own strength and problem spaces.
Encoding a complex issue sometimes is just shitty with a visual metaphor. Other times writing code is a really bad idea. If you want to express “flow” or “connections”, filter or stream systems like modular synths, that’s when the visual metaphor shines.
You use whatever metaphor works best at the moment. One cannot replace the other.
The “problem” is that people want to push all of “programming” into the visual metaphor. That’s like pushing all of programming into only functional, only declarative, only imperative or only OOP (or whatever), but worse. That’s not going to work, but I guess people can try.
I agree. I love modelling state machines in node-based systems, and I think user interfaces could be fine in node-based editors (I’ve never tried, but they’re already node-based internally and they seem well-suited in the same way state machines are). But I’d hate to model something like a flow of concurrent tasks with retries and exponential back offs or something where the visual queues don’t seem like they’d be obvious and the editor couldn’t (as far as I can imagine) offer useful simulation or testing tools.
It could be a failure of my imagination. I’ve designed similar things though, and these weird cases (especially temporal cases) become extremely hard to represent more universally. I suppose you could offer a “timeline” to indicate how things would behave on a time scale, but even that… I just don’t know.
It also seems key to have a node-based editor work with one language or a set which map together extremely well.
OTOH, whenever somebody is explaining their multithreaded async code lines on a web page or in a book, there a graph is shown, since it seems to be the ideal metaphor. Just not for implementation purposes...?
There's definitively some hard limitation in dimension, though, so there might be the idea that, if one can only show problems of a certain limited complexity visually, why not do all the lousy (text-based, relational/reference-based way) but universal way that at least can be stored and edited everywhere.
So a central question might be: can we have a universal gain from, let's say, a three dimensional notation that still does not limit the problem space to these dimension.
As a UI designer (at times), I have to say... It isn't easy. I've made much nicer UIs on MacOS and iOS than I have on the web, with considerably less effort.
Part of it is what people expect. You get pushed and pulled when it comes to designing things for the web. Partially by constraints, partially by people's desires and expectations. It's better than ever these days, but my career has generally had the greatest challenges presented on the frontend of web projects.
I find backend development a bit "smoother". I won't say easier, but... I don't know, the frontend of the web is a jungle and a bit of an uphill battle sometimes.
I suspect my phrase “UI designer” was misunderstood: I learned to program in 1996 or so with Delphi and the graphical UI design paradigm of that environment failed to make the jump to website design
Some people write, others draw. Each method has its own strength and problem spaces.
Encoding a complex issue sometimes is just shitty with a visual metaphor. Other times writing code is a really bad idea. If you want to express “flow” or “connections”, filter or stream systems like modular synths, that’s when the visual metaphor shines.
You use whatever metaphor works best at the moment. One cannot replace the other.
The “problem” is that people want to push all of “programming” into the visual metaphor. That’s like pushing all of programming into only functional, only declarative, only imperative or only OOP (or whatever), but worse. That’s not going to work, but I guess people can try.