www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why we chose not to use D for our Linux project

reply Bill Lear <rael zopyra.com> writes:
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.

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.


Bill
May 19 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Bill Lear (rael zopyra.com)'s article

 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.

 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.

I agree with your comment on tools and libraries in general, but D does already
have a solid
install/update/build tool in DSSS/rebuild.  With it, installing supported
packages is as simple
as "dsss net install blah", which I believe is roughly equivalent to ruby gems
or whatever you
used there instead.  Regarding DB support, I think some branch of DDBI may
actually build
with the current version of D, but you're right that it doesn't receive a lot
of attention.
Unfortunately, D is still very much a language for self-starters, and the
overarching focus
on newer and more features rather than building a solid base for development
probably
doesn't help things either.  Overall, the trend seems to be a churn of new
users rather than
a growing group of serious professionals--likely for these reasons.  That said,
there are
more than a few professional developers which have found a development
environment
which suits them--from my experience it tends to be DMD/Linux and Tango with
either
makefiles or DSSS for building and GDB with the demangling patch for debugging.


Sean
May 19 2008
parent reply Bill Lear <rael zopyra.com> writes:
Sean Kelly Wrote:
[...]

 I agree with your comment on tools and libraries in general, but D does
already have a solid
 install/update/build tool in DSSS/rebuild.  With it, installing supported
packages is as simple
 as "dsss net install blah", which I believe is roughly equivalent to ruby gems
or whatever you
 used there instead.  Regarding DB support, I think some branch of DDBI may
actually build
 with the current version of D, but you're right that it doesn't receive a lot
of attention.
 Unfortunately, D is still very much a language for self-starters, and the
overarching focus
 on newer and more features rather than building a solid base for development
probably
 doesn't help things either.  Overall, the trend seems to be a churn of new
users rather than
 a growing group of serious professionals--likely for these reasons.  That
said, there are
 more than a few professional developers which have found a development
environment
 which suits them--from my experience it tends to be DMD/Linux and Tango with
either
 makefiles or DSSS for building and GDB with the demangling patch for debugging.


Thanks to all for the (mostly) thoughtful comments on this issue.  I have tried
again, this time documenting my steps, to more thouroughly illustrate what I am
going through.  Here is a more-or-less verbatim run of my efforts to get dbi
compiled and installed.  To say the least, the results are less than satisfying:
Download and install d 1.030.

Go to D web site to find OBI component.  Look for something that
indicates "tools", or "libraries" for D.  See "Tools" section.
Look in "More Tools" link.  Nothing there, so back to the
main page.  Look under "Community"/"D links".  Looks good.
Using Firebugs, search for "Database" on the page.  Find D DBI.
Ok, click it.

Look for "downloads".  Find "Recommended" is "Version 0.2.5", so
download that to my build directory and unzip the zip file.

Look for and find doc on "HowToBuild".  It says:

The current recommended way to build dbi.lib is to use buildme.d. It comes
in the directory below dbi.

To build a release version of D DBI with every module, use any of
the following:

    dmd -run buildme.d all

So, I try the first command:

% cd tags/0.2.5
% dmd -run buildme.d all
buildme.d: module buildme cannot read file 'buildme.d'

So, it fails because it cannot read the file.  So, I figure out why:

ls -l
total 28
----------  1 rael rael 4478 2007-02-03 01:21 buildme.d
drwxr-xr-x 10 rael rael 4096 2008-05-28 15:02 dbi
drwxr-xr-x  3 rael rael 4096 2008-05-28 15:02 docs

It has unzipped things with no read permissions.  So, I fix it and try
again:

% chmod +rw buildme.d
% dmd -run buildme.d all
buildme.d(42): module FileConst cannot read file 'tango/io/FileConst.d'

With no clue as to what this means, I read the source file buildme.d,
and discover that it appears to support two versions, Phobos, and
something else, presumably Tango.  So, I read the dmd doc to see how
to set this flag (dmd -Dversion=Phobos didn't work).  Finding that,
I try again, and fail again:

% dmd -version=Phobos -run buildme.d all
sh: bud: command not found

So, I try to find bud.  I go back to the dlinks page and find it
and download it, and attempt to build IT:

% cd bud-3.04

The instructions say:

If you have no existing binary, the executable must be built with
the makefile first:

make -f Makefile.unix

So, I try that:

% make -f Makefile.unix
make: Makefile.unix: No such file or directory
make: *** No rule to make target `Makefile.unix'.  Stop.

Ah, ok.  Let's see what's wrong now:

% ls
Source

Ok, would have been nice to document that, but forging ahead...

% cd Source
% make -f Makefile.unix
dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d util/str_bn.d
source.d util/fdt.d util/fileex.d util/fileex_bn.d util/linetoken.d
util/linetoken_bn.d util/macro.d util/file2.d
build.d(56): Identifier expected following package
build.d(56): ';' expected
build.d(634): identifier expected following '.', not 'macro'
build.d(3348): identifier expected following '.', not 'macro'
source.d(55): Identifier expected following package
source.d(55): ';' expected
source.d(105): Identifier expected following package
source.d(105): ';' expected
source.d(483): identifier expected following '.', not 'macro'
util/macro.d(38): Identifier expected following package
make: *** [build] Error 1

So, the build tool itself advertised to build the tool I want to use
fails to build.  Irony...

So, I discover after a long set of searches and guess on my part that
'util.macro' should perhaps be 'util.Macro'.  I make those substitutions
in the bud source code and the build of it finally works:

% make -f Makefile.unix
dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d util/str_bn.d
source.d util/fdt.d util/fileex.d util/fileex_bn.d util/linetoken.d
util/linetoken_bn.d util/macro.d util/file2.d

Noting that the bud build instructions also say:

It is still imperative to build a final binary with the utility itself:

    ./build build -full -op
    ln -s build bud

So:

% ./build build -full -op
Source.d(55): module Macro cannot read file 'util/Macro.d'

Of course not.  So, I move util/macro.d to util/Macro.d:

% mv util/macro.d util/Macro.d

try again:

% ./build build -full -op
/usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for
-lphobos
/usr/bin/ld: cannot find -lphobos
collect2: ld returned 1 exit status

Usure how a freshly installed libphobos.a from the freshly installed dmd
package could be a problem:

% which dmd
/opt/dmd/bin/dmd
% ls -l /opt/dmd/lib/libphobos.a
-rw-r--r-- 1 rael rael 1344630 2008-05-16 23:01 /opt/dmd/lib/libphobos.a
% ls -l /usr/lib/libphobos.a
-rw-r--r-- 1 root root 1344630 2008-05-28 14:17 /usr/lib/libphobos.a
% cmp /opt/dmd/lib/libphobos.a /usr/lib/libphobos.a
% echo $?
0

So, the files are identical...

Oh, and here's another cool thing:

% ls -l build
ls: cannot access build: No such file or directory

So, the build failure erases the build file itself.  Very, very cool.

So, rebuild from makefile:

% make -f Makefile.unix
make: *** No rule to make target `util/macro.d', needed by `build'.  Stop.

Of course.  So, I link util/Macro.d to util/macro.d:

% cd util/
% ln -s Macro.d macro.d
% cd ..
% make -f Makefile.unix
dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d util/str_bn.d
source.d util/fdt.d util/fileex.d util/fileex_bn.d util/linetoken.d
util/linetoken_bn.d util/macro.d util/file2.d

And now, move build to something else, perhaps?:

% mv build buildit
% ./buildit build -full -op
/usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for
-lphobos
/usr/bin/ld: cannot find -lphobos
collect2: ld returned 1 exit status

And now I discover that since I have a 64-bit machine, perhaps I am
just totally hosed?

dmd itself seems to work fine:

% cd /opt/dmd/samples/d/
% dmd wc.d
% echo "Hello world" | ./wc
% ./wc wc.d
   lines   words   bytes file
      45      80     810 wc.d

So, what the hell, I'll try with the version of bud built from the makefile
and see if that is good enough:

% cp buildit ~/bin
% cd /build/tags/0.25
% dmd -version=Phobos -run buildme.d all
Error: dbi/all.d: Permission denied

Lovely, more permissions errors:

% ls -l dbi/all.d
---------- 1 rael rael 250 2007-02-03 01:21 dbi/all.d

So, fix them:

% find . -type f | xargs chmod +rw

and try again:

%  dmd -version=Phobos -run buildme.d all
dbi/oracle/imp/orl.d(1147): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1147): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1147): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1188): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1188): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1188): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1200): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1200): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1200): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1216): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1216): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1216): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1231): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1231): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1231): Declaration expected, not ','
dbi/oracle/imp/ori.d(404): found 'ref' when expecting ')'
dbi/oracle/imp/ori.d(404): semicolon expected following function declaration
dbi/oracle/imp/ori.d(404): Declaration expected, not ')'
dbi/oracle/imp/ori.d(1106): found 'ref' when expecting ')'
dbi/oracle/imp/ori.d(1106): semicolon expected following function declaration
dbi/oracle/imp/ori.d(1106): Declaration expected, not ')'

