Live data from Hacker News

Managing State with Signals

tonsky.me

121–126 of 126 posts

Re: Managing State with Signals

#121
post #119

Earlier quoted context omitted.

> Mathematically, RxJS and Vue/Solid Qwik like FRP are equivalent. Yes, these are basically the same thing. However, they have little to do with Conal Elliott's "FRP". Which itself is also badly named. > Meijer (who invented Rx) Well "invented". What's a bit surprising is that with both Rx and the Rx-style "FRP", there either is no public history of the ideas at all (Rx) or it is patently wrong (Rx-style "FRP"). Or a…

All this is documented in Meijer's actual paper though? (Your mouse is a database) as well as his aformentioned talk (duality and the end of reactive). He for sure invented observables (as we know it and as the mathematically dual of enumerables) - that doesn't mean it was the first ever reactive system or the concept of data being dependent of other data. If I remember correctly he also explicitly talks abut Conal F…

I have seen plenty of Erik's talks and certainly read Your mouse is a database a bunch of times.

What is "documented" there is the alternate history of all this coming out of fundamental insights into FP and dualities and all that.

But that isn't the case, it just sounds a lot better than "I found a really complicated way to map dataflow onto FP concepts".

But we as an industry just love complicated.

Re: Managing State with Signals

#122
post #117
post #67

Earlier quoted context omitted.

I'm curious. How so?

In a gist: MobX just keeps the whole dependency graph of what data needs to update when what computed runs. Excel can't do that because it has to be able to work on large files with impartial data.

Aren't excel formulas the expression of data dependency graphs?

In which case it is kept in the document?

Re: Managing State with Signals

#123
post #117
post #67

Earlier quoted context omitted.

I'm curious. How so?

In a gist: MobX just keeps the whole dependency graph of what data needs to update when what computed runs. Excel can't do that because it has to be able to work on large files with impartial data.

Isn't the Excel document still in memory?

Re: Managing State with Signals

#124
post #88

The author does a lovely job of covering a number of the interesting ideas in this space. But reactive programming is such a tough sell. I know from experience. I maintain a reactive, state management library that overlaps many of the same ideas discussed in this blog post. https://github.com/yahoo/bgjs There are two things I know to be true: 1. Our library does an amazing job of addressing the difficulties that come…

That sounds very familiar to me. I'm now retired but in my last job I put together a simple C++ framework to do something similar. I used this in a small part of a financial trading application. Like you, I was convinced it would pay off to apply much more widely, but I found it difficult to "sell" the idea. As you say, the real payoff comes in complex situations, which simple examples don't really convey. However lots of people seem to be playing around with reactive programming now, so perhaps it's an idea whose time is coming.

Re: Managing State with Signals

#125
post #65

Interesting that this is Clojure and it doesn't mention Hoplon/Javelin[0] as prior work. I've used Hoplon/UI[1] to implement a moderately complex web app ~6 years ago. The library is practically a prototype, pretty much dead by now. However, I found the ideas interesting. I find the biggest benefit of using a fringe library like this is the ability to read and understand the whole implementation. It's really simple c…

FYI, they recently resumed activity on Hoplon. Good to see!

Re: Managing State with Signals

#126

It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation. But the implementations are rarely extracted out for general purpose usage and rarely have a rich API. I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a seq…

This sounds almost like you've just invented Haskell-like `IO`.

All operations get "queued up" in IO and only run "at the end of the world".

To write your program you `flatMap` over the `IO`: An `IO` contains the computation(s) that will run at some point, but you can map on the result of them right away, and return another `IO` value; than `flatten` the `IO[IO]` data structure (which makes `flatMap`). In Haskell you have extra syntax for `flatMap` called "do notation". In Scala, where there are library solutions for `IO`, you can use "for comprehensions" instead. In both cases the nested `flatMap` calls get sequenced. This way and you can write code almost like a consecutive chain of imperative procedure calls but it all gets "queued up" and the whole program only runs when the `IO` data structure gets evaluated by the runtime ("at the end of the world", as last call in your program).

But that's not really related to data flow.

Post reply on HN