Necessities for Adoption of D

Hans W. Uhlig huhlig at clickconsulting.com
Sat Feb 9 13:42:27 PST 2008


Good morning everyone,
	I am new to the D forums but I have been following D's progress for a 
good while.

The topic seems to pop up quite a bit and was mentioned in the very long 
Standard Library Concerns thread about adoption for new users. Coming 
from C and then Java and now Looking at D. There are many things sun did 
  right with Java and some things that they still need to work on but I 
figure I will toss in my .02 and let people shoot each one down in turn.

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.

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.

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.

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

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.

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.

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)

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

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.

Feel free to shoot and flame all you like but I figured a Pointy Haired 
Programmers opinion from a newcomer might spark some valuable discussion.

Hans W. Uhlig
Engineer
Click Consulting, Inc.



More information about the Digitalmars-d mailing list