Necessities for Adoption of D

[Burton Radons]

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.

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