What's wrong with D's templates?

[grauzone]

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.

> The longer answer:
> 
> 1. optimizations - yes, the optimizer does take advantage of 
> immutability and purity, and yes, those optimizations are minor. But 
> they do exist and do work.
> 
> 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.

> 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, 
which again slow down the whole thing. Is there really an advantage over 
copying?

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).

> 
> 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?

> 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? There 
are old and central language core features which _still_ can trigger dmd 
bugs as of today (like forward references and circular module imports). 
I don't mean to be insolent, but I think the language is going to be too 
huge for one compiler writer. Yes, you're the one who knows best how far 
he can go, but I as a clueless user suffering from dmd bugs think the 
limit must already have been reached.

(btw. here's another one, but it's also going to be fixed soon: 
http://d.puremagic.com/issues/show_bug.cgi?id=2093)

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.

> 
>> Over two years have passed since immutable/const was added to dmd, but 
>> I couldn't see any benefit yet. But lots of new compiler bugs. There's 
>> the danger that those feature are all nothing but hot air in real 
>> programming. I like D, and it sure would relief me to hear that this 
>> is not the case.
> 
> The message passing threading advantage awaits the construction of a 
> message passing library. Sean Kelly is working on it.

That's nice, but it would be possible without immutable.