What's wrong with D's templates?

[Walter Bright]

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.