I thought I might write down some of the many suggestions I have for making D really come into the spotlight as a language.

They cover many areas, and I'm trying to address issues that I feel aren't being given - by what I've seen - enough attention.  I'm sure many of you here will pick me apart, and I look forward to it.

Hopefully some of the suggestions can improve D.

I write these with experience with an open source project I lead the development of, and years of watching the Mozilla development process. I have no doubt that the majority of these things would be of great improvement, if they are possible and done.

http://www.unknownbrackets.com/tutorials/polishing-d

-[Unknown]

Unknown W. Brackets wrote:
> I thought I might write down some of the many suggestions I have for making D really come into the spotlight as a language.


Thanks for taking the time to write this. I think your suggestions are very good.

Unknown W. Brackets schrieb:
> I thought I might write down some of the many suggestions I have for making D really come into the spotlight as a language.
> http://www.unknownbrackets.com/tutorials/polishing-d

Interoptability :
This will make IDE developers work extremely comfortable and will result    in world class tools.
Having this kind of interoptability (let me say interactive compiler) is a win win.
Outstanding IDEs, making D even more productive, attractive,  -> greater user base -> ...
As a side effect I can imagine that dll/so support will be improved.
f.i. Multithreading support.

I really hope to see this features become reallity! Ergo : vote++

But for the moment just 2 little things :
1- make compiler output more consistent, in other words, easier to parse. (same is valid for profiler output)
2- write errors to stderr

Regarding source-code-management/QA etc. :
IMO this should be essential part of an D IDE. Simply having support for current systems like CVS/SVN,Mercurial, .. is not good enough.

Excellent article Unknown !
Bjoern

On Sun, 20 Jan 2008 21:32:45 -0800, Walter Bright wrote:

> Thanks for taking the time to write this. I think your suggestions are very good.

I think I should ask you here since it's in context with the
Phobos suggestions.
What are you planning to do with Tango?

Personally I prefer the Phobos API for it's naming, organisation and documentation, but I also like the extra features tango adds and of course I don't want to say no to a faster garbage collector and less bugs, which leaves me torn.

Perhaps it might be time to replace Phobos, or (even better) officially merge the two libraries? Better now than later.

Unknown W. Brackets wrote:
> I thought I might write down some of the many suggestions I have for making D really come into the spotlight as a language.
> 
> They cover many areas, and I'm trying to address issues that I feel aren't being given - by what I've seen - enough attention.  I'm sure many of you here will pick me apart, and I look forward to it.
> 
> Hopefully some of the suggestions can improve D.
> 
> I write these with experience with an open source project I lead the development of, and years of watching the Mozilla development process. I have no doubt that the majority of these things would be of great improvement, if they are possible and done.
> 
> http://www.unknownbrackets.com/tutorials/polishing-d
> 
> -[Unknown]

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.

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.

Thanks.  It was just an idea I've had for a long time, I figured I'd throw into the end of the document as an example.  I'm glad you think it's a good idea.

Your point about stderr is a good one, and something I missed.  This is important mainly on Linux.  I mentioned the other somewhere.

For management, I'm really talking about D itself.  I'm mostly unconcerned about how people use D, as much as how D itself is developed and presented to them - I think that's what needs work, personally.

-[Unknown]


Bjoern Wrote:
> But for the moment just 2 little things :
> 1- make compiler output more consistent, in other words, easier to
> parse. (same is valid for profiler output)
> 2- write errors to stderr
> 
> Regarding source-code-management/QA etc. :
> IMO this should be essential part of an D IDE. Simply having support for
> current systems like CVS/SVN,Mercurial, .. is not good enough.
> 
> Excellent article Unknown !
> Bjoern
> 

Walter,

I'm volunteering to head up a web development project to revamp the 'site, should you be interested.  I'm sure a shiny new website would certainly give D a toe up in the external appeal department.

I'm not running a web design firm.  I'm really not interested in advertising potential or the likes.  I'd just like to commit something I can be proud of back to the community; and I should probably do the same for Walnut later anyways.

