Every time I come back to a D program I wrote over a year ago, it
seems like there are numerous breaking changes and it takes me a
while to get it to compile again. And the documentation is
difficult to figure out. I wish I could remember every time I've
had to change this line of code, but I know most times I have
come back to this project over the last 14 years, I have had to
change it.
This is more or less what I had the last time:
auto sekunden = to!("seconds", long)(dauer);
return cast(long)floor(sekunden * 18);
The compiler complained about double. I found a post in dlang
from 2019 saying the library doesn't allow double conversion. It
sure doesn't! However, it used to.
I downloaded bindbc and got an error building with dmd version
2.087. The error was 'atomicFence is not a template declaration'.
Mike suggested I upgrade to 2.095 and lo and behold, that
compilation issue went away.
Now, I hate Java as much as the next guy (maybe more than most
next guys), but the things that led to me being a Java Developer
today are:
1. The Java Trails tutorials and JDK documentation
2. Backwards compatibility and easy-to-understand versioning
3. Lack of self-respect and willingness to stand up for what's
right
#3 is not in the purview of a language developer, but #1 and #2
are. I always feel like I want to be an evangelist for D, but
then I come back and things have changed and by the time I figure
out what's going on and do something cool, I need to take a
break. That is because I run into compilation errors with a few
minor version updates, I spend a lot of time retooling and fixing
my project to work on a new version of the compiler (or, I
assume, standard library) and libraries. I don't have that
problem in other languages.
If I write code in Java (barring a few major changes like the
generics update), it will continue to work just fine in newer
versions of Java. I can dig out the Java version of the program
which I wrote - just before the D program I am referring to - in
2006/2007 and it still compiles and runs horribly just like the
day I wrote it.
When Java 6 came out, I bought a book called Java 6 SE
Development. I read it and since I knew Java 5 now I knew what
was in Java 6.
As to the Java Trails and JDK documentation, I could figure out
how to do anything in the standard library that I needed to. I
didn't have to look anywhere else. As a new developer I wrote an
entire multi-threaded application that connected to a server
written in C and made thousands of draws per frame at 8-10 frames
per second, and I didn't have to use any resources outside of one
book and the standard Java library documentation. That's pretty
good.
Contrast to me trying to figure out how to format a number in
binary. format!"%b"(number) does not work but is very similar to
what is suggested in the documentation. I was able to figure out
it's format("%b", number) but it took a few minutes.
I also have to figure out how to determine how many 18ths of a
second have elapsed since the application started up. Don't ask
me why 18ths, that is just the number that the server uses. Does
total give me the total number of nanoseconds or the number of
nanoseconds after the large time units are factored out? The
documentation appears to say one thing but the tests appear to
show the opposite. I just have to write a test program to figure
it out.
I've been using D for close to half my life and I have no
intention to stop using it, but it will never be my go-to tool
for things like web development with C# around. I'd love for it
to be the language and tooling that I reach for all the time. It
has the potential to be that, but just the thought of having to
upgrade to the new compiler, new standard library, new build
tools and new library makes me hesitate every time. Even now, on
this project, I am going to spend ~10 hours to work through these
issues just to get back to where I was.
I think the first thing to do is lock down D to major version
changes. Any DMD 2 program should continue to compile with any
future 2.x version of DMD. If it is not longer backwards
compatible, make that version 3. Then for each version upgrade,
write some kind of upgrade guide. Crowd source it even as people
experience issues.
Maybe it's just me, but if I had confidence that the versions
would be around a little while and an example I write today would
work for others in a year or two, I would be more willing to
contribute examples, documentation and so forth. As it is, I will
probably do that in some fashion, but very limited and possibly
not in as community-wide of a venture.
PS I have a copy of The D Programming Language I refer to when I
start programming but it's in a storage unit. That is at least as
good as the Java Trails, although I'm not sure the examples would
even compile today.
