On Thursday, 15 December 2011 at 02:10:09 UTC, Walter Bright
wrote:
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.
Not the answer I was expecting for the first question, but it
ultimately turned out to be the same, "you or anybody else can't,
and neither can I." The point is I have something that works now
moving to something new means risks and having to learn new
things which ultimately ends up meaning time spent on other
things then driving the project forward. I do realize there are
some similarities with this argument and your argument for
discontinuing D1 support, so I can't argue those reasons.
So the way I see it now, is there are some minor risks involved
and a upfront investment of time to convert the code, for no
real gain. Tho std.concurrency is looking pretty neat.
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.
The issues I have ran into long ago, I'm pretty sure I haven't
filed bugs about, sorry about that. The Mac platform issues I
have: filed bugs for or reported me too's, generated pull
requests, which have been pulled. So they are all resolved.
I think that my biggest fear is running into new bugs that I will
have to waste a day or so of productivity on.
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.
My point was it would not be a non-trivial amount of work. You
are of course correct that the non-D code would be left alone.
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.
I can try and spend some time on this again. But the last time I
tried I got random crashes inside the graphics driver with DMD &
DMC while the same code cross compiled worked just fine. That was
after a long day fighting various other versions of mingw-gdc
trying to get it to work. I have to admit I at that point gave
up. I know this is not ideal, sorry about that.
That said it might all work if I move to D2 and it might not, so
there is that to factor into things as well.
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.
C style code is mostly what I have been doing anyways. I think
the point I was trying to make is that D2 has the same unglued
problem as D1. It might be different set of problems, but
probably the same. That said C and C++ has its own set of
problems and you just learn to work around those. If they differ
from D1 to D2 I would have to relearn those.
That said I do have some advanced code in there, mostly relating
to resource management, the code itself isn't, but writing it was
a uphill battle against the GC. But I'm doing things not allowed,
accessing objects from the dtor of a object. Those problems could
be solved with the two step approach outlined by the link above.
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.
I have tried to explain, I think my biggest concern is having to
waste time for no gain.
