Hacker News Reader

Comment by kia | Hacker News Reader

I think mutability was unavoidable because in the early days memory an CPU cycles were too expensive to waste them for copying data.

View on HN

The machines that we deal with are mutable as hell (unless we see time as an implicit argument ;)). Most early languages were thin abstractions from machine code, and the world kind of built from there.

Doesn't mutability force you to actually copy data? Immutability enables sharing, which needs less copying.

(Of course what it really comes down to, is whether you use multiple different copies of your data structures. If you only ever use one, even functional languages can update them in place. See Clean's linear types as an example, or Haskell's ST monad.)

Mutable objects are there so that you don't have to create new instances whenever a field changes. The danger of shared mutable objects is that the ground can change beneath your feet.

Immutable objects enable safe sharing, however, if you have an immutable object and want to change it, you have to copy it and make the change during construction of the new object.

I guess the 'copy penalty' in either case depends on the size of your objects.

If your compiler is smart enough (i.e. you are programming in clean, or use Haskell's GHC) the `copy penalty' can be zero for objects that only have "one future", i.e. you only ever keep one copy of your structure. (And that's still cleaner and safer than mutable structures.)

The `copy penalty' for multiple uses of your objects, say a = update1 (x), b = update2 (x), does not depend so much on the size of your object as one the amount of sharing you can do. Immutable objects allow sharing. For mutable ones you have to work much harder.

Actually, today's hardware, with multiple cores/CPUs clashing over shared memory through non-shared cache, is less friendly to mutability than the old systems.

Immutability does require different data structures; a (singly-linked) list is easy to make immutable in most cases -- many lists with the same tail part can share that tail, without copying when a new list starts sharing that tail. Arrays, not so much.

Though to be fair, singly-linked lists are not useful for parallelism.

Unless the list elements can be thunks that can be evaluated when necessary or appropriate. See for instance Control.Parallel.Strategies in Haskell, which provides amongst others 'parMap' (parallel mapping over lists).

Even then it's not enough. The problem is that the structure of a list is itself linear. Guy Steele had a nice talk about that.

(This only bites you when your lists get long.)

I think that's a too blanket statement. What do you want to do with the list, a map or a fold? In the former case, what is the cost of the function application?

Please have a look at Guy Steele's talk (http://www.vimeo.com/6624203). Basically he suggests using tree-like data structures, instead of linear data structures. You can also map, fold and filter over trees, but it parallelizes better.

Ah those were the days when computers hardly had enough memory to even keep the Haskell standard prelude in memory.

Immutability doesn't necessarily require copying data all the time though if you copied data only when modified and used the right data structures, does it?

1990?

I think the issue of mutability in OOP vs FP pre-dates that.

The Haskell 98 standard prelude is 39 kb big. Computers with less RAM than that were in use in the early 1980s. Since you're obviously an engineer by training, you may now ask why somebody would try to load an Haskell prelude in the early 1980s on a computer that isn't even capable of running a Haskell programme.

Anyway, I guess what I actually wanted to say got lost in the space between.

Actually, I'm wondering what Haskell has to do with any of this at all.

You're comparing the size of the current incarnation of a fairly modern functional programming runtime with the capacity of computers that existed 10 years before the first incarnation was realised...

The only message I can take from that is that programs today are quite big. That's only really interesting from a nostalgic point of view, I don't see what relevance it has to the discussion of mutability?

Of course, I could have missed something obviously significant here...

The parent poster was talking about immutability, "the early days" and copying data. I think my point was that you don't have to copy data all the time but this requires a clever interpreter/compiler that you could not have run "in the early days".

I'd also like to use the opportunity to say that I find those OOP vs FP posts at HN rather pointless.

Reply on news.ycombinator.com