Polishing D - suggestions and comments

[Unknown W. Brackets]

I tried to stay away from the language, syntax, style, etc. for the most part.  There are things to talk about there, and plenty of opinions flying around.

Even if I were an expert on compiler design and theory, that's getting enough attention.

I'm more concerned about process.  Whether or not D has a pluggable GC or better interface design won't really prevent D from becoming a widely used language.  They are good things to think about and discuss, nonetheless.

C/C++, Perl, PHP, Java, all languages have design flaws.  But almost all of them have covered the issues I mentioned - or else they wouldn't have become well known languages.  I think that's the biggest issue for D right now.

-[Unknown]


Neal Alexander Wrote:
> Having a highly optimized and pluggable GC would go a long way i think.
> 
> 
> It seems like sometimes a naive implementation in D can be slower than 
> its Java counterpart -- kind of a kick in the teeth IMO. People tend to 
> have a false sense of security that stuff will automatically be faster 
> because its native compiled.
> 
> It wouldn't hurt to have an article explaining the performance 
> implications of some of the more exotic features of the language either.
> 
> 
> 
> On an unrelated note: i've noticed a *lot* of code tends to use 
> templated function parameters for stuff like read()/write() operations. 
> This type of usage pattern should probably be supported in a different 
> way IMO.
> 
> Things to consider (off the top of my head):
> 
> **** Avoid template code replication for different types by defining 
> common attributes / operations -- some type of numerical interface that 
> defines operations for built-in and user types. This doesnt have to mean 
> that basic types become real classes but that the compiler knows how to 
> generate stubs for each operation.
> 
> 
> t_interface ordinal  { void inc(); void plus(ordinal); ... }
> t_interface copyable
> {
>      void* ptr();
>      size_t size();
>      void copy(copyable);
>      ...
> }
> 
> Side note: Maybe the "copyable" interface could be overloaded to perform 
> endian conversion or simple crypto etc.
> 
> 
> t_interface number : ordinal, copyable, ...;
> 
> type double : number
> type int    : number
> type char   : ordinal, copyable;
> 
> class user_t : number
> {
>      uint64_t backing;
>      size(){ return backing.sizeof; }
>      inc(){ ++backing; }
>      ...
> }
> 
> void f(number x){ x.inc; printf("size=%d", x.size); }
> 
> double d;
> int i;
> char c;
> user_t t;
> 
> f(d); -> size=8
> f(i); -> size=4
> f(c); -> size=1
> f(t); -> size=8
> 
> 
> **** Function parameter assignment
> double d;
> file.read(d, offset=4);
> 
> void read(copyable data, size_t offset = void, int flags = 1234){ ... }
> 
> ("void" used to ignore options instead of hacks like size_t.max would be 
> nice)
> 
> 
> 
> I dunno, its kind of a half baked idea i guess, but something to consider.