4 ms·
> In other words I'd consider OOP for a "state-rich" problem domain Why is a paradigm like FP necessarily bad for this? Not all FPs are pure like Haskell, and
by dnautics 6y ago
> In other words I'd consider OOP for a "state-rich" problem domain
Why is a paradigm like FP necessarily bad for this? Not all FPs are pure like Haskell, and some exist specifically for the purpose of managing state in sane ways (for example which tolerate concurrency without introducing bugs).
- AnimalMuppet 6y agoWhich FP languages do you think would be good for managing state? I've read here on HN the idea that FP is appropriate when you can think of your program like a pipe (data comes in, data goes out). To me, significant amounts of state would be antithetical to that. Is that view mistaken?
- api 6y agoThat's a good way to put it. I've thought of it as "FP is good if you can think of your program as a single possibly recursive data transform, even if it's a very elaborate one." AFAIK it is theoretically possible to model any program that way, but it's only convenient for some problems.
- dnautics 6y agoThat's really not true for most working fp-languages. For example Julia has support for fully mutable datastructures, which, you might expect for a language designed for high performance scientific computation first. In my experience (20 years of OO programming and 5 of fp)... Almost all programs are better modeled as data transformations (recursive or otherwise). One time I did come across a data structure where this did not work, but I was not convinced that the layout of the data structure itself was wisely designed (it was tied to a legacy Django ORM layout).
- dnautics 6y agoJulia, erlang. Beyond some point you're using a DB for state anyways.