Ok, it's building oracle.  I don't really want oracle.  The code
says I can pass '-mysql'.  Try that:

% dmd -version=Phobos -run buildme.d -mysql
Error: Invalid argument "-mysql."  "mysql" isn't on the list of DBDs to build.

Try again:

% dmd -version=Phobos -run buildme.d mysql

Hmm, no errors, no nothing.  What did it do?

% ls -lt
total 36
drwxr-xr-x 10 rael rael 4096 2008-05-28 16:03 dbi
drwxr-xr-x  2 rael rael 4096 2008-05-28 16:03 libddbi.a
drwxr-xr-x  3 rael rael 4096 2008-05-28 15:52 docs
-rw-r--r--  1 rael rael 4478 2007-02-03 01:21 buildme.d

% ls -l libddbi.a/
total 0
% ls -lt dbi/
total 264
-rw-r--r-- 1 rael rael 124890 2008-05-28 16:03 all.a
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 ib
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 msql
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mssql
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mysql
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 odbc
drwxr-xr-x 3 rael rael   4096 2008-05-28 15:52 oracle
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 pg
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 sqlite
-rw-r--r-- 1 rael rael    250 2007-02-03 01:21 all.d
-rw-r--r-- 1 rael rael   5813 2007-02-03 01:21 Database.d
-rw-r--r-- 1 rael rael   2658 2007-02-03 01:21 DBIException.d
-rw-r--r-- 1 rael rael   2500 2007-02-03 01:21 ErrorCode.d
-rw-r--r-- 1 rael rael   1192 2007-02-03 01:21 Result.d
-rw-r--r-- 1 rael rael   4194 2007-02-03 01:21 Row.d
-rw-r--r-- 1 rael rael   6736 2007-02-03 01:21 Statement.d

Hm, ok, we have an 'all.a' file and some .d files, so presumably
we'll have to install these somewhere.  No clue if it actually
built what I wanted ... There is no install
target, it appears (thank goodness we're not using make!).  So, we
look for example code on the web site:

Another recommended way to learn how to use D DBI is to look at the
unittests in the SqliteDatabase file.

When I click on the link:

Internal Server Error

500 Internal Server Error (No node /trunk/dbi/sqlite/sqlitedatabase.d at
revision 91<br><p>You can <a
href="/projects/ddbi/log/trunk/dbi/sqlite/sqlitedatabase.d?rev=91&amp;mode=path_history">search</a>
in the repository history to see if that path existed but was later
removed.</p>)

Oops...

So, I try to run the unit test code.  Guessing:

% dmd -version=Phobos -run dbi/mysql/MysqlDatabase.d dbi/all.a -lmysqlclient
[big fat failure]

Try again:

%  dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
-lmysqlclient
Error: unrecognized switch '-lmysqlclient'

and again:

% dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
[... vast spewage ...]

Well, ok, try again:

% dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
-L'-L/usr/lib/mysql -lmysqlclient'

and more failures.

Try again:

% dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
/usr/lib/mysql/libmysqlclient.a

Well, it gets by the undefined references to mysql internals, but of course
new undefined errors show up.

[More tail chasing elided here for sake of space.]

At this point, I've wasted, not "20 minutes" as claimed here, but a solid
2 1/2 hours of my time.

I do hope others realize that I have gone to the trouble to document this not
to impugn anyone's motives, but to provide what I think is a valuable service
to the D community, while at the same time declining to join said community due
to professional and personal time constraints.

Perhaps I'll return to this effort tomorrow and see if I can kick it along any
further, but I rather doubt I will, as even if I do get the thing to compile,
my confidence in the entire body of code is so low that I am loathe to
recommend that our development group even consider it for production-ready code.

Some observations:

1) Using "yet another make system" to build dbi seems of dubious benefit.

2) Even the most basic issues do not go well --- the source code wouldn't even
unzip properly.

3) If users are to adopt D, then the support universe around it needs to be
strengthened.  Anything more than a few keystrokes' to install something is
going to turn away potential legions of followers.  I'd like to see this:

% dinstall dbi
DBI is now installed for D.  Have fun.

And I think that is a reasonable goal to aim for.

As I said, I just don't have the time presently to contribute any more than I
have to this, and I hope this will help the D community in some way.

Thanks.


Bill
May 28 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Lear wrote:

 Thanks to all for the (mostly) thoughtful comments on this issue.  I
 have tried again, this time documenting my steps, to more thouroughly
 illustrate what I am going through.  Here is a more-or-less verbatim
 run of my efforts to get dbi compiled and installed.  To say the
 least, the results are less than satisfying:


Thanks for taking the time and effort to document what is going wrong. 
This is very valuable information.
May 28 2008
prev sibling next sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Wed, 28 May 2008 22:44:14 +0100, Bill Lear <rael zopyra.com> wrote:

[Too much to usefully summarise...]

