I'm pretty sure I can implement any imaginable algorithm without mutation.
Implementing it with any efficiency seems like a different question.
A common activity in many programs is scanning a list and changing a few items based on some criteria. So far I've heard in Haskel you either duplicate the list or create a complicated data-structure that somehow essentially makes this mutation OK. Either ways seems silly - especially do what you did before but with complex dance around it.
> Either ways seems silly - especially do what you did before but with complex dance around it.
Interesting you think that. I think the opposite. It seems silly to overwrite something that someone else may have been relying on to not change when I can do a persistent update with pretty much the same performance.
That makes immutability a nice technique if you happen to be dealing with a situation of synchronous access and otherwise an unneeded approach.
The topic was haskell as first-language. Despite the hype, most people aren't going to be writing fully synchronous applications most of the time and thus immutability all the time seems mostly like unneeded bondage and discipline programming.
> I'm pretty sure I can implement any imaginable algorithm without mutation.
We know this from the equivalence of Universal Turing Machines (which mutate a tape) and partial recursive functions (application of operations to immutable values).
Any mutation is a functional mapping from the total previous state to the total new state.
Of course, you generally don't want your ethernet driver to clone the entire OS just because it has another packet to add to a queue.
Mutation can be tremendously resource-saving, when you don't need the previous state. The problems occur when parts of the software develop nostalgia for the way things were before the mutation. :)
Even in non-Haskell, a lazy list is a obvious possibility for that. It's not for no reason that many languages have implemented map, reduce, filter; laziness can still be pretty efficient while increasing composability and readability.
Even Java has finally been dragged into the 1960s!
Implementing it with any efficiency seems like a different question.
A common activity in many programs is scanning a list and changing a few items based on some criteria. So far I've heard in Haskel you either duplicate the list or create a complicated data-structure that somehow essentially makes this mutation OK. Either ways seems silly - especially do what you did before but with complex dance around it.