Thursday, October 16, 2008

ArcLib status + The Problem with D

Just a short time to post, spending most of my time finishing up college, looking for jobs, thinking about the possibility of graduate school.

ArcLib status: ArcLib development should be considered "on hold" until about May 8th, 2009. I'm leaning towards doing some more work on ArcLib after that. It is already on solid ground and the D community is fairly awesome.

The Problem with D: From a language standpoint, there is one major problem with D, and that problem is that D is not C. I have a feeling that most serious system level projects (Operating Systems, Game Engines) are done in C, because...

1. C is everywhere, there is a compiler for every system
2. Everyone knows C, it is tried and true
3. C is a better language to program in than C++ for large scale projects. The C++ STL is not up to par, and C++ adds more complexity than useful abstraction. Game companies that do use C++, like EA, implement their own version of STL. I'm guessing they also use a restricted subset of C++ features.

I think what is holding D back is
1. You can not find a D compiler for every system
2. Not many people know how to program D
3. There is too much legacy code written in C++ / C

Problem 2 and 3 are problems due to marketing and language maturity. Also, as more code gets written in D, even more code gets written C++, so the amount of D code will probably never be able to eclipse C++ / C code.

Problem 1 can be addressed, but needs to be addressed via the community like what is happening with the LLVMDC project.

So, D will probably stay as being a very niche language in the ecosystem of computer language's, catering to those few independent minded folks who do not need to program for the Ps3/X-box, etc., and who actually value the beauty of a language over it's acceptance in the world, and who don't mind having to re-invent the wheel. These "problems" are actually acting like a filter, and so the D community itself is very cohesive.


Sin said...

I think the official D compiler should target llvm, either as part of clang or in some other way.

baxissimo said...

Well, these problems are not D's problems specifically. They are the generic "new language" problem.

LLVM is almost certainly the answer to #1, though.

Clay Smith said...

They may be generic problems, but I feel that they are what is holding back D the most.

AFFLTest said...

I have to add the problems of a 'moving target' and of a split community.

The moving target really applies only to D2, but for many people (here I am extrapolating 'me' to mean 'many people' ;)) D2 offers many new features which are extremely compelling. The fact that D2 is still a moving target though makes it risky to code to and means you have even fewer libraries to make use of. Hopefully this will be resolved when D2 closes in on release.

The Phobos/Tango and D1/D2 splits are very problematic: It essentially makes more smaller communities out of an already small community. Thankfully this seems to be on fast track to being resolved through a common runtime.

he_the_great said...

I'm going to stick with affltest here. I enjoy using D and recommend friends try it, but I can't recommend using it. D1 suffers from the Phobos/Tango split because only some libraries work with both. And it has D2 looming over its head. D2, well, it has nothing.

I think once D2 settles down, and Tango with all its friends are usable there, being able to recommend and push D will be easier.

I would change 2 to, not many people know of D and how it improves C++

3 is the reason Walter wants D to work with C so easily.