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.
Nah, same asymptotic limitations, just different constants and patterns in what's sensible.
Example: https://www.youtube.com/watch?v=6nh6LpcXGsI
Data.Map, Data.Sequence, Data.Vector all serve for most anything you'd want.
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.
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 Java has finally been dragged into the 1960s!