It sounds like one problem is that this DBI package is being maintained  
mostly on Windows.
The case sensitivity issues are a dead give away. This would also explain  
the permissions
problems and probably the library ones too.
You are effectively doing the porting work for this package so its no  
surprise you are
struggling to get something up and running quickly. Porting something when  
you are working
with a known toolchain is one thing but doing it with tools you are less  
familiar with is
going to be a struggle.
Perhaps there is a more appropriate tool-chain and or library choice  
available for your needs
already. Then again maybe not given the rest of this thread. There is  
(someone will correct
me if I'm wrong) some consensus that gdc is the way to go on linux.  
Especially if you are
only intending to use D v1 and not v2 (in spite of all the extra coolness  
it makes available).

Regards,

Bruce.
May 28 2008
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Lear wrote:


 Sean Kelly Wrote:
 [...]

 I agree with your comment on tools and libraries in general, but D does
 already have a solid
 install/update/build tool in DSSS/rebuild.  With it, installing supported
 packages is as simple as "dsss net install blah", which I believe is
 roughly equivalent to ruby gems or whatever you
 used there instead.  Regarding DB support, I think some branch of DDBI
 may actually build with the current version of D, but you're right that
 it doesn't receive a lot of attention. Unfortunately, D is still very
 much a language for self-starters, and the overarching focus on newer and
 more features rather than building a solid base for development probably
 doesn't help things either.  Overall, the trend seems to be a churn of
 new users rather than
 a growing group of serious professionals--likely for these reasons.  That
 said, there are more than a few professional developers which have found
 a development environment which suits them--from my experience it tends
 to be DMD/Linux and Tango with either makefiles or DSSS for building and
 GDB with the demangling patch for debugging.


 
 Thanks to all for the (mostly) thoughtful comments on this issue.  I have
 tried again, this time documenting my steps, to more thouroughly
 illustrate what I am going through.  Here is a more-or-less verbatim run
 of my efforts to get dbi compiled and installed.  To say the least, the
 results are less than satisfying: Download and install d 1.030.
 
 Go to D web site to find OBI component.  Look for something that
 indicates "tools", or "libraries" for D.  See "Tools" section.
 Look in "More Tools" link.  Nothing there, so back to the
 main page.  Look under "Community"/"D links".  Looks good.
 Using Firebugs, search for "Database" on the page.  Find D DBI.
 Ok, click it.
 
 Look for "downloads".  Find "Recommended" is "Version 0.2.5", so
 download that to my build directory and unzip the zip file.
 
 Look for and find doc on "HowToBuild".  It says:
 
 The current recommended way to build dbi.lib is to use buildme.d. It comes
 in the directory below dbi.
 
 To build a release version of D DBI with every module, use any of
 the following:
 
     dmd -run buildme.d all
 
 So, I try the first command:
 
 % cd tags/0.2.5
 % dmd -run buildme.d all
 buildme.d: module buildme cannot read file 'buildme.d'
 
 So, it fails because it cannot read the file.  So, I figure out why:
 
 ls -l
 total 28
 ----------  1 rael rael 4478 2007-02-03 01:21 buildme.d
 drwxr-xr-x 10 rael rael 4096 2008-05-28 15:02 dbi
 drwxr-xr-x  3 rael rael 4096 2008-05-28 15:02 docs
 
 It has unzipped things with no read permissions.  So, I fix it and try
 again:
 
 % chmod +rw buildme.d
 % dmd -run buildme.d all
 buildme.d(42): module FileConst cannot read file 'tango/io/FileConst.d'
 
 With no clue as to what this means, I read the source file buildme.d,
 and discover that it appears to support two versions, Phobos, and
 something else, presumably Tango.  So, I read the dmd doc to see how
 to set this flag (dmd -Dversion=Phobos didn't work).  Finding that,
 I try again, and fail again:
 
 % dmd -version=Phobos -run buildme.d all
 sh: bud: command not found
 
 So, I try to find bud.  I go back to the dlinks page and find it
 and download it, and attempt to build IT:
 
 % cd bud-3.04
 
 The instructions say:
 
 If you have no existing binary, the executable must be built with
 the makefile first:
 
 make -f Makefile.unix
 
 So, I try that:
 
 % make -f Makefile.unix
 make: Makefile.unix: No such file or directory
 make: *** No rule to make target `Makefile.unix'.  Stop.
 
 Ah, ok.  Let's see what's wrong now:
 
 % ls
 Source
 
 Ok, would have been nice to document that, but forging ahead...
 
 % cd Source
 % make -f Makefile.unix
 dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
 source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d
 util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d
 util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
 build.d(56): Identifier expected following package build.d(56): ';'
 expected build.d(634): identifier expected following '.', not 'macro'
 build.d(3348): identifier expected following '.', not 'macro'
 source.d(55): Identifier expected following package source.d(55): ';'
 expected source.d(105): Identifier expected following package
 source.d(105): ';' expected source.d(483): identifier expected following
 '.', not 'macro' util/macro.d(38): Identifier expected following package
 make: *** [build] Error 1
 
 So, the build tool itself advertised to build the tool I want to use
 fails to build.  Irony...
 
 So, I discover after a long set of searches and guess on my part that
 'util.macro' should perhaps be 'util.Macro'.  I make those substitutions
 in the bud source code and the build of it finally works:
 
 % make -f Makefile.unix
 dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
 source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d
 util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d
 util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
 
 Noting that the bud build instructions also say:
 
 It is still imperative to build a final binary with the utility itself:
 
     ./build build -full -op
     ln -s build bud
 
 So:
 
 % ./build build -full -op
 Source.d(55): module Macro cannot read file 'util/Macro.d'
 
 Of course not.  So, I move util/macro.d to util/Macro.d:
 
 % mv util/macro.d util/Macro.d
 
 try again:
 
 % ./build build -full -op
 /usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for
 -lphobos /usr/bin/ld: cannot find -lphobos
 collect2: ld returned 1 exit status
 
 Usure how a freshly installed libphobos.a from the freshly installed dmd
 package could be a problem:
 
 % which dmd
 /opt/dmd/bin/dmd
 % ls -l /opt/dmd/lib/libphobos.a
 -rw-r--r-- 1 rael rael 1344630 2008-05-16 23:01 /opt/dmd/lib/libphobos.a
 % ls -l /usr/lib/libphobos.a
 -rw-r--r-- 1 root root 1344630 2008-05-28 14:17 /usr/lib/libphobos.a
 % cmp /opt/dmd/lib/libphobos.a /usr/lib/libphobos.a
 % echo $?
 0
 
 So, the files are identical...
 
 Oh, and here's another cool thing:
 
 % ls -l build
 ls: cannot access build: No such file or directory
 
 So, the build failure erases the build file itself.  Very, very cool.
 
 So, rebuild from makefile:
 
 % make -f Makefile.unix
 make: *** No rule to make target `util/macro.d', needed by `build'.  Stop.
 
 Of course.  So, I link util/Macro.d to util/macro.d:
 
 % cd util/
 % ln -s Macro.d macro.d
 % cd ..
 % make -f Makefile.unix
 dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
 source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d
 util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d
 util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
 
 And now, move build to something else, perhaps?:
 
 % mv build buildit
 % ./buildit build -full -op
 /usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for
 -lphobos /usr/bin/ld: cannot find -lphobos
 collect2: ld returned 1 exit status
 
 And now I discover that since I have a 64-bit machine, perhaps I am
 just totally hosed?
 
 dmd itself seems to work fine:
 
 % cd /opt/dmd/samples/d/
 % dmd wc.d
 % echo "Hello world" | ./wc
 % ./wc wc.d
    lines   words   bytes file
       45      80     810 wc.d
 
 So, what the hell, I'll try with the version of bud built from the
 makefile and see if that is good enough:
 
 % cp buildit ~/bin
 % cd /build/tags/0.25
 % dmd -version=Phobos -run buildme.d all
 Error: dbi/all.d: Permission denied
 
 Lovely, more permissions errors:
 
 % ls -l dbi/all.d
 ---------- 1 rael rael 250 2007-02-03 01:21 dbi/all.d
 
 So, fix them:
 
 % find . -type f | xargs chmod +rw
 
 and try again:
 
 %  dmd -version=Phobos -run buildme.d all
 dbi/oracle/imp/orl.d(1147): found 'ref' when expecting ')'
 dbi/oracle/imp/orl.d(1147): semicolon expected following function
 declaration dbi/oracle/imp/orl.d(1147): Declaration expected, not ')'
 dbi/oracle/imp/orl.d(1188): found 'ref' when expecting ')'
 dbi/oracle/imp/orl.d(1188): semicolon expected following function
 declaration dbi/oracle/imp/orl.d(1188): Declaration expected, not ')'
 dbi/oracle/imp/orl.d(1200): found 'ref' when expecting ')'
 dbi/oracle/imp/orl.d(1200): semicolon expected following function
 declaration dbi/oracle/imp/orl.d(1200): Declaration expected, not ')'
 dbi/oracle/imp/orl.d(1216): found 'ref' when expecting ')'
 dbi/oracle/imp/orl.d(1216): semicolon expected following function
 declaration dbi/oracle/imp/orl.d(1216): Declaration expected, not ')'
 dbi/oracle/imp/orl.d(1231): found 'ref' when expecting ')'
 dbi/oracle/imp/orl.d(1231): semicolon expected following function
 declaration dbi/oracle/imp/orl.d(1231): Declaration expected, not ','
 dbi/oracle/imp/ori.d(404): found 'ref' when expecting ')'
 dbi/oracle/imp/ori.d(404): semicolon expected following function
 declaration dbi/oracle/imp/ori.d(404): Declaration expected, not ')'
 dbi/oracle/imp/ori.d(1106): found 'ref' when expecting ')'
 dbi/oracle/imp/ori.d(1106): semicolon expected following function
 declaration dbi/oracle/imp/ori.d(1106): Declaration expected, not ')'
 
 Ok, it's building oracle.  I don't really want oracle.  The code
 says I can pass '-mysql'.  Try that:
 
 % dmd -version=Phobos -run buildme.d -mysql
 Error: Invalid argument "-mysql."  "mysql" isn't on the list of DBDs to
 build.
 
 Try again:
 
 % dmd -version=Phobos -run buildme.d mysql
 
 Hmm, no errors, no nothing.  What did it do?
 
 % ls -lt
 total 36
 drwxr-xr-x 10 rael rael 4096 2008-05-28 16:03 dbi
 drwxr-xr-x  2 rael rael 4096 2008-05-28 16:03 libddbi.a
 drwxr-xr-x  3 rael rael 4096 2008-05-28 15:52 docs
 -rw-r--r--  1 rael rael 4478 2007-02-03 01:21 buildme.d
 
 % ls -l libddbi.a/
 total 0
 % ls -lt dbi/
 total 264
 -rw-r--r-- 1 rael rael 124890 2008-05-28 16:03 all.a
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 ib
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 msql
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mssql
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mysql
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 odbc
 drwxr-xr-x 3 rael rael   4096 2008-05-28 15:52 oracle
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 pg
 drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 sqlite
 -rw-r--r-- 1 rael rael    250 2007-02-03 01:21 all.d
 -rw-r--r-- 1 rael rael   5813 2007-02-03 01:21 Database.d
 -rw-r--r-- 1 rael rael   2658 2007-02-03 01:21 DBIException.d
 -rw-r--r-- 1 rael rael   2500 2007-02-03 01:21 ErrorCode.d
 -rw-r--r-- 1 rael rael   1192 2007-02-03 01:21 Result.d
 -rw-r--r-- 1 rael rael   4194 2007-02-03 01:21 Row.d
 -rw-r--r-- 1 rael rael   6736 2007-02-03 01:21 Statement.d
 
 Hm, ok, we have an 'all.a' file and some .d files, so presumably
 we'll have to install these somewhere.  No clue if it actually
 built what I wanted ... There is no install
 target, it appears (thank goodness we're not using make!).  So, we
 look for example code on the web site:
 
 Another recommended way to learn how to use D DBI is to look at the
 unittests in the SqliteDatabase file.
 
 When I click on the link:
 
 Internal Server Error
 
 500 Internal Server Error (No node /trunk/dbi/sqlite/sqlitedatabase.d at
 revision 91<br><p>You can <a


href="/projects/ddbi/log/trunk/dbi/sqlite/sqlitedatabase.d?rev=91&amp;mode=path_history">search</a>

 in the repository history to see if that path existed but was later
 removed.</p>)
 
 Oops...
 
 So, I try to run the unit test code.  Guessing:
 
 % dmd -version=Phobos -run dbi/mysql/MysqlDatabase.d dbi/all.a
 -lmysqlclient
 [big fat failure]
 
 Try again:
 
 %  dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
 -lmysqlclient Error: unrecognized switch '-lmysqlclient'
 
 and again:
 
 % dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
 [... vast spewage ...]
 
 Well, ok, try again:
 
 % dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
 -L'-L/usr/lib/mysql -lmysqlclient'
 
 and more failures.
 
 Try again:
 
 % dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a
 /usr/lib/mysql/libmysqlclient.a
 
 Well, it gets by the undefined references to mysql internals, but of
 course new undefined errors show up.
 
 [More tail chasing elided here for sake of space.]
 
 At this point, I've wasted, not "20 minutes" as claimed here, but a solid
 2 1/2 hours of my time.
 
 I do hope others realize that I have gone to the trouble to document this
 not to impugn anyone's motives, but to provide what I think is a valuable
 service to the D community, while at the same time declining to join said
 community due to professional and personal time constraints.
 
 Perhaps I'll return to this effort tomorrow and see if I can kick it along
 any further, but I rather doubt I will, as even if I do get the thing to
 compile, my confidence in the entire body of code is so low that I am
 loathe to recommend that our development group even consider it for
 production-ready code.
 
 Some observations:
 
 1) Using "yet another make system" to build dbi seems of dubious benefit.
 
 2) Even the most basic issues do not go well --- the source code wouldn't
 even unzip properly.
 
 3) If users are to adopt D, then the support universe around it needs to
 be strengthened.  Anything more than a few keystrokes' to install
 something is going to turn away potential legions of followers.  I'd like
 to see this:
 
 % dinstall dbi
 DBI is now installed for D.  Have fun.
 
 And I think that is a reasonable goal to aim for.
 
 As I said, I just don't have the time presently to contribute any more
 than I have to this, and I hope this will help the D community in some
 way.
 
 Thanks.
 
 
 Bill


