Comment by eternalban | Hacker News Reader

Comment by eternalban | Hacker News Reader

Parent Full thread

Curious as to choice of 'demands' vs 'dependency' and 'supplies' vs 'provider'. The latter of these are fairly commonly understood and used.

As an aside, "complex, interdependent state" is possibly one of the few areas that lend themselves naturally to visual programming (which is a fail in the general programming case). Why not just draw graphs?

> I've read plenty of reactive blog posts and reactive library documentation sets and they all struggle with communicating the benefits.

I just googled 'visual programming for reactive systems' and this (interesting project) turned up:

https://openmusic-project.github.io/openmusic/doc/reactive.h...

So the approach is specifically addressing complex interaction patterns between components. To highlight the solution, just do what these guys did: here you can see the benefit of 'reactive components' just by looking.

https://openmusic-project.github.io/openmusic/doc/images/mid...

(2c - good luck w/ the project)

It's a reasonable suggestion about the naming of demands and supplies. We landed on those names because they had some of the correct connotations, and it was easy to be clear with each other what we were talking about. A "Demand" is a very specific thing when using Behavior Graph. "Dependency" is a common term that means half a dozen things in a program at any given time. "Supplies" is just a reasonable opposite to "Demands".

That being said, we do often consider renaming them and other parts to feel more mainstream reactive. But honestly, I secretly suspect that fiddling with names won't make a difference to anyone.

I do also agree that there is some appeal to visual programming paradigms. It's pretty easy to look at the examples you linked to and get some quick sense of understanding. But those typically work well when there are a handful of nodes and edges. The software we maintain at work can have 1000's of nodes at runtime with more than 10000 edges. There's no visual representation that won't look like a total mess. Whatever their faults, text based programming languages are the only approach that have stood up at scale so far.

So our library is just a normal programming library. You can use standard javascript/swift/kotlin to write it.

Thanks for your feedback! :)

Reply on news.ycombinator.com