I've been a web designer for the last 11 years, and I know most, if not all the tricks with CSS and AJAX and the rest.  I fact, that's how I got into programming.  I'm currently a Web Site Manager for one of the plethora of internal websites within Citi, and the only one I know of that's W3C standards conformant.  It's also WAI AA conformant, and implements some cutting edge stuff that I haven't seen other people on the web do such as:

- keyboard accessible multi-tier horizontal-or-vertical suckerfish menus with the fix for the IE6 select box overlay bug.

- keyboard accessible toggle-able list-based suckerfish file tree generated from the file system.

- automatic user authentication and authorization using Active Directory; which is honestly limited to intranet applications.

- ajax SQL queries dumping into an embedded OWC excel spreadsheet.

I've attached screenshots from two previous iterations of my website for Citi to ease worries.

Regards,
Daniel Lewis

Unknown W. Brackets Wrote:
> 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]

Daniel Lewis wrote:
> Walter,
> 
> I'm volunteering to head up a web development project to revamp the 'site, should you be interested.  I'm sure a shiny new website would certainly give D a toe up in the external appeal department.
> 
> I'm not running a web design firm.  I'm really not interested in advertising potential or the likes.  I'd just like to commit something I can be proud of back to the community; and I should probably do the same for Walnut later anyways.
> 
> I've been a web designer for the last 11 years, and I know most, if not all the tricks with CSS and AJAX and the rest.  I fact, that's how I got into programming.  I'm currently a Web Site Manager for one of the plethora of internal websites within Citi, and the only one I know of that's W3C standards conformant.  It's also WAI AA conformant, and implements some cutting edge stuff that I haven't seen other people on the web do such as: 
> 
> - keyboard accessible multi-tier horizontal-or-vertical suckerfish menus with the fix for the IE6 select box overlay bug.
> 
> - keyboard accessible toggle-able list-based suckerfish file tree generated from the file system.
> 
> - automatic user authentication and authorization using Active Directory; which is honestly limited to intranet applications.
> 
> - ajax SQL queries dumping into an embedded OWC excel spreadsheet.
> 
> I've attached screenshots from two previous iterations of my website for Citi to ease worries.
> 
> Regards,
> Daniel Lewis

That would be fabulous.  My vote would be for a design at around the Slashdot level of glitz.  Not too much popup bling-bling or shiny faux glass junk.  The Citi pages look a little too shiny to me.  Good for Citi I think but not for a grass-roots programming language website.

In terms of functionality, making the user-comments in-line would be a big help.  Most people don't notice the "comments" button at the top of each doc page, and obviously the comments on those external pages don't show up when you do a Ctrl-F find-on-page search.

--bb

Aha, I thought that was somewhere... but couldn't find it.  I touched on this briefly.  It also represents problems as far as SEO (something that could be improved on D's pages.)

For example, the fact that these two, entirely separate in Google's eyes, URLs work is bad:

http://www.digitalmars.com/d/changelog.html http://digitalmars.com/d/changelog.html

In addition, really, all the pages within d/ should 301 redirect to 2.0/ so that 1.0 and 2.0 are each present in their pages' URLs.  This would make searching for documentation on a specific tree simpler and most likely improve relevancy.

But, this is more specific than I really wanted to get with the website's needs.  The important thing is making the decision to get the changes done, and taking the time to review who to work with on it.  Maybe an internal team of volunteers, maybe an outside agency.  This can't happen until responsibility is better dispersed...

As a side note, I work for a web company, and we use PHP primarily - which language I do like.  But it would be cool to see D eat its own dogfood here, and host the website on its own, lightweight webserver with D-coded dynamic pages.  This wouldn't be hard to write at all, and would really show the versatility of D (as well as efficiency, assuming it handled load well.)  Maybe not practically the best, though.

-[Unknown]


Bill Baxter Wrote:
> In terms of functionality, making the user-comments in-line would be a big help.  Most people don't notice the "comments" button at the top of each doc page, and obviously the comments on those external pages don't show up when you do a Ctrl-F find-on-page search.