immutability

Is there a benefit to immutable data structures like in Clojure and erlang? What does it do for you versus just not mutating mutable objects?

They share structure. If you have a huge structure and you need a new version of it with just one changed value, without a structure-sharing data structure you'd need to copy the whole thing. Imagine your structure being 1MB and needing to be updated 1000 times a second, and you'll get it.

what the fuck is this programming shit doing in my /g/?

SAGE!

>>1
Thread safety as well as JIT optimization of extra copies into mutable accesses on a single copy whenever it is safe to do so.

Don't listen to faggots who will recommend their dead language called Haskell -- they combine language-wide immutability with strong typing, resulting in a mess of academic proportions.

>>1
It may seen like a restriction at first, but it quickly becomes a data model with which to program against, and it forces you to think very differently about programing. Simply returning a value becomes almost as the goal of all functions, and using that data becomes merely something required for returning new data. It's a very interesting model to program againstt, and one that the result s of are amazing. I highly recommend it, OP. learn Erlang.

>>1
Immutable data means you don't need to lock concurrent access to variables since a change will never be observed. Clojure seems to be more sophisticated, IIRC >>2 doesn't apply as much to Erlang as it does to Clojure.

>>6
Yeah, the description was about Clojure. I don't know anything about Erlang.

Sharing part of a data structure, thread safety, easier to reason about, easier to keep earlier versions of a data structure, unlocks the possibility of doing clever tricks behind the scenes.

Example of a ``clever trick'':
We have a list defined as a sequence of conses whose cdr is a cons or '(). The predicate list? has to cdr all the way up to the last element, and check whether it is null?. Since the list is immutable, when we cons something to '(), we know it will result in a list, and that cannot change, so (cons x y) can return a cons with some metadata saying it is a list whenever y is '(), or a list. The list? predicate is now O(1) instead of O(n).
The length of a list will also not change, we can make length O(1) instead of the usual O(n) in the same way: (length '()) is 0, (cons x '()) makes a list of length 1, (cons x y), where y is a list of length n, marks the returned cons to be a list of length n+1.

>>8
Then again, it's better not to do that for ALL cons pairs since that would just be a waste of space.

I have seen people bring immutability up in Clojure vs. CL conversations. Does Common Lisp's have an answer to this paradigm?

>>10
I believe the usual answer is akin to ``Clojure is Java brackets Jewish set theory infinity nonsense''

>>9
In a way or another, you're going to need an header in your structures to store the type tag, maybe how the data should be aligned, stuff for the GC, etc.
You can reserve some bits for datatype specific metadata, and use one or two bits to encode that. No space wasted, except for the length thing.

>>10
I'm sure there's a library for it.

>>9
idk how it's done in fact, but you could keep it with your references. Then you have it for every reference into the list (the only place you can use it), and nowhere else. There's some overhead of recalculating the length, but it's O(1) at each step, so complexity remains unaltered.

Hey guys, would you like to have mutable or immutable strings?

>>16
Yes, please.

>>17
Should the constructor copy the character array it is passed?
I guess this is a prerequisite of mutable strings.

>>18
Not if the array itself is immutable.