Necessities for Adoption of D

[Clay Smith]

Hans W. Uhlig wrote:
> Good morning everyone,
>     I am new to the D forums but I have been following D's progress for 
> a good while.

Hello.


> 1) Lots of example code & documentation - This one may sound silly, but 
> if you want to do nearly anything in Java as a programmer, you can enter 
> in Google "Java <thing I want to do>" and find something from sun on the 
> topic. This makes it simple for new users.

I do not think D lacks examples or documentation. When I was a newer 
user, http://www.digitalmars.com/d/1.0/lex.html and 
http://www.dsource.org/projects/tutorials/wiki got me by pretty well. If 
the documentation is good enough for newbie hobby programmers, I think 
professionals should be able to understand it.

> 
> 2) A single standard library for most tasks - The whole Phobos here and 
> Tango there and DWT someplace else makes picking up a language 
> difficult. Not only that but as a Java Instructor I can simply point to 
> the Sun java & javax library sets available and say here is something 
> that can do that. In Suns case it may not do it well but its there.

I sort of agree, but...

1) While Tango / Phobos situation is not up to par, ... the situation 
would be a whole lot worse if Tango didn't exist. Tango is pretty great, 
and I think just by its existence it will help get phobos up to speed, 
as well as provide a good alternative lib that decent programmers can 
have a sense of ownership with.

2) It probably is not smart to have a big GUI in a standard library, 
because if the GUI is buggy and incomplete, people will think the same 
of the whole standard lib. Plus, someone may write a better GUI and then 
the standard lib won't be able to use it.


> 
> 3) Good automatic documentation library for EVERYTHING - Being able to 
> search and find all the information on a Java library in the same format 
> and the same style no matter what library I look at makes using the 
> language easier and usually faster for development.

We have that http://www.digitalmars.com/d/2.0/ddoc.html

> 
> 3) Good, native parallelism - With dual core, quad core, or in IBM's 
> Cell  processor Obscene core processors, none of the current C Syntax 
> family is parallelism handled natively and "well".

I'm pretty sure the D community is very aware of this.

> 
> 4) Write once, run everywhere. - This one may make me sound like a loon 
> but Sun had the right idea. Just not the bast implementation. I will 
> clarify however I said Write once, not compile once. Most system 
> specific tasks for application level programming are handled by the 
> standard library. This includes gui integration, simple and native cross 
> compile tools and integrated tar/compression support.

Both phobos and Tango are cross platform...

> 
> 5) A library packager - The scripting languages got it right with cpan, 
> simple quick, easy, no complex installation instructions, just cpan 
> install x. Being able to do this and keep your libraries up-to-date 
> quickly and easily is a godsend to most programmers. DSource is nice, 
> but it lacks a lot in usability, and being able to figure out core from 
> cruft.

I think DSSS http://www.dsource.org/dsss has the potential to become 
this, although lack of a 'dsss update' feature prevents it. DSSS is a 
great way to fetch libraries however.

> 
> 6) Well supported exterainious libs - In java if you need an xml library 
> there are 30, in perl if you need a mysql link, there is one that is 
> regularly updates. This one takes people using the language and doing 
> such things but its important none the less. There is no reason to 
> reinvent the wheel 10 times when someone has done it for you. (I am well 
> aware that many programmers will reinvent the wheel 'right' again anyway)

I'm not sure what you mean by well supported, but D does have plenty of 
libraries that do a pretty good job of gettings things done 
http://www.dsource.org/projects

> 
> 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
> odd but being able to time a function or stress test something across 
> all possible values from your IDE is a beautiful thing, as is good 
> debugging, syntax coloring and all the other nifty little things that 
> Eclipse and Visual Studio have done right.
> 
> And my final bullet for this memo which is far longer then I thought it 
> would be

I don't know anything about this really, but D did recently get a d.ide 
newsgroup, so its on the radar it looks like.

> 
> 8) Unified Thought in Paradime - Right now I see in the community a 
> divergence in idea between C style functions, C++ style classes and a 
> cleaner java style classes. (My preference is C functions and java 
> classes but thats just me) Choose your options and unify that in the 
> library. Do what perl did in premise and have oo or function style(yes I 
> am aware this is older libs like CGI but I dont care for the argument). 
> Integrate Both paradimes into the core logic of your libraries or focus 
> on one. But don't develop libraries that compete.

I don't think library competition is necessarily a bad thing. It adds 
some sport into the process and if a library has to compete, it will 
become stronger.

As with unified style,... I think 
http://www.digitalmars.com/d/2.0/dstyle.html tries to be it, but 
honestly, you can't control someone to do exactly how you want. People 
will just use the style they feel confortable with and its nice to know 
that D attracts C, C++, and Java programmers.