3 ms·

I agree that there is pedagogical value in forcing yourself to write programs using only immutable data structures, but I don't think it's a restraint we should

• tikhonj 14y ago
  Not only is that not cheating, it's actually completely reasonable in Haskell too! You can use ST to have as much mutable state as you like; the awesome thing is that the state is guaranteed not to leak--from the outside, the function is just as deterministic as one that doesn't use mutable references and data structures. The big idea about Haskell isn't to avoid all state. Not at all. The big idea is to control state. Haskell expects you to use state if it makes the logic clearer or the code much faster. What you do not do in Haskell is use state for program organization. You avoid global state as much as possible. This means that communication between disparate parts of your program are explicit--you don't have implicit dependencies everywhere. This is definitely a good thing. I think one of the problems is that people without much experience in Haskell interpreter "purely functional" too strictly. It just means you do not have state by default; you can still use it where it makes sense. The good thing about not having it by default is that it forces your program to be simpler and more decoupled and it lets the compiler and libraries make many more assumptions about your code. All sorts of awesome features like STM and data parallel Haskell depend on having this sort of control over side-effects. But that's all it is--control. You can still have state and side effects; however, unlike most other languages, you can also not have them.
• bad_user 14y ago
  On immutable data structures, a language like Scala makes it really practical to use only immutable data structures in daily programming. My own code is full of immutable data-structures, except in instances in which I have to process stuff returned by Java libraries and even in those cases I wrap them in Scala's immutable interfaces (note, I'm talking about Scala and not Haskell only because it's the language I know). The only problem is that many times you need mutable references to immutable data-structures, with no easy way out and this is where you can still have problems with side-effects and multi-threading. But dealing with such references is easier, because (a) you tend to do it less and less often and (b) you can use STM or just plain atomic references or @volatiles, as in many instances you need to just ensure the visibility of updates and you only really need locks only on writes. Also, I tend to encapsulate and hide really well pieces of code that deal with mutability. A good standard library of immutable data-structures is very practical for day to day use. I wasn't talking about immutable data-structures though, as the data-structures themselves are only a small part of the puzzle. Much more difficult is to deal with inter-modules communications, processing streams of data, I/O and stuff like that. And that's also where things break and where I feel the urge to look for better techniques. On lazy data structures, Python is an awful example.