Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Managing State with Signals

tonsky.me

Post reply on HN
Print view View original

61–70 of 126 posts

Re: Managing State with Signals

#61

Post by idkwhoiam »

klabb3 wrote: post #14
mpweiher wrote: post #11

It looks like we are going to keep reinventing dataflow constraints[1] over and over again, always with slightly different terminology (Rx, FRP, signals, ...) So it (a) appears to be a very useful or at least attractive concept, and (b) somehow difficult to fit into current programming languages/practice in a clean way. [1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an... (HN: https://news.ycombinator.…

I feel like reactive programming is approaching ripeness for a mainstream programming language or cross-stack paradigm within the next few years. React, Svelte, Redux etc in the frontend world has certainly paved the way on the mainstream side, albeit in a simplified environment (singlethreaded, does not cross the network boundary and can simply share memory cheaply). I wonder if a refined version of this with will p…

The native (future) solution for Apple platforms is SwiftUI [1] + Combine [2]. I use it on a side project and for somebody who works with React 9-5 it feels very natural. In short SwiftUI is like React & Combine is like RxJs.

[1] - https://developer.apple.com/tutorials/swiftui [2] - https://developer.apple.com/documentation/combine

Re: Managing State with Signals

#62

Post by giovannibonetti »

mpweiher wrote: post #11

It looks like we are going to keep reinventing dataflow constraints[1] over and over again, always with slightly different terminology (Rx, FRP, signals, ...) So it (a) appears to be a very useful or at least attractive concept, and (b) somehow difficult to fit into current programming languages/practice in a clean way. [1] https://blog.metaobject.com/2014/03/the-siren-call-of-kvo-an... (HN: https://news.ycombinator.…

A language/framework that explored well this idea is Elm, which is used in front-end apps. It started with Signals and FRP, then 7 years ago changed course to the Model-View Update architecture [1], today known as The Elm Architecture. It is still a bit niche, but a handful of frameworks in other languages like Rust are following this architecture for GUI apps.

[1] https://elm-lang.org/news/farewell-to-frp

Re: Managing State with Signals

#63

Post by Joker_vD »

mananaysiempre wrote: post #55
Joker_vD wrote: post #48

Earlier quoted context omitted.

> any implementable function has to be one whose first k outputs are determined by at most the first k inputs -- i.e., you can't look into the future. That is, these functions have to be causal. def f(input_stream): i = next(input_stream) j = next(input_stream) yield i + j f(input_stream) This function produces k outputs when given 2*k inputs, so it's either acausal or impossible to execute. Right?

For GP’s stream-transformer / state-machine equivalence to work, you need to sprinkle option types throughout so each input yields some kind of output, even if empty. So more like def co(): i = yield None # hurray for off-by-one streams j = yield None while True: i = yield i + j j = yield None This won’t help if the output stream produces more than one output item from each input item. You could sprinkle lists instea…

But I am not criticizing his stream-transformer / state-machine equivalence, I am just curious why he thinks functions of Stream A -> Stream B have to produce exactly 1 output for exactly 1 input.

Now, I know that Haskell in its pre-monad days used to have main have signature [Response] -> [Request]: the lists being lazy, they're essentially streams. Each Request produced by the main would result in a Response being provided to it by the runtime. This model actually has to be strictly 1-to-1, and indeed, it was so easy to accidentally deadlock yourself that switching to IO monad was quite welcomed, according to SPJ in his "Tackling the Awkward Squad" paper.

Re: Managing State with Signals

#64

Post by mpweiher »

inglor wrote: post #58
mpweiher wrote: post #46

Earlier quoted context omitted.

A couple of notes: 1. You seem to be confusing "dataflow constraints" with "dataflow". Though related, they are not the same. 2. Yes, the implementation of Rx-style "FRP" (should have used the scare quotes to indicate I am referring to the common usage, not actual FRP as defined by Conal Elliott) has deviated. And has deviated before. This also happened with Lucid. 3. However, the question is which of the two is the…

Mathematically, RxJS and Vue/Solid Qwik like FRP are equivalent. There is interesting proof by Meijer (who invented Rx) in the famous "duality and the end of reactive". https://www.youtube.com/watch?v=SVYGmGYXLpY

> 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 bit of both.

For example, the "Reactive" part of Rx-style FRP appears to come from the definition of system styles by Harel. Both the connection of synchronous dataflow with the term "Reactive" and with FP languages are made in the paper on Lustre, which is a language that integrates synchronous dataflow into an FP language. But there is nothing inherently FP-ish about synchronous dataflow, it was previously integrated into to the imperative language Esterel, and they also made a variant of C with synchronous dataflow.

Again, nobody mentions this, it is all presented as having been invented out of thin air and the principles of Functional Programming. (Or as having come from Conal Elliott's FRP, which is not true. Ask Conal Elliott).

Once I figured out the connections, I asked Erik Meijer, who has "I am the original inventor of Rx..." in his bio. He admitted that he was "inspired" by synchronous dataflow. And of course that is pretty much all it is. Except they dropped the requirement for it to be synchronous.

What do you get when you drop "synchronous" from "synchronous dataflow"? FRP, obviously ;-)

Just like Objective-C is Smalltalk + C, and Objective-C - C is ... Swift?

Controlling narratives is important.

Re: Managing State with Signals

#65

Post by dm3 »

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 compared to something like React.

[0]: https://github.com/hoplon

[1]: https://github.com/hoplon/ui

Re: Managing State with Signals

#66

Post by eternalban »

pdamoc wrote: post #25

Elm started as a FRP language and ended up giving up FRP[1] for ease of use. If ease of use is targeted, signals might not be the best approach. I distinctly remember things becoming easier when they went away. [1] https://elm-lang.org/news/farewell-to-frp

Thanks for the link.

Re: Managing State with Signals

#67

Post by aatd86 »

inglor wrote: post #59
mpweiher wrote: post #46

Earlier quoted context omitted.

A couple of notes: 1. You seem to be confusing "dataflow constraints" with "dataflow". Though related, they are not the same. 2. Yes, the implementation of Rx-style "FRP" (should have used the scare quotes to indicate I am referring to the common usage, not actual FRP as defined by Conal Elliott) has deviated. And has deviated before. This also happened with Lucid. 3. However, the question is which of the two is the…

Also, as someone who both works on open source reactive stuff (like MobX) and literally works on a spreadsheet app (Excel) I can say what we do is entirely different from what these systems do because of different constraints and both are reactive.

I'm curious. How so?

Re: Managing State with Signals

#68

Post by ElFitz »

idkwhoiam wrote: post #61
klabb3 wrote: post #14

Earlier quoted context omitted.

I feel like reactive programming is approaching ripeness for a mainstream programming language or cross-stack paradigm within the next few years. React, Svelte, Redux etc in the frontend world has certainly paved the way on the mainstream side, albeit in a simplified environment (singlethreaded, does not cross the network boundary and can simply share memory cheaply). I wonder if a refined version of this with will p…

The native (future) solution for Apple platforms is SwiftUI [1] + Combine [2]. I use it on a side project and for somebody who works with React 9-5 it feels very natural. In short SwiftUI is like React & Combine is like RxJs. [1] - https://developer.apple.com/tutorials/swiftui [2] - https://developer.apple.com/documentation/combine

While I agree, I’d say I find SwiftUI easier and more intuitive than React. And Combine often much more frustrating than Rx.

Re: Managing State with Signals

#69

Post by ElFitz »

samsquire wrote: post #10
bsaul wrote: post #8

Earlier quoted context omitted.

"It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation." This rings so true to me. I've recently realized how every single non trivial part of my app is in fact a workflow problem : it could be ideally written as a pipe of asynchronous steps, glued together. It's true both for the frontend part and the back…

Thanks for this thoughtful and insightful comment. Many problems can be workflow problems, sometimes even pulling in a rule engine, or require a job queue to do things that can fail. Then you have software such as https://temporal.io/ which is really powerful for resilient workflows. Imagine coordinating the user with a workflow with asynchronous data collection steps. Imagine programming "reaction to user behaviour…

I often wonder about some sort of unified distributed system, encompassing frontend & backend into a single whole. One where user input is just something the system can ask and wait for, no matter which frontend or client it comes from.

But I’ve only ever been able to catch glimpses of it. More of a nebulous feeling and intuition than a real understanding of how such a thing would work. Something that feels obviously right, that will make perfect sense once understood, but that I still can’t begin to grasp.

It’s frustrating.

I’m also pretty sure I must not be the first, and that it either already exists or involves some complexity, maintainability or evolution issues I have no idea of.

Your example reminded me of "it".

Re: Managing State with Signals

#70

Post by naasking »

flagrant_taco wrote: post #57
awestroke wrote: post #37

Earlier quoted context omitted.

The idea in and of itself is not what is being rediscovered. Nobody is reinventing the wheel. It's whether the implementation is ergonomic and powerful that determines whether it catches on.

Signals have become enough of a buzz word that they may catch on just for the hype, regardless of whether they are particularly powerful or ergonomic.

I feel like signals have been a buzzword for almost 10 years now.
Post reply on HN