D's Continous Changing

[harakim]

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.