Necessities for Adoption of D

[Hans W. Uhlig]

Burton Radons wrote:
> Hans W. Uhlig Wrote:
> 
>> 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".
> 
> Do you mean in the library or in the language? I don't think D can be
> a magically-parallelising language; it's not constructed for it, and
> while it's a cool trick in those languages which do it I'd be worried
> about it not parallelising important code because of some functional
> test incorrectly failing and making it run sequentially. But it could
> handle something like OpenMP more elegantly, where you tell the
> compiler what can be parallelised, a la:
> 
> // The compiler can and probably should split this into pieces. 
> parallel foreach (i, foo)  // The compiler can also do these two
> tasks at the same time. parallel { // Pause any other worker threads
> so that only this thread can work during this statement. synchronized
>  { }
> 
> // But this only causes us to pause this thread if another thread is
> using the object. synchronized (object) { } }  parallel bar ();
> 
> // But everything's gotta be done before calling this! baz ();
> 
> That would be a quick addition to the compiler that could be expanded
> over time (both in how well the compiler handles the instruction and
> semantics) rather than taking a month just to get it to a
> semi-working state, it's something that would retain its usefulness
> even if the compiler starts to learn how to automatically parallelise
> code, and it's simple (probably too simple, I haven't explored OpenMP
> much) while still making a material contribution to the language.
> 
> I'm working on this issue in a library, but there's a limit to how
> elegant I can make it. Also I have no freaking idea what I'm doing.
> It hasn't stopped me before, but it does slow me down.
> 

Yes, With both where computers are going and where they already are, 
native parallelism is one of the prime areas where a language will have 
to shine.

>> 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 half agree and half disagree. I can see how this allows outsiders
> to get a simple, cohesive view of a language. On the other hand,
> there are often manifest problems or deficiencies in a library, and
> variations on a theme allow us to explore different ways to address
> the issue and find the best way to implement it. This is particularly
> important with D, which has certain features which no other language
> has and needs implementing in new ways. It's not pointless
> reinvention.

very true but when you move from hobbier to production you need a single 
accepted standard you can show a Pointy haired project manager and say 
we are using X from Y. we can rely on them supporting it for x years. 
Personal Development vs Corporate development have very different 
standards.