Thank you - I will save this for later reference.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 29 2008
prev sibling parent Jacob Carlborg <doobnet gmail.com> writes:
Bill Lear wrote:

 [...]


First I can say that there are two runtime libraries available, the 
standard library Phobos and the alternative community developed runtime 
library Tango.

The problems you have with bud is that it's code is very old and D has 
introduced new keywords (ref, macro) since then which conflicts with the 
module and variable names. If you want to build bud then you have to 
change all the module and variable names that conflicts with the new 
keywords, this includes both source files and make files. But I think 
you should use dsss (see below) instead.

dmd is not 64bit compatible so you have to use gdc or dmd with 32bit 
libraries.


 % dinstall dbi
 DBI is now installed for D.  Have fun.


This can be done with the dsss tool:
dsss net install ddbi

This will download, compile and install ddbi.

I think the best and easiest way to get D (and Tango) working is 
downloading a tango bundle (D compiler with the Tango runtime library 
pre-compiled) which exists for the platforms osx,linux and windows and 
then download dsss as a pre-compiled binary.

dmd bundled with Tango for windows and linux: 
http://www.dsource.org/projects/tango/wiki/DmdDownloads

gdc bundled with Tango for linux and osx:
http://www.dsource.org/projects/tango/wiki/GdcDownloads

pre-compiled dsss binary for linux, windows and osx:
http://svn.dsource.org/projects/dsss/downloads/0.75/

I completely agree with you that the lack of documentation is a big 
problem, I know that it was for me when I started, and I had big 
problems before I found the right tools to use.

BTW I think ddbi is going through some changes and I've seen that other 
people have problems with it.
May 30 2008
prev sibling next sibling parent torhu <no spam.invalid> writes:
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.


Did you ask on the newsgroup or the ddbi forum?  These questions are 
easily answered by almost anyone familiar with how things work D world. 
  The last commit in ddbi svn[1] was two weeks ago, so it's reasonable 
to assume that ddbi works with dmd 1.028, which is the latest stable 
compiler version[2].  From reading the log, it's also clear that Tango 
is supported, and Phobos support has been removed.

And the version in svn also seems to support building with dsss, which I 
would recommend over bud for linux use.  Of course, this assumes that 
you're prepared to use an unreleased, work-in-progress version of the 
library...

That said, I agree that the state of D tools and libraries is not what 
it should have been.  Most projects are run by a single person, some 
work well on one platform but not others, etc.  Some projects are of 
good quality though, the best example probably being Tango.  Another 
problem is that dsource doesn't give you a way to distinguish the 
mature, actively maintained projects from the ones that are abandoned or 
not quite ready yet.

[1] http://www.dsource.org/projects/ddbi/log/
[2] http://www.digitalmars.com/d/download.html
May 19 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Lear:

 We settled on ruby,


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. So to me it's
strange that seeing D unfit, you have used Ruby.



 I think some serious attention needs to be focused on this, rather than the
minutiae of the latest cool language feature.


I think D is younger and it's used by quite less people, so you have not even
1/100 of the modules you can find in the Python world (there are some modules
available thanks to the easy binding to C libs).
I think D language focuses on language features because it's developing still,
because it's looking for its place in the world still. I think that if D
succeeds in the parallel programming it may have a chance to become widely used

languages able to use the future multi core CPUs. Among them something like
Haskell looks one of the more promising, despite being a bit too much complex
to become an industry standard language).

