Lars Ivar Igesund wrote:
> Tools situation may have stagnated, but I'm not sure you have followed Tango
> too closely :)

The tools situation is definitely not stagnant!

Ty Tower wrote:
> Torhu says as well that DBI should work with 1.029 etc etc but has he checked? Has Lars checked?  Obviously Bill checked and it didn't .

He did not make clear from his post that he checked the latest revision in trunk. These were merely suggestions. And I'm guessing Lars checked considering he's the one maintaining it.

Bill Lear wrote:
> Sadly, we have given up on using D for our Linux project, despite my hopes and favorable overall impression of the D language.  I thought I would share briefly our reasons in hopes that the information is useful to those in the D community.
> 
> We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related information.  We need a language that has a library that provides easy database access (something along the lines of Perl's DBI, for example), CGI programming support, access to system-level routines, reasonable performance, YAML support, and other features.
> 
> We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust --- it just wasn't going to work without serious effort.

The last stable release of ddbi compiles on the most recent releases of dmd and tango with about twenty minutes' work. However, when compared with the Active Record implementations in Ruby, Python, and C#, and the various Hibernate-like libraries, D has nothing comparable.

There's an issue of having no convenient way of supplying metadata on UDT members. The best method I've come up with is:

1. Define a template that takes the metadata arguments.
2. This template expands into a string containing a static constructor.
3. The static constructor adds some data to a metadata aggregator singleton, keyed to the ClassInfo of the current class.
4. By the way, you can't initialize that singleton with a static constructor, because that might be called after the static constructor that creates the instance.
5. Now, instead of querying the typeinfo for the metadata, you query the metadata aggregator.

Ugly! And it turns the code from:

@Field(dbname = "id", primaryKey = true)
int id;

to:
mixin(Field!("id", true));
int id;

Or if you want named parameters, you use some string parsing scheme, like I did (actual code from a project I'm working on):
mixin(dbfield!("id", "name = id; primaryKey"));
int id;

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

There are people working on it. Just relatively few, compared to the number of people working on Ruby or Python, both of which have been around a fair bit longer. There's an advantage that D is coming out later and thus doesn't have to do as much research in how to make decent libraries. But C# had some of that, and Ruby launched itself out of obscurity with that, so it isn't much of a competitive advantage.

"Bill Lear" <rael@zopyra.com> wrote in message news:g0sa4j$2fmf$1@digitalmars.com...
> Sadly, we have given up on using D for our Linux project, despite my hopes and favorable overall impression of the D language.  I thought I would share briefly our reasons in hopes that the information is useful to those in the D community.
>
> We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related information.  We need a language that has a library that provides easy database access (something along the lines of Perl's DBI, for example), CGI programming support, access to system-level routines, reasonable performance, YAML support, and other features.
>
> We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust --- it just wasn't going to work without serious effort.

I certainly see you're point. I'm still using 1.028 and compile dbi with few changes to the source code, but I still encounter some obscure bugs that needs workarounds. And I havent got dbi to work with the build tools, so I'm building manually. Still, D 1.0 is not very old so I don't think you can expect a load of mature libraries. It would have been great if some companies would support D though. I'm an open source enthousiast, but until there are good enough open source libraries I would gladly spend some money on commercial ones if any existed :)


> We settled on ruby, after spending a short time installing the necessary components, coding up test routines, and deciding it fit the bill.
>
> The sad thing is that D looks very promising, but the future for it does not, I'm afraid, unless the D community can produce a coherent set of tools that are used in the real world and that can be installed without developers being burdened with trying to figure out arcane install problems, incompatibility issues, and the like.  With ruby, we had just a few easy commands to run to install DBI and it was up and running, and we have had no problems with it since.
>
> I told our CTO that maybe in a year or two D would have a stable set of libraries and support systems in place that could be considered, but we'll be long past choosing D at that point.
>
> 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.
>

Yeah. Even if D2 is very exiting, I think the focus should be on D1 and building a stable base of libraries. But as someone else mentioned here, most libraries are one man efforts and thus have the tendency to get abandoned when they loose interest or when the library works for their purpose.

But I don't agree with the future of D looking pale. I have been using D for various projects since it hit the 1 mark, and it works well even if it has its quirks (the libraries being the main reason. I've switched UI several times, switched to tango, debugged almost every library I've tuched etc...). I'm actually very glad I found D as I've found the complexity of C++ a bit daunting in the past.

"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:g0t0gj$11sh$2@digitalmars.com...
> bearophile wrote:
>> Python/Ruby and D are in two quite different classes of languages. Usually where you use one of them you don't want to use the other.
>
> Not necessarily. D is still useful for quick scripting. More to the point, webapps are often written with Ruby/Python/Perl backends which could be swapped out for one written in a native language to help performance.

I agree with the scripting. I'm still using quite a lot of python, but when I'm doing small programs I'm often using D to avoid the bloat of py2exe. Too sad I haven't gotten PyD to work with larger classes, and it seems it won't be updated until D2.

Ty Tower Wrote:

> This is a typical of a lot of what like to call themselves "The D Community" They are more interested in attacking the messenger.
> 
> Torhu says as well that DBI should work with 1.029 etc etc but has he checked? Has Lars checked?  Obviously Bill checked and it didn't .
> 
>  If you aren't sure why post?
> 

I checked out the D DBI trunk about two weeks ago. It didn't build out of the box but after a number of trivial fixes it did. It's been working pretty much as expected (with MySql backend, I haven't tried it with other backends yet). There was a bug or two like fetched resultsets being freed prematurely, but the bugs were trivial to fix as well. Currently I'm building a thin ORM layer on top of DDBI and I think it is turning out to be a fast and flexible solution suitable for my purposes.

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.

Reply to Clay,

> 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 said, you have given nothing to the end user until you start writhing code. So design the code and then and then get on to writhing it. I haven't seen it my self but I rather suspect that projects have failed because they didn't want to be done designing it.

Clay Smith wrote:
> Chris R. Miller wrote:
>> 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.

Agile software development? XP? :-)

"Simen Haugen" <simen.haugen@pandavre.com> wrote in message news:g0tttj$8mt$1@digitalmars.com...
>
> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:g0t0gj$11sh$2@digitalmars.com...
>> bearophile wrote:
>>> Python/Ruby and D are in two quite different classes of languages. Usually where you use one of them you don't want to use the other.
>>
>> Not necessarily. D is still useful for quick scripting. More to the point, webapps are often written with Ruby/Python/Perl backends which could be swapped out for one written in a native language to help performance.
>
> I agree with the scripting. I'm still using quite a lot of python, but
> when I'm doing small programs I'm often using D to avoid the bloat of
> py2exe.
> Too sad I haven't gotten PyD to work with larger classes, and it seems it
> won't be updated until D2.

If you're referring to the errors you get from the linker about symbol length, there's nothing Kirk can do about it.  It's a major shortcoming of the DMD Windows object format and linker, namely an extremely limited symbol length.  It works fine with all the other compiler combinations (GDCWin, DMDLin, GDCLin).