grauzone wrote:
Walter Bright wrote:
grauzone wrote:
Walter Bright wrote:
I can expound on the huge advantages immutability and purity offer,
if you want.
Yes, I'd like to hear about this. You can leave away the things that
are not going to be implemented (like memorization of pure return
values), are only micro-optimizations (common sub-expression
elimination with pure functions?), which don't work (immutable was
used to make strings read-only, but you can stomp over immutable
arrays), which were thought to be useful, but nothing has
materialized yet (something like immutable was supposed to be the
cure for multithreading)...
The short answer is: the benefits of functional programming.
I can see how D benefits from some functional language features (like
those that increase expressiveness), but not the immutability thing.
It's a good idea, but there's some tradeoff. And immutability can still
be handled as a concept outside of the language type system.
You can certainly do immutability as a convention, but I contend that is
unreliable and does not scale. It's like saying you can write C code
that doesn't have buffer overflows.
I have been using C since before it had function prototypes. It was just
all kinds of win to add the prototypes, because then the manual checking
got handed over to the compiler.
2. immutable reference types can be treated as if they were value
types - this advantage is most obvious in strings. Without
immutability (and this happens in C, C++, and D1) programmers tend to
make their own private copies of things "just in case" someone else
changes them.
With string, you used to follow the copy-and-write protocol. Now you're
doing the same (you have to re-instantiate immutable data to change it),
just that the compiler forces you. This can go good for reliability, but
it also takes a lot of flexibility. Plus you have to deal with the
complications of the type system now.
My experience is that relying on convention to follow the protocol does
not work. I think that the evidence in the field that it doesn't work is
pretty compelling as well.
3. (2) has a great advantage in doing message passing between threads.
This model was popularized by Erlang, and is very successful. You can
do message passing without immutable references, but you've got to
hope and pray that your programming team didn't make any mistakes with
it. With immutable references, you have a statically enforced
guarantee. Value types (and immutable references) do not need
synchronization.
But you need to allocate this data from a shared garbage collection,
You do anyway.
which again slow down the whole thing. Is there really an advantage over
copying?
Copying will invoke the garbage collector. Since you argued that is
slow, then avoiding the necessity of doing so will make it faster.
For large portions of data you could (at least in theory) make it
_actually_ read-only by using mprotect (make the memory pages read-only).
Compile time checking is better than runtime checking.
4. immutability and purity enable user reasoning about a program.
Otherwise, you have to rely on the (probably wrong) documentation
about a function to see what its effects are, and if it has any side
effects.
If the program logic gets more complicated because of the type system,
this isn't going to help much. Now I see you applying language hacks
like DIP2 to reduce the damage. Is there an end to it?
C function prototypes increased the complexity, but it was darn well
worth it. You can either have more complexity in the language, or you
can spend endless hours manually checking to see if convention was
followed - and even then you can't be sure.
Yes, there was a recently discovered bug which enabled modifying an
immutable array. This was a bug, and has been fixed. A bug does not
mean the concept is broken.
Sure, but the question is: will all those bugs ever to be fixed?
Forgive me, but every month 20 to 40 bugs get fixed. You can see it in
the change log. I don't understand these complaints.
Also, how much is this reliability worth if you can just cast away
immutable? It's even exactly the same syntax you have to use for
relatively harmless things, like casting a float to an integer.
It's not allowed in @safe functions.
That's nice, but it would be possible without immutable.
Again, relying on convention has shown, in practice, to NOT WORK when it
comes to making reliable multithreaded programs.