Bye,
bearophile
May 19 2008
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
bearophile schrieb:

 Bill Lear:

 We settled on ruby,


 
 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. So to me it's
strange that seeing D unfit, you have used Ruby.


and disqualify a "language" because of missing working database libs - 
strange base decision ...
May 19 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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.
May 19 2008
parent reply "Simen Haugen" <simen.haugen pandavre.com> writes:
"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.
May 20 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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).
May 20 2008
parent reply "Simen Haugen" <simen.haugen pandavre.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g0uoob$2htb$1 digitalmars.com...

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


Yes, that was the think I was thinking of. But with more reflection instead 
of templates this can be fixed.
May 21 2008
parent BCS <ao pathlink.com> writes:
Reply to Simen,


 Yes, that was the think I was thinking of. But with more reflection
 instead of templates this can be fixed.
 


If I'm reading you correctly, "this" can't be fixed. The symbol length limit 
is fixed by the file format and can't be changed. OTOH several ways to sidestep 
it by reducing symbol lengths have bean proposed but not implemented for 
various reasons.
May 21 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Lear wrote:
 

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


 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 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. At the very
least the community needs to know what you as a potential user needs from
the project, so that tasks can be prioritized. Most of D still being open
source, one cannot normally expect anything to happen without contributing
self at some level. Posting your summary here may or may not help, but
going to the specific project will always be best. Not all in the D
community follow these newsgroups regularly.

An example of how I think a company could get involved to help D move on, is
how the work I will do on DDBI is sponsored (part time) by a company that
plans to use D commerically. In light of that, now may be the right time to
get involved in that particular project.
 

 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 :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 19 2008
next sibling parent reply Ty Tower <tytower yahoo.com.au> writes:
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?


At the very
 least the community needs to know what you as a potential user needs from
 the project, so that tasks can be prioritized. Most of D still being open
 source, one cannot normally expect anything to happen without contributing
 self at some level. Posting your summary here may or may not help, but
 going to the specific project will always be best. Not all in the D
 community follow these newsgroups regularly.


He has just told you !

 
 An example of how I think a company could get involved to help D move on, is
 how the work I will do on DDBI is sponsored (part time) by a company that
 plans to use D commerically. In light of that, now may be the right time to
 get involved in that particular project.


Give me some money and I will help you !

  

 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 :)
 
 -- 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


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?

From what I have seen it is a mess but listening to people like this and DOING
SOMETHING ABOUT IT would be a good start . Don't start on me ! I am still here
and contributing with posts wherever I see stupidity, or where somethiong does
not work properly, but I am no master programmer so I can't fix it.
May 19 2008
next sibling parent reply Chris R. Miller <lordSaurontheGreat gmail.com> writes:
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 :)
 


 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 found that it compiled into a library with DMD 1.030, though I haven't
verified to see if it works beyond that point.  Neither 1.029 or 1.030 are
stable, so they really don't count much.


 From what I have seen it is a mess but listening to people like this and DOING
SOMETHING ABOUT IT would be a good start . Don't start on me ! I am still here
and contributing with posts wherever I see stupidity, or where somethiong does
not work properly, but I am no master programmer so I can't fix it.


The obvious solution is to write more code.

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!
May 19 2008
parent reply Clay Smith <clayasaurus gmail.com> writes:
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.
May 20 2008
next sibling parent reply BCS <ao pathlink.com> writes:
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.
May 20 2008
parent reply "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
BCS wrote:

 Reply to Clay,
=20

 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.


=20
 That said, you have given nothing to the end user until you start=20
 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=20
 failed because they didn't want to be done designing it.


Yes, that's more or less his point.  You can always rewrite a bad=20
system, or anything else.  Whatever you call it, you can always polish=20
the turd later, but getting something - anything - would be an imperative=
=2E
May 20 2008
parent reply "Me Here" <p9e883002 sneakemail.com> writes:
Chris R. Miller wrote:


 BCS wrote:
Whatever you call it, you can always polish the turd later, 


I'm not normally of a weak disposition, but please don't post video of your
polishing attempts.

Unless, by "later", you mean far enough in the future that we're talking
coprolites :)

b.
--
May 20 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Me,


 Chris R. Miller wrote:
 

 Whatever you call it, you can always polish the turd later,


 I'm not normally of a weak disposition, but please don't post video of
 your polishing attempts.
 
 Unless, by "later", you mean far enough in the future that we're
 talking coprolites :)
 
 b.
 


it's (I hope) a figure of speech.
May 20 2008
parent "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
BCS wrote:

 Reply to Me,
=20

 Chris R. Miller wrote:


 Whatever you call it, you can always polish the turd later,


 I'm not normally of a weak disposition, but please don't post video of=





 your polishing attempts.

 Unless, by "later", you mean far enough in the future that we're
 talking coprolites :)

 b.


=20
 it's (I hope) a figure of speech.


It's a rather rude figure of speech I picked up from my dad.  It's=20
basically a euphemism for continuing to work on a project that already=20
suits your purposes, though especially if it's for the wants of someone=20
else.  For instance, I worked on a poster project for a class once to=20
the point that it was more than good enough for me, but I "polished the=20
turd" some more to meet the teacher's expectations.  It's also used to=20
point some wry doubtfulness to the overall value of the project (hence=20
the turd allusion).

Sorry for the confusion, I forget that this is an international group=20
and not everyone is familiar with all the little idioms in English.
May 20 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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? :-)
May 20 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Ary Borenszweig wrote:

 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? :-)


Absolutist statements are /always/ wrong.

(...including that one :-))

--bb
May 20 2008
prev sibling next sibling parent Chris R. Miller <lordSaurontheGreat gmail.com> writes:
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.
May 20 2008
prev sibling next sibling parent reply Daniel Giddings <daniel.giddings gmail.com> writes:
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.


Your first design will either be wrong or take forever! (at least a lot 
longer than it need as you make decisions based on lack of experience 
with the problem)

Better to start with a minimal design and then prototype and iterate. 
Set up your development process to deal with design changes and code 
refactoring.
May 20 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Daniel,


 Your first design will either be wrong or take forever! (at least a
 lot longer than it need as you make decisions based on lack of
 experience with the problem)
 
 Better to start with a minimal design and then prototype and iterate.
 Set up your development process to deal with design changes and code
 refactoring.
 


Or better yet, work with a system that allows you to define how to derive 
the implementation from your design.

Then the only thing you need to iterate on is the design and the derivation 
rules (and they can be reused for the next project).

