9 ms·
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
by 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?