Go and generic programming on reddit, also touches on D

[Timon Gehr]

On 09/18/2011 08:17 PM, Peter Alexander wrote:
> On 18/09/11 6:55 PM, Timon Gehr wrote:
>> On 09/18/2011 07:16 PM, Peter Alexander wrote:
>>> On 18/09/11 5:08 PM, Timon Gehr wrote:
>>>> On 09/18/2011 03:48 AM, Andrei Alexandrescu wrote:
>>>>> Quite interesting.
>>>>>
>>>>> http://www.reddit.com/r/programming/comments/kikut/think_in_go_gos_alternative_to_the/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> 2 hours ago, Andrei Alexandrescu wrote:
>>>> > The problem is, Vector was just an example of a multitude of
>>>> containers. The huge problem with slices is dogfood-related - they
>>>> are >
>>>> "magic" because the language features proposed to programmers were not
>>>> enough for expressing a simple abstraction. Reserving "special"
>>>> features
>>>> for the language is a terrible way to go about programming language
>>>> design.
>>>>
>>>> Don't D arrays do a similar thing? They are not templates, yet work
>>>> with
>>>> generic element types.
>>>
>>> Yes. As I understand, Andrei prefers things in libraries and Walter
>>> prefers things built in to the compiler (obviously an
>>> oversimplification, but I believe that's the general way they 'lean').
>>>
>>> There's advantages to both. Being implementable in a library means that
>>> they can easily be swapped out or modified to work with other code, but
>>> being built-in ("magic", as Andrei puts it) means that the compiler has
>>> greater awareness of them and can do better optimizations, give better
>>> errors etc.
>>>
>>> Of course, there are ways of extending the language to provide better
>>> errors and allow better optimizations (e.g. 'pure' in D), but as a
>>> purely practical matter, it's easier if they are just built-in.
>>>
>>
>> Well, I think arrays should be built-in. What I was implying was that D,
>> not entirely unlike Go, also has some magic. You can get almost the same
>> with templates, so it is way better in that aspect than Go, but it is
>> still there.
>
> Yes, you are right. D does have some "magic". Every language has to draw
> a line between library code and built-in code. The only way a language
> can be purely library is if the "language" is just the source code for
> the compiler :-)
>

It is not at all about syntax sugar, or whether or not the functionality 
comes in a library or as a built-in. I am merely feature-oriented here, 
and D does not have generics, but arrays work like generics. I am not 
even saying that is a bad thing. :)

>
>>>> Afaics, improving the language to the point were dynamic array-like
>>>> structures could be implemented in the library without resulting in a
>>>> bloated executable would be quite involved.
>>>
>>> I don't think you'd get much bloat in D by implementing dynamic arrays
>>> with templates. Remember, the built-in arrays *are* mostly implemented
>>> in D:
>>> https://github.com/D-Programming-Language/druntime/tree/master/src/rt
>>
>> Those work like generics, not like templates. Making them templates
>> would duplicate all the runtime functions that process arrays for every
>> element type it is instantiated with. And I am sure that would add some
>> bloat. D has no generics, just templates. But built-in arrays work like
>> generics.
>
> Yeah, they use runtime polymorphism like generics instead of compile
> time polymorphism.
>
> I don't believe there's any way round this -- you can't solve it with a
> better language design. If you want to handle different types with a
> single interface then either you need to generate code for each type
> (templates) or use runtime polymorphism (generics). Of course, you can
> improve both to minimize the overhead, but there's a fundamental memory
> v.s. performance compromise.

Consider eg this:

T foo(T: Object)(T x){
     return x;
}

Generics clearly win on that one, because it does not require code 
duplication or runtime polymorphism (as often is true in pure OO design 
programs for instance!). The same is the case for arrays. They don't 
need runtime polymorphism (except for stray language bugs such as 
array.sort).