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