3 ms·

Your comparison of mutable programming to the use of goto and unhygenic macros would suggest that mutation is a similar type of dinosaur to be culled. >You've

Your comparison of mutable programming to the use of goto and unhygenic macros would suggest that mutation is a similar type of dinosaur to be culled. >You've never tried to compose multiple asynchronous event streams of complex data types from different subsystems into one single user-facing unified presentation, have you? Your assertion is simply not true. Such feat is way simpler in functional reactive style, and a true nightmare in an imperative multithreaded program. That's why web frameworks are evolving to handle more and more reactive functional patterns for compositional asynchronous tasks. Imperative programming with state is simple. Programming asychronous event streams of complex data types from different subsystems into a single unified presentation is complex. Functional programming claims to have abstractions that make the latter more simple than imperative programming, which may or may not be true. The use of functional reactive style in React (I do not believe Angular relies on this) is probably driven by JavaScript having atrocious scoping rules and the general Web / DOM stack being full of hacks and badly written APIs. The hacks that are still present in React make it seem like this will just be yet another layer of cruft that is the front end, alas.

TuringTest 3y ago
> Your comparison of mutable programming to the use of goto and unhygenic macros would suggest that mutation is a similar type of dinosaur to be culled. Then you missed the point, which is that using mutation a.k.a. cells a.k.a. imperative code when it's not needed is a dinosaur to be culled. But you need to understand when it's not needed to realize this. Functional reactive programming adoption is not something caused by the state of one particular stack; as it is also being adopted by game engines, big data analysis tools, development environments like web notebooks, etc. People throughout the industry are seeing the value and are simplifying their tools thanks to the paradigm. > Functional programming claims to have abstractions that make the latter more simple than imperative programming, which may or may not be true. Look, I get it, I really do. You don't see the possibilities of the functional paradigm and don't know how and where to use it effectively, so you keep criticizing the small part of it you do understand. I've been there, done that (though it was a long time ago). With that attitude you can stay comfortably in a corner and be impervious to the changes the industry is undergoing, and miss out on a really cool programming style out of prejudice. Or you can accept the intellectual challenge (which it certainly is, especially for someone who has spent his entire career with a single style), and know concepts that those who learn them agree that they improve their programming even if they do not adopt them 100% for their work. It's up to you. I don't gain anything with this, so I will not try to convince you of it.

TuringTest 3y ago

> Your comparison of mutable programming to the use of goto and unhygenic macros would suggest that mutation is a similar type of dinosaur to be culled. Then you missed the point, which is that using mutation a.k.a. cells a.k.a. imperative code when it's not needed is a dinosaur to be culled. But you need to understand when it's not needed to realize this. Functional reactive programming adoption is not something caused by the state of one particular stack; as it is also being adopted by game engines, big data analysis tools, development environments like web notebooks, etc. People throughout the industry are seeing the value and are simplifying their tools thanks to the paradigm. > Functional programming claims to have abstractions that make the latter more simple than imperative programming, which may or may not be true. Look, I get it, I really do. You don't see the possibilities of the functional paradigm and don't know how and where to use it effectively, so you keep criticizing the small part of it you do understand. I've been there, done that (though it was a long time ago). With that attitude you can stay comfortably in a corner and be impervious to the changes the industry is undergoing, and miss out on a really cool programming style out of prejudice. Or you can accept the intellectual challenge (which it certainly is, especially for someone who has spent his entire career with a single style), and know concepts that those who learn them agree that they improve their programming even if they do not adopt them 100% for their work. It's up to you. I don't gain anything with this, so I will not try to convince you of it.