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

51–60 of 126 posts

Re: Managing State with Signals

#51

Post by mirekrusin »

samsquire wrote: post #3

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…

Jane Street/Yaron Minsky/at al came to similar conclusion with their formalized incremental implementation [0] - that this type of computation reappears in different contexts (build systems, ui, optimal data processing/display on large volumes of high frequency data etc). It's very interesting approach indeed.

[0] https://blog.janestreet.com/introducing-incremental

Re: Managing State with Signals

#53

Post by bheadmaster »

ed_blackburn wrote: post #40
bheadmaster wrote: post #33

Earlier quoted context omitted.

What's the exact difference between Erlang and OTP that would answer my question?

OTP is the means by which the programming language is able to accomplish tasks such as process to process comms, how to supervise actors etc. It's the enabler for the distributed computing compared to Erlang which is the programming language. They're (obviously) complementary but OTP is the magic that enable one to deliver on the reactive manifesto. Functional programming needs augmenting with mechanisms that provide…

Thanks for the explanation.

Where does reactive programming fit in that concept? Is OTP a "reactive" library? If so, why - what exactly makes it "reactive"?

Re: Managing State with Signals

#54

Post by dgb23 »

bheadmaster wrote: post #29
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…

What's the difference between reactive and functional programming? Both seem to focus on expressing relationships between objects and having compiler/runtime infer the computation, instead of explicitly specifying the computation.

> Both seem to focus on expressing relationships between objects and having compiler/runtime infer the computation, instead of explicitly specifying the computation.

That's true of every declarative approach. Functional, reactive, relational, regex etc. are all to some degree declarative.

To answer your question: Functional programming is really more about avoiding mutation at the language surface, while reactive programming is about how mutation propagates through code, so it's an abstraction over specific mutation. This is why they pair nicely together.

Re: Managing State with Signals

#55

Post by mananaysiempre »

Joker_vD wrote: post #48
neel_k wrote: post #41

Earlier quoted context omitted.

Surprisingly, FRP doesn't have anything to do with dataflow constraints at all. In FRP, a program is fundamentally a function of type Stream Input → Stream Output. That is, a program transforms a stream of inputs into a stream of outputs. If you think about this a bit more, you realise that 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 l…

> 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 instead, but in reality multiple simultaneous events have always been a sore point for FRP—in some libraries you can have them (and that’s awkward in some cases), in some you can’t (and that’s awkward in others).

Re: Managing State with Signals

#56

Post by samsquire »

mirekrusin wrote: post #51
samsquire wrote: post #3

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…

Jane Street/Yaron Minsky/at al came to similar conclusion with their formalized incremental implementation [0] - that this type of computation reappears in different contexts (build systems, ui, optimal data processing/display on large volumes of high frequency data etc). It's very interesting approach indeed. [0] https://blog.janestreet.com/introducing-incremental

I wonder if there is some wisdom in Rich Hickey's Transducers

There is also differential dataflow.

I feel all the ideas are related and could be combined.

What I want is a rich runtime and API that lets me fork/join, cancel, queue, schedule mutual exclusion (like a lock without a mutex), create dependency trees or graphs.

I am also reminded of dataflow programming and Esterel which a kind HN user pointed me towards for synchronous programming of signals.

Re: Managing State with Signals

#57

Post by flagrant_taco »

awestroke wrote: post #37
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.…

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.

Re: Managing State with Signals

#58

Post by inglor »

mpweiher wrote: post #46
neel_k wrote: post #41

Earlier quoted context omitted.

Surprisingly, FRP doesn't have anything to do with dataflow constraints at all. In FRP, a program is fundamentally a function of type Stream Input → Stream Output. That is, a program transforms a stream of inputs into a stream of outputs. If you think about this a bit more, you realise that 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 l…

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

Re: Managing State with Signals

#59

Post by inglor »

mpweiher wrote: post #46
neel_k wrote: post #41

Earlier quoted context omitted.

Surprisingly, FRP doesn't have anything to do with dataflow constraints at all. In FRP, a program is fundamentally a function of type Stream Input → Stream Output. That is, a program transforms a stream of inputs into a stream of outputs. If you think about this a bit more, you realise that 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 l…

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.

Re: Managing State with Signals

#60

Post by cormacrelf »

mirekrusin wrote: post #51
samsquire wrote: post #3

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…

Jane Street/Yaron Minsky/at al came to similar conclusion with their formalized incremental implementation [0] - that this type of computation reappears in different contexts (build systems, ui, optimal data processing/display on large volumes of high frequency data etc). It's very interesting approach indeed. [0] https://blog.janestreet.com/introducing-incremental

May be of interest: I released a port of Incremental to Rust the other week. It has a bit of a way to go in polish and docs, but the core implementation and API should be very familiar. (To the extent that it uses GADTs for node kinds just like the OCaml!) It has Expert nodes so incremental-map is feasible and already works. I’ve been using it as the state management for some UI with much success. Credit to the authors because it’s a good design. https://github.com/cormacrelf/incremental-rs
Post reply on HN