3 ms·
What are the advantages of complete immutability when we can write compilers that specifically prevent shared mutability? You're avoiding the dangerous quadrant
by at_compile_time 4y ago
What are the advantages of complete immutability when we can write compilers that specifically prevent shared mutability? You're avoiding the dangerous quadrant but also excluding a valid one. I'd definitely prefer FP's solution over Python's GIL, but it still feels like an unnecessary compromise.
- assbuttbuttass 4y agoMost functional languages allow mutability when you need it, they just default to immutable data. Haskell might be the exception, where everything has to be immutable all the time
- marcosdumay 4y agoEverything does not have to be immutable in Haskell. It's only that mutability can only exist in IO or some other context that deals with it. The language enforces purity, not immutability.
- poorlyknit 4y agoThis is not true, Haskell of course allows you to mutate state. It just forces you to declare it: For example, there's a MutableByteArray type whose operations only work in a specific Monad (because Haskell...) [1]. There's also more basic stuff like IORef which represents an assignable variable [2]. Again, you're constrained to use this in IO contexts. Etc. Haskell basically just forces you to do that thing someone else in this thread mentioned: Write functional APIs, allow side effects but make them explicit and confined to very specific places. [1]: https://hackage.haskell.org/package/primitive-0.7.4.0/docs/src/Data.Primitive.ByteArray.html#newByteArray https://hackage.haskell.org/package/primitive-0.7.4.0/docs/s... [2]: https://hackage.haskell.org/package/base-4.16.3.0/docs/Data-IORef.html https://hackage.haskell.org/package/base-4.16.3.0/docs/Data-...