Hacker News Reader

Comment by mikewarot | Hacker News Reader

Mixing procedural and reactive code in the same program. Imagine if A := B worked in the normal pascal assignment sense, but A :<<: B caused A to be recalculated every time B changed, like a magical assignment operator.

If you assigned something to the system clock, it would act like an interval timer, for example.

View on HN

https://svelte.dev/ is an example of this idea.

Snapshot state in Jetpack Compose is a less magical version that works well with multithreading.

Surplus too, which came before it (but is less popular because it wasn't marketed at all).

An issue would be spooky action at a distance. A ripple effect of a single assignment could cause a cascade of computations. What order do they happen in? How do you find them all?

Use an algorithm similar to excel spreadsheets, mark a result dirty, and ripple through all the dependencies.

This is always comprehensible in excel because state changes only ever come about as a result of a user changing a value in a cell. In the general case where there are a bunch of different asynchronous sources of change, this could become pretty confusing.

This is why you would opt for a declarative language like Excel for this kind of feature. You define a relationship, and the programming language runtime maintains it as an invariant. Then you don’t care where or when or how the value changes, because that doesn’t factor in to the definition of the thing.

The language can help with debugging by providing traces of execution that you can record and replay to inspect. Then you can query the trace to answer any questions you have about the execution of the program.

The next issue is that you will want atomic updates of multiple variables, because in "x = y + z", you might not want an intermediate "x" value to be used somewhere if both "y" and "z" change.

It gets messy fast, and I absolutely would not want to debug a big program that was full of implicit dependencies like this. This was tried in Java FX. AFAIK it was a total disaster.

I wouldn't say that's an issue, that's how programming is done in such systems. It's like noting that maintaining and managing state is an issue for imperative languages, and you wouldn't want to debug a program that's full of state changes and side effectful functions. Yes, it can be messy, but that doesn't preclude language constructs, compiler support, and best practices to help you write correct programs. Today's newest imperative programming languages try to smooth out the rough edges of old languages in this way.

The issue with reactive, declarative languages is they have not been given the same opportunity to optimize. We've devoted a lot of resources to making imperative programming more accommodating despite all of its warts, but with declarative programming so far we have decline to go through the same process.

Declarative reactive programming has proven to have a lot of potential. After all, if we call Excel a programming language (which it is), then reactive programmers far outnumber those of any other style. We should take that direction as far as it can go. Mine it for every good idea the same way imperative programming has been mined. Sure maybe JavaFX was a total disaster. But why can't its successor be better? Why exactly was it a disaster? What could potentially be done to improve that?

K has this: http://johnearnest.github.io/ok/index.html?run=%20a%3A%3Ab*c...

a::b*c; b:2; c:3; a results in a being equal to 6, and if you update b or c a will update too.

How is this different than a method pointer, Action<T>, Runnable etc? Maybe I don't understand what you're suggesting. Is there something more to it than assigning a method to a variable and calling it as if it was a plain variable?

What GP is suggesting is more about push systems than pull. In a push system you'd have something like this:

  a = 10
  b = 20
  c = a * b
  s = "{c}"
  widget.display(s) -- will show '200' at the start
  a = 2             -- c = 40 and widget shows '40'

It's like a spreadsheet. In a pull system, each dependent would have to periodically update itself, which means they'd be doing unnecessary work when there haven't been changes, and be stale (for longer than necessary) when there have been changes.

So maybe something closer to an observable but sugar built into the language? I suppose it could be interesting if everything was an observable and you could implicitly chain observables through assignment.

Yes, and I actually meant to include them in my comment but for some reason didn't.

Have A be a pointer to B?

Reply on news.ycombinator.com