Hacker News Reader

Comment by hermitcrab | Hacker News Reader

Yes, attempting to re-implement generic programming (as opposed to a particular domain) as node-based seems doomed to failure.

View on HN

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.

I think node-based can work well for data flow or control flow. But probably not both.

We already have had good UI designers, they just never made it to the web.

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

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.

Idle thought: I sometimes wonder if SQL could be implemented visually. It's basically sets, after all.

I suspect it would quickly become too complex, but there's plenty of people smarter than me...

You often see SQL joins represented with Venn diagram, but it realy isn't a great representation of join.

You sure? I tend to think in terms roughly like this when I'm selecting a JOIN: https://dk81.github.io/dkmathstats_site/set-theory-sql.html

Eg (A LEFT JOIN B) = (A ∩ B) + A

Maybe I'm missing something though.

https://blog.jooq.org/say-no-to-venn-diagrams-when-explainin...

Hmm. It's true, the set model breaks down when you remove the key relationship, or add filters.

Reply on news.ycombinator.com