4 ms·

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 th

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.

ModernMech 5y ago
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.
- titzer 5y ago
  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.
  - ModernMech 5y ago
    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?

ModernMech 5y ago

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.

titzer 5y ago
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.
- ModernMech 5y ago
  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?