(Darn where did this soapbox I'm standing on come from <G>)
May 20 2008
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Giddings" <daniel.giddings gmail.com> wrote in message 
news:g0vmk1$1qfk$1 digitalmars.com...

 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.




That would certainly be true if you're using the waterfall method.


 Your first design will either be wrong or take forever! (at least a lot 
 longer than it need as you make decisions based on lack of experience with 
 the problem)

 Better to start with a minimal design and then prototype and iterate. Set 
 up your development process to deal with design changes and code 
 refactoring.


That's been exactly my experience.

No matter what strategy you use, your first approach (or two, or three) is 
going to be wrong, period, regardless of how much thought you put into it. 
It's just a fact of programmer life. So you can either waste your time 
pretending you have a shot in hell of getting it right the first time, or 
you can play around with a compiler *while* you're brainstorming to get hard 
instant feedback instead of operating on speculation. A compiler should be 
one of your design-time tools.

Forcing a long code-less "design" stage is like agonizing over your code 
before compiling to make sure there's no syntax errors. Just compile the 
damn thing. It'll tell you if it's wrong (provided the language doesn't 
suck, but that's a different discussion ;) ).

That said, there are times when it can be good to sit back, think, and not 
touch the editor. But the real test to see how much 
"think/paper-n-pencil/UML" you should be doing, versus 
"implement/prototype/iterate" is "How much work will this take to try out?" 
The more work it takes to actually try out an idea, the more upfront thought 
you should put into it. But more often than not, anything you can play 
around with in UML structure diagrams is also going to be very easy and 
productive to play around with in actual code, even if you have to use a lot 
of stubs for "to-be-implemented" functionality.
May 21 2008
parent BCS <ao pathlink.com> writes:
Reply to Nick,


 
 No matter what strategy you use, your first approach (or two, or
 three) is going to be wrong, period, regardless of how much thought
 you put into it. It's just a fact of programmer life. So you can
 either waste your time pretending you have a shot in hell of getting
 it right the first time, or you can play around with a compiler
 *while* you're brainstorming to get hard instant feedback instead of
 operating on speculation. A compiler should be one of your design-time
 tools.
 


I'd love to see a compiler that can pick out the kind of issues I worry about. 
(Logic errors etc.)


 Forcing a long code-less "design" stage is like agonizing over your
 code before compiling to make sure there's no syntax errors.
 
 But the real test [...] is "How much work will this take to try
 out?" The more work it takes to actually try out an idea, the more
 upfront thought you should put into it.


The prime issue of that is that people don't like throwing stuff out. If 
the developer is very willing to hit delete and go for a total re wright 
the above becomes much more viable. But if they are very willing to munge 
what they have into what they need you can start running into issues: "this 
is the design we have, so lest work with it"

That all said, a lot of the coolest stuff I've done couldn't be designed 
on a blackboard because it's been related to exploring the corners of the 
compiler.
May 21 2008
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
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.


UML class diagrams and UML sequence diagrams are not design; they are 
programming. Programming in a language with no compiler, programming 
without including your core algorithms, programming without any tests. 
There's no way in hell you can verify your design will be even remotely 
close to something that can work.

You can safely and usefully design at a higher level before writing any 
code, but not on the class level.
May 21 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Chris,


 UML class diagrams and UML sequence diagrams are not design; they are
 programming. Programming in a language with no compiler, programming
 without including your core algorithms, programming without any tests.
 There's no way in hell you can verify your design will be even
 remotely close to something that can work.
 
 You can safely and usefully design at a higher level before writing
 any code, but not on the class level.
 


I beg to differ. The one and only time I used UML it was very useful. It 
helped me track a number of aspects of the design and brought to light a 
number of deficiencies. I'd say UML is a design "tool" but in the way that 
Word or a pad of paper can be, as an aid to documentation.
May 21 2008
parent reply Chris Wright <dhasenan gmail.com> writes:
BCS wrote:

 Reply to Chris,
 

 UML class diagrams and UML sequence diagrams are not design; they are
 programming. Programming in a language with no compiler, programming
 without including your core algorithms, programming without any tests.
 There's no way in hell you can verify your design will be even
 remotely close to something that can work.

 You can safely and usefully design at a higher level before writing
 any code, but not on the class level.


 
 I beg to differ. The one and only time I used UML it was very useful. It 
 helped me track a number of aspects of the design and brought to light a 
 number of deficiencies. I'd say UML is a design "tool" but in the way 
 that Word or a pad of paper can be, as an aid to documentation.


You were using UML class diagrams. Were you generating code from UML, or 
UML from code?

If you want to use UML to document existing code, that has always 
sounded like a good idea to me. You don't have to wade through code and 
comments to get an idea of what's going on. But in this case, you MUST 
use UML that's autogenerated from your code. Otherwise, your UML 
documentation will branch away from your code.
May 21 2008
parent BCS <ao pathlink.com> writes:
Reply to Chris,


 BCS wrote:
 

 Reply to Chris,
 

 UML class diagrams and UML sequence diagrams are not design; they
 are programming. Programming in a language with no compiler,
 programming without including your core algorithms, programming
 without any tests. There's no way in hell you can verify your design
 will be even remotely close to something that can work.
 
 You can safely and usefully design at a higher level before writing
 any code, but not on the class level.
 


 I beg to differ. The one and only time I used UML it was very useful.
 It helped me track a number of aspects of the design and brought to
 light a number of deficiencies. I'd say UML is a design "tool" but in
 the way that Word or a pad of paper can be, as an aid to
 documentation.
 


 You were using UML class diagrams. Were you generating code from UML,
 or UML from code?
 


Not yet. The project the design was for got back burnered so no actual code 
has been written yet.

Aside: I've though it might be interesting to do a mid size project where 
the only people allowed to touch the actual code are interns. The "real" 
programmers are only allowed to work on the spec and design. But they are 
allowed to design to the point their there really isn't anything left that 
a C average CS sophomore couldn't handle.


 If you want to use UML to document existing code, that has always
 sounded like a good idea to me. You don't have to wade through code
 and comments to get an idea of what's going on. But in this case, you
 MUST use UML that's autogenerated from your code. Otherwise, your UML
 documentation will branch away from your code.
 


The other option is to fully generate the code from the UML. Either way one 
is golden and the other is generated.
May 22 2008
prev sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Chris Wright" <dhasenan gmail.com> wrote in message 
news:g116kf$2sjl$1 digitalmars.com...

 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.


 UML class diagrams and UML sequence diagrams are not design; they are 
 programming. Programming in a language with no compiler, programming 
 without including your core algorithms, programming without any tests. 
 There's no way in hell you can verify your design will be even remotely 
 close to something that can work.

 You can safely and usefully design at a higher level before writing any 
 code, but not on the class level.


Safely, yes, usefully, maybe ;)

I'm convinced highly iterative development for anything even remotely 
complex is where it's at, so it's easy to spend too much time on the initial 
design stage, IMHO. I've seen too many projects that were over-designed 
prior to any coding that have failed miserably, mostly because what the user 
thinks they want and what they really want (once they start using something) 
are totally different.

A great example is the development of the language and tools for D itself 
<g>
May 22 2008
parent BCS <ao pathlink.com> writes:
Reply to Dave,


 it's easy to spend too much time on the
 initial design stage, IMHO. I've seen too many projects that were
 over-designed prior to any coding that have failed miserably


I think the important thing is to keep in mind what the design gives you 
and what it costs you.

The design is a tool for making better software. It lets you catch some design 
flaws earlier and fix them when it's cheaper. But it can be a costly way 
to find types of bugs. So when the cost savings of finding the bug that way 
exceeds the cost savings of fixing it later, just implement the sucker.

I suspect that's why formal design is more common in airplanes and space 
probes, finding a bug in flight control code by waiting for the plain to 
crash (pun) is kind of expensive.
May 22 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
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.
May 19 2008
prev sibling next sibling parent reply Max Samukha <spamme spambox.com> writes:
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.
May 20 2008
parent reply Sean Reque <seanthenewt yahoo.com> writes:
Max Samukha Wrote:


 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.




Am I the only one who thinks software build bugs, no matter how trivial, are
simply unacceptable? Just because it's free doesn't mean it doesn't have to
work! I shouldn't have to dig through source code just to get something to
compile, let alone run properly.
May 20 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Reque wrote:


 Max Samukha Wrote:
 

 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.


 
 
 
 Am I the only one who thinks software build bugs, no matter how trivial,
 are simply unacceptable? Just because it's free doesn't mean it doesn't
 have to work! I shouldn't have to dig through source code just to get
 something to compile, let alone run properly.


Indeed, and DDBI always compiles with the correct combination of compiler
and Tango :) The perceived problem here is that DDBI haven't had a stable
release for a long time (and that I hope to rectify), and so you may have
to be a bit lucky to get it to compile with your setup - to compile trunk
now for instance, you need Tango trunk.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 20 2008
next sibling parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
 Indeed, and DDBI always compiles with the correct combination of compiler
 and Tango :) 


Nope, ddbi does not compile with current version of Tango. You did not test
at least sqlite backend. Below you can see part of SqliteDatabase.d from
trunk version of DDBI:

version (Phobos) {
    private import std.string : toDString = toString, toCString = toStringz;
    debug (UnitTest) private import std.stdio;
} else {
    private import tango.stdc.stringz : toDString = fromUtf8z, toCString =
toUtf8z;
    private import tango.util.log.Log;
}

