On 12/14/2011 4:32 PM, Jakob Bornecrantz wrote:
In short it can be answered with the questions "Can you
guarantee it work?"

A guarantee would be something like you paid $x for it and I would refund your $x if you weren't completely satisfied (which I often do for Digital Mars C++ and other paid products). But I don't see how I could offer a guarantee on a free product where I have no control over your satisfaction.


and "Can I justify the amount of work I have
to put in for the gain?",

That's something only you can answer.


the thing is I have a had a lot of
problems with D1 toolchain, I have fixed or worked around these
issues and I'm wondering if I have to work around those or other
again. I am currently supporting 3 platforms (Mac, Linux &
Windows), so that factors in as well (me having fixed some
issues on Mac for D1).

I can ask:

1. Are these issues all reported in Bugzilla?
2. Are your fixes also supplied to Bugzilla?

With (1), I then will know about the issues, and myself or one of the many contributors can supply a fix. With (2), I can incorporate your fixes into the official toolchain so it will never darken anyone else's doorstep again.


My current code base is 40Kloc's where about 8Kloc of those
are library bindings, on top of that it also includes a couple
of C projects sources (expat, lua and some other misc
libraries). So I would have to convert all that code to D2 and
also fix any issues that might arise from that conversion.
That said I think that it would mostly running the code
through dmd2 and just fix any cases where it complains. But it
probably wouldn't be a trivial amount of work.

I don't know how much work that would be. I will say that 40Kloc is not a huge base of code, as these things go. I don't think you'll have to do anything with the C code or other non-D sources.


I don't use Phobos that much in my code so I wont have to
change much code with that regards, then again I don't see much
value of the new Phobos since there isn't much new there for me.
In fact I sort of have a philosophical disagreement with the
boost/templet-ification of it and the language in general.

That's fair, but it's also something that could be a separate, wide-ranging discussion.

Also in the beginning when I was using D1 and it moved much
more faster I would often find myself having to work around
or change various parts of the program due to new bugs or
features. I think D2 is much better in the bug department then
D1 was so that isn't much of a issue, but its still not really
stable and its more work for me.

I understand the pain that breaking changes cause, and have pushed hard to stop a few that I felt the minor gains on did not justify the disruption.


That said there are a couple of features that if they where
implemented in D2 would encourage me to switch.

One of the biggest problem right now is that I can't build
my project on Windows and is forced to cross compile it with GDC
from Linux. This stems from me having a mixed C & D project and
not getting the various compilers to get along (Both DMD & DMC
and GDC & GCC, would either not compile or produce broken
binaries). So making DMD work with the mingw toolchain on
Windows would be really appreciated (COFF support right?).

I cannot help with this without knowing what the specific problems are.


Improvements to the GC, I'm currently having to thread lightly
around various issues with the GC, again its works currently so
I don't want to work around it again. Adopting a two step
approach employed by GObject would might help.
http://developer.gnome.org/gobject/stable/gobject-memory.html


All said and done, knowing what I know today I would probably
not do the project in D1, but I have thrown my dice and I'm
"stuck" (not used strongly here, I still like a lot of D), but
I'm not sure I would want to go through all that pain again
with D2. As Andrie have said D has a tendency to come unglued
when you start to do advanced thing, and the language dies a
death of a thousand paper-cuts (and some knife stabs).

You don't have to write advanced code using D2. You can still write "C style" code with it, and even "D1 style" code in it.


I do appreciate the work you have put into D over the years,
I just don't want to have meaningless battles with language/-
compiler bugs. I hope this message is useful for you.

It is, but I really do need more detail as outlined above.

Reply via email to