Why we chose not to use D for our Linux project

[Chris R. Miller]

Clay Smith Wrote:

> Chris R. Miller wrote:
> > Ty Tower Wrote:
> > 
> >> Lars Ivar Igesund Wrote:
> >>
> >>> I suppose you already made your decision, but as mentioned, a question in
> >>> the forum would have given you more information on this. DDBI has moved
> >>> very slowly over the last 18 months, but is being picked up again now, and
> >>> will hopefully have a new release soonish. DDBI in trunk is now Tango only,
> >>> but should work with DMD 1.028/29.
> >>> I won't critize your company for making the choice it did, as it obviosly
> >>> will need to earn money, but I don't see how you can expect the community
> >>> to do what you want it to do with getting involved yourself. 
> >> He has just done so?
> > 
> > He criticized the decision, but everyone's entitled to their own opinion.
> > 
> > Ruby is probably a better choice for a product they need to make money off of.  Ruby has a bigger community, it's older, and more stable.  It has better, more mature libraries, and setting it up is far easier than it is with D.  
> > 
> > In addition, he said that database support was lacking in D.  I have to second that.  DDBI is really the only viable tool that I can find, and on its dsource page it says to not use it because it's "going to change."  I can totally understand the confusion on that point.  The Tango confusion, not so much.
> > 
> > Ruby, on the other hand, is an SQL embedded language.  Doing things with databases is going to be trivially easy with Ruby.
> > 
> > Furthermore, Ruby has some excellent web-facing support with Ruby on Rails.  If they wanted to add some web-facing support to their product, they could use the exact same source code and the exact same libraries for the web application that they use for the rest of the whole mess.  Ruby can also make use of C extensions, which will doubtlessly become useful for managing - or even mangling - videos (since Ruby itself isn't all that fast in comparison).  That will also allow them to tap into an existing, impressive set of C libraries for video stuff, which they won't have to code.
> > 
> > It's probably a better choice to go with Ruby -- for **them**.
> > 
> >>>> I think some serious attention needs to be focused on this, rather than
> >>>> the minutiae of the latest cool language feature.  I have been following D
> >>>> for some years now, hoping it would all come together --- and I hope it
> >>>> does, soon --- as it feels D is being left in the dust.
> >>> Tools situation may have stagnated, but I'm not sure you have followed Tango
> >>> too closely :)
> >>>
> 
> <snip>
> 
> > A very good friend of mine and an absolutely fantastic programmer once told me some great advice: stop making stupid UML diagrams and write code!
> > 
> 
> Sorry, but I have to say that you are not getting great advice. The 
> design stage is the most important stage in the life of a program. Get 
> that wrong and you can write all the code you want, and it will all be 
> wrong.

That really depends on the problem.  If there's no existing solution, it's probably best to just sit down and write a solution and see how it goes.  If there's already an existing solution to a problem, spending some time and thought in the design phase will do you a lot of good in making a better solution.

Then again, that friend is really smart... He basically sat down and wrote a huge editor system for OS X (called Araelium Edit, if you've ever heard of it before) basically without any planning.  It still took him about three years to write, but he had zero diagrams, charts, or anything like that to share with me.  It was just code.

Often smart people forget that the rest of the world isn't quite that smart.  He might have been guilty of that when he made that statement.  Luckily, given my situation when he said it, he was right.  Trying to make something work in a real-code enviroment impelled me to leave Java.  Looking at where it's landed me, it's quite possibly the best advice I've ever been given, though your mileage may vary, of course.