Do you see problem?: fromUtf8z and toUtf8z already do not exist in Tango.

In Sqlite backend, there is another problem - there is method:
bool execute(StatementBinder binder) but StatementBinder is not committed to
SVN.


-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
May 20 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Marcin Kuszczak wrote:


 Indeed, and DDBI always compiles with the correct combination of compiler
 and Tango :)


 
 Nope, ddbi does not compile with current version of Tango. You did not
 test at least sqlite backend. Below you can see part of SqliteDatabase.d
 from trunk version of DDBI:
 
 version (Phobos) {
     private import std.string : toDString = toString, toCString =
     toStringz; debug (UnitTest) private import std.stdio;
 } else {
     private import tango.stdc.stringz : toDString = fromUtf8z, toCString =
 toUtf8z;
     private import tango.util.log.Log;
 }
 
 Do you see problem?: fromUtf8z and toUtf8z already do not exist in Tango.
 
 In Sqlite backend, there is another problem - there is method:
 bool execute(StatementBinder binder) but StatementBinder is not committed
 to SVN.
 
 


Oh my, that is embarrassing. I had a mix and match dev version of Tango
installed, and so neither mysql nor sqlite backends compiled with a recent,
clean Tango. I have fixed mysql for now, whereas there is more work in line
to get the sqlite backend working. The rest of the backends I'm not even
likely to test very soon (maybe pgsql), and should be considered
unsupported.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 20 2008
prev sibling parent reply Sean Reque <seanthenewt yahoo.com> writes:
 Indeed, and DDBI always compiles with the correct combination of compiler
 and Tango :) The perceived problem here is that DDBI haven't had a stable
 release for a long time (and that I hope to rectify), and so you may have
 to be a bit lucky to get it to compile with your setup - to compile trunk
 now for instance, you need Tango trunk.
 
 -- 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango



Sorry, I didn't mean any personal offense. I've just dealt with one too many
open source projects that wouldn't even compile, either because of lack of good
up-to-date documentation or just plain bugs, or both. I remember reading a
forum post by an open source project owner once where the owner admitted that
the build for his project had bugs and did not work. Not only so,  he openly
admitted he hadn't fixed them because he didn't find that kind of work
interesting, and was instead asking for volunteers to do it for him!!!! 

I feel like, while it is getting better, that many open source content creators
focus more on pursuing personal interests than creating something useful for
other people. I have no problems with people wanting to explore personal
interests. Just don't try to tease the public and get them to believe you have
made something worth their time when it isn't! (Again, that's not directed to
anyone in particular.)
May 20 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Reque wrote:


 Indeed, and DDBI always compiles with the correct combination of compiler
 and Tango :) The perceived problem here is that DDBI haven't had a stable
 release for a long time (and that I hope to rectify), and so you may have
 to be a bit lucky to get it to compile with your setup - to compile trunk
 now for instance, you need Tango trunk.
 
 --
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


 
 
 Sorry, I didn't mean any personal offense. I've just dealt with one too
 many open source projects that wouldn't even compile, either because of
 lack of good up-to-date documentation or just plain bugs, or both. I
 remember reading a forum post by an open source project owner once where
 the owner admitted that the build for his project had bugs and did not
 work. Not only so,  he openly admitted he hadn't fixed them because he
 didn't find that kind of work interesting, and was instead asking for
 volunteers to do it for him!!!!


No offense taken :) Actually I was proven to even be wrong in my above
statement :P
 

 I feel like, while it is getting better, that many open source content
 creators focus more on pursuing personal interests than creating something
 useful for other people. I have no problems with people wanting to explore
 personal interests. Just don't try to tease the public and get them to
 believe you have made something worth their time when it isn't! (Again,
 that's not directed to anyone in particular.)


Well, many open source projects _do_ scratch an itch, and they are often
publicized on the off chance that others could be interested in it. If you
indeed are giving it "commercial" properties, then of course one should
expect it to build.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 20 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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?
 

At the very
 least the community needs to know what you as a potential user needs from
 the project, so that tasks can be prioritized. Most of D still being open
 source, one cannot normally expect anything to happen without
 contributing self at some level. Posting your summary here may or may not
 help, but going to the specific project will always be best. Not all in
 the D community follow these newsgroups regularly.


 
 He has just told you !

 
 An example of how I think a company could get involved to help D move on,
 is how the work I will do on DDBI is sponsored (part time) by a company
 that plans to use D commerically. In light of that, now may be the right
 time to get involved in that particular project.


 
 Give me some money and I will help you !
 
   

 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 :)
 
 --
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


 
 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 .


Yes, I checked, I'm the current mantainer of DDBI.


 
  If you aren't sure why post?
 
 From what I have seen it is a mess but listening to people like this and
 DOING SOMETHING ABOUT IT would be a good start . 


That is what I have been doing for quite a few years now.


 Don't start on me ! I am 
 still here and contributing with posts wherever I see stupidity, 


Contributing more stupidity?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 20 2008
parent reply Ty Tower <tytower yahoo.com.au> writes:
Lars Ivar Igesund Wrote:

 Don't start on me ! I am 
 still here and contributing with posts wherever I see stupidity, 


 
 Contributing more stupidity?


Now you see Lars here be your way, and your error.
Attack the messenger and ignore the message 
We all fall into it from time to time but you do it regularly whenever someone
says anything negative.

What happens then is no-one dare give you a message for fear of ridicule and
being on your high horse you influence others with your view .
So if its OK for you to do it ,it will be acceptable for others and this
permeates down to other forum members and nothing gets fixed 

This is how it is with D now . You could fix it simply by a small change to 
your approach and attitude. If you assume directness is rudeness you are very
wrong.
May 20 2008
next sibling parent reply Chris R. Miller <lordSaurontheGreat gmail.com> writes:
Ty Tower Wrote:


 Lars Ivar Igesund Wrote:

 Don't start on me ! I am 
 still here and contributing with posts wherever I see stupidity, 


 
 Contributing more stupidity?


 
 Now you see Lars here be your way, and your error.
 Attack the messenger and ignore the message 
 We all fall into it from time to time but you do it regularly whenever someone
says anything negative.
 
 What happens then is no-one dare give you a message for fear of ridicule and
being on your high horse you influence others with your view .
 So if its OK for you to do it ,it will be acceptable for others and this
permeates down to other forum members and nothing gets fixed 
 
 This is how it is with D now . You could fix it simply by a small change to 
your approach and attitude. If you assume directness is rudeness you are very
wrong.


I wise man speaks of what he sees.  The easiest approach to communication in a
newsgroup, forum, or mailing list is a simple loop:

1) State what you see.
2) State what you think.
3) (optional) State what you ****think**** should change.
4) Goto: 1

Ty sees a resistence to change.  He thinks that this is making D a harder
language for new people to get into.  He thinks that people should start taking
criticism less personally and more like contstructive criticism.

I see no reason for animosity here.
May 20 2008
parent reply Neal Alexander <WQEQWEUQY HOTMAIL.COM> writes:
Chris R. Miller wrote:

 Ty Tower Wrote:
 

 Lars Ivar Igesund Wrote:

 Don't start on me ! I am 
 still here and contributing with posts wherever I see stupidity, 


 Contributing more stupidity?


 Now you see Lars here be your way, and your error.
 Attack the messenger and ignore the message 
 We all fall into it from time to time but you do it regularly whenever someone
says anything negative.

 What happens then is no-one dare give you a message for fear of ridicule and
being on your high horse you influence others with your view .
 So if its OK for you to do it ,it will be acceptable for others and this
permeates down to other forum members and nothing gets fixed 

 This is how it is with D now . You could fix it simply by a small change to 
your approach and attitude. If you assume directness is rudeness you are very
wrong.


 
 I wise man speaks of what he sees.  The easiest approach to communication in a
newsgroup, forum, or mailing list is a simple loop:
 
 1) State what you see.
 2) State what you think.
 3) (optional) State what you ****think**** should change.
 4) Goto: 1
 
 Ty sees a resistence to change.  He thinks that this is making D a harder
language for new people to get into.  He thinks that people should start taking
criticism less personally and more like contstructive criticism.
 
 I see no reason for animosity here.
 


I don't see how you can take a person who has conversations with 
themselves (under different aliases) seriously.

Especially when all the multiple personalities are douchebags haha.
May 20 2008
next sibling parent Ty Tower <tytower yahoo.com.au> writes:
Neal Alexander Wrote:


 Chris R. Miller wrote:

 Ty Tower Wrote:
 

 Lars Ivar Igesund Wrote:

 Don't start on me ! I am 
 still here and contributing with posts wherever I see stupidity, 


 Contributing more stupidity?


 Now you see Lars here be your way, and your error.
 Attack the messenger and ignore the message 
 We all fall into it from time to time but you do it regularly whenever someone
says anything negative.

 What happens then is no-one dare give you a message for fear of ridicule and
being on your high horse you influence others with your view .
 So if its OK for you to do it ,it will be acceptable for others and this
permeates down to other forum members and nothing gets fixed 

 This is how it is with D now . You could fix it simply by a small change to 
your approach and attitude. If you assume directness is rudeness you are very
wrong.


 
 I wise man speaks of what he sees.  The easiest approach to communication in a
newsgroup, forum, or mailing list is a simple loop:
 
 1) State what you see.
 2) State what you think.
 3) (optional) State what you ****think**** should change.
 4) Goto: 1
 
 Ty sees a resistence to change.  He thinks that this is making D a harder
language for new people to get into.  He thinks that people should start taking
criticism less personally and more like contstructive criticism.
 
 I see no reason for animosity here.
 


 I don't see how you can take a person who has conversations with 
 themselves (under different aliases) seriously.
 
 Especially when all the multiple personalities are douchebags haha.


Cant give a reasonable argument so go with the name calling. If you think this
is the case prove it ?
May 20 2008
prev sibling parent reply "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Neal Alexander wrote:

 Chris R. Miller wrote:

 Ty Tower Wrote:


 Lars Ivar Igesund Wrote:

 Don't start on me ! I am still here and contributing with posts=20
 wherever I see stupidity,=20


 Contributing more stupidity?


 Now you see Lars here be your way, and your error.
 Attack the messenger and ignore the message We all fall into it from =







 time to time but you do it regularly whenever someone says anything=20
 negative.

 What happens then is no-one dare give you a message for fear of=20
 ridicule and being on your high horse you influence others with your =







 view .
 So if its OK for you to do it ,it will be acceptable for others and=20
 this permeates down to other forum members and nothing gets fixed
 This is how it is with D now . You could fix it simply by a small=20
 change to  your approach and attitude. If you assume directness is=20
 rudeness you are very wrong.


 I wise man speaks of what he sees.  The easiest approach to=20
 communication in a newsgroup, forum, or mailing list is a simple loop:=





 1) State what you see.
 2) State what you think.
 3) (optional) State what you ****think**** should change.
 4) Goto: 1

 Ty sees a resistence to change.  He thinks that this is making D a=20
 harder language for new people to get into.  He thinks that people=20
 should start taking criticism less personally and more like=20
 contstructive criticism.

 I see no reason for animosity here.


 I don't see how you can take a person who has conversations with=20
 themselves (under different aliases) seriously.
=20
 Especially when all the multiple personalities are douchebags haha.


In the event that you are accusing me of being "personality" of Ty, I=20
rebuke you and must say you have no idea what you are talking about.

We are two different people who live on different continents and have=20
different lives.  I resent your implications to the contrary.
May 20 2008
parent reply Neal Alexander <WQEQWEUQY HOTMAIL.COM> writes:
Chris R. Miller wrote:

 Neal Alexander wrote:

 Chris R. Miller wrote:

 Ty Tower Wrote:


 Lars Ivar Igesund Wrote:

 Don't start on me ! I am still here and contributing with posts 
 wherever I see stupidity, 


 Contributing more stupidity?


 Now you see Lars here be your way, and your error.
 Attack the messenger and ignore the message We all fall into it from 
 time to time but you do it regularly whenever someone says anything 
 negative.

 What happens then is no-one dare give you a message for fear of 
 ridicule and being on your high horse you influence others with your 
 view .
 So if its OK for you to do it ,it will be acceptable for others and 
 this permeates down to other forum members and nothing gets fixed
 This is how it is with D now . You could fix it simply by a small 
 change to  your approach and attitude. If you assume directness is 
 rudeness you are very wrong.


 I wise man speaks of what he sees.  The easiest approach to 
 communication in a newsgroup, forum, or mailing list is a simple loop:

 1) State what you see.
 2) State what you think.
 3) (optional) State what you ****think**** should change.
 4) Goto: 1

 Ty sees a resistence to change.  He thinks that this is making D a 
 harder language for new people to get into.  He thinks that people 
 should start taking criticism less personally and more like 
 contstructive criticism.

 I see no reason for animosity here.


 I don't see how you can take a person who has conversations with 
 themselves (under different aliases) seriously.

 Especially when all the multiple personalities are douchebags haha.


 
 In the event that you are accusing me of being "personality" of Ty, I 
 rebuke you and must say you have no idea what you are talking about.
 
 We are two different people who live on different continents and have 
 different lives.  I resent your implications to the contrary.
 


If i were accusing you of being him, why would i ask how *you* could 
take *him* seriously.

And as far is i can tell, i've seen 2-3 handles that could easily be 
aliases of his. Based on their mannerisms/writing style, and how they 
always seem to agree with each other and bump each others threads.

Not that i really care either way, but Lars is probably right to call 
him a dumbass heh.
May 20 2008
parent "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Neal Alexander wrote:

 Chris R. Miller wrote:

 In the event that you are accusing me of being "personality" of Ty, I =





 rebuke you and must say you have no idea what you are talking about.

 We are two different people who live on different continents and have =





 different lives.  I resent your implications to the contrary.


 If i were accusing you of being him, why would i ask how *you* could=20
 take *him* seriously.


Whoops, sorry.  I misinterpreted you.  No hard feelings I hope.
May 20 2008
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
Ty Tower wrote:

 Lars Ivar Igesund Wrote:

 Don't start on me ! I am 
 still here and contributing with posts wherever I see stupidity, 


 Contributing more stupidity?


 
 Now you see Lars here be your way, and your error.
 Attack the messenger and ignore the message 
 We all fall into it from time to time but you do it regularly whenever someone
says anything negative.


If a messenger repeatedly attacked me, I'd start attacking the messenger 
and ignoring the message.
May 21 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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!
May 19 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Robert Fraser wrote:


 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!


Sorry Robert, strike that :) I guess it is more the tools I use that are not
moving as fast as they did.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
May 20 2008
prev sibling next sibling parent Neal Alexander <WQEQWEUQY HOTMAIL.COM> writes:
Bill Lear wrote:


 We are writing a distributed media publishing system that uses a relational
database to store media programming schedules and other related information.  


Out of curiosity - did you guys consider Erlang? I'd be curious to hear 
why Ruby seemed more suited.
May 19 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:

 D is still useful for quick scripting.


Useful maybe, but for quick scripting for me it's not quick enough nor flexible
enough nor many other things, compared to Python :-) They are too much
different. 
Have you tried to practically use Phobos RegularExpressions compared to their
usage in Ruby?

Here I have listed few differences (mostly regarding the bug production, that
is an important thing to increase programming speed. In that list I have
forgotten few things, like that it essentially avoids the large class of
integer overflow-related bugs):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=71363

I think trying to do everything with D is silly.

Bye,
bearophile
May 19 2008
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
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 

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 

obscurity with that, so it isn't much of a competitive advantage.
May 19 2008
prev sibling parent "Simen Haugen" <simen.haugen pandavre.com> writes:
"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.
May 20 2008