Necessities for Adoption of D

Hans W. Uhlig huhlig at clickconsulting.com
Sun Feb 10 08:10:22 PST 2008


Clay Smith wrote:
> 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.
> 

You would be surprised what a crappy GUI in a standard library can do, I 
reference AWT & Swing as an example. It did miles to help Java.

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

I will look into DSSS but it sounds like something that should come with 
the base package including your standard lib, and toolchain.

>>
>> 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.
> 
Its not that all peoples code should be but the language should follow 
the same paradime for the "accepted" and "core" code and libraries.



More information about the Digitalmars-d mailing list