On Monday, 14 May 2012 at 06:27:15 UTC, Walter Bright wrote:
On 5/13/2012 11:09 PM, Mehrdad wrote:
(1) Compiler helps you write correct multithreaded code
(2) You help compiler perform optimizations based on contracts
(3) I don't think there exists a #3 that's very different from
#1 and #2
#3 Improves self-documentation of code - it's more
understandable and less susceptible to breakage during
maintenance.
#4 Improves encapsulation
#5 Makes function purity possible
And all this together culminates into a much greater ability to
_reason about code_.
Suppose I have code like this:
immutable item = ...;
auto res = aPureFunct(item);
// tons of code
auto calc = someVal * aPureFunct(item);
Barring the fact that the compiler will probably optimize this
out for you in D... If you were writing C++ code like this, you
couldn't tell _almost anything_ about this code based on that
fragment I gave you. The mere fact that I can tell you
_something_ is shocking. I can figure out properties and reason
about code, even in small chunks like this. I know that I can
replace "aPureFunct(item)" with res and it'll be equivalent.
I'd say that this is my favorite reason (but non-obvious unless
you actually code using const/immutable):
#6 Reduced cognitive load
I posted this elsewhere, but it also ties multiple things
together (including the GC):
How about if you're trying to figure out how often a substring of
length 10 is repeated in some large string (maybe 4 million
characters long?). In D:
uint[string] countmap;
foreach(i; 0..str.length-10)
++countmap[str[i..i+10]];
And you're done. Because your string is immutable, D will do the
correct thing and use pointer+length to the original huge string
and won't waste time copying things that are guaranteed not to
change into its hash table. Thanks to the GC, you don't have to
worry about watching your pointers to make sure they get deleted
whenever it's appropriate (when you're done, you can just clear
out countmap and the GC will collect the string if it's not used
by anyone else...). Presumably the associative array
implementation could take advantage of both the immutability of
the string and the purity of toHash to cache the result of
hashing (although, I'm not certain it does).
Now imagine the code you'd have to write in C++ or many other
languages to do this _right_. Not just fast, but _also_ correct.
The fact of the matter is that, considering all of D's features,
the whole is greater than the sum of its parts. Can you find
something wrong with each part? Of course. But the fact of the
matter is that each of them support each other in such a way that
they synergistically improve the language ... if you take any one
of them away, you would be left with everything else being less
useful than before.
This is why you really ought to spend some time with const and
immutable (and, yeah, they're mostly inseparable) and really get
to know what it enables you to do. Tons of features and
capabilities depend on it, so it's really not something that
"should be gotten rid of to make the language more marketable".
I'm not saying I wouldn't use D if we lost const/immutable, but
it would certainly sour my experience with it.
