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.

For the record, I was able to resolve all of my issues in about 7 hours. That included upgrading from DerelictSDL to bindbc and converting to use dub instead of make.

I hope my above post does not lead people to believe that I don't like D, because I otherwise wouldn't have lost track of time until midnight working on this project!

I also should mention that this project was probably last touched in 2017. I thought I pulled it out a year ago, but that was a different project.

On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote:
> ...

Yes it's a problem indeed. I had the same problem and that's worse when you don't upgrade very often.

But let me tell something, where I work we have software in C#, do you think that upgrading was smoothly with all the tools that Microsoft provides?

No it wasn't, and it gets worse with third party components.

So this guy was hired just for that, port a very old code to the new framework, and after a month he did, yes it compiled alright... but the software didn't work as expected is some cases, some controls wasn't acting right and was very unreliable.

Guess what? They are still developing with old framework until everything works correctly on the new framework.

Matheus.

On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote:
> For the record, I was able to resolve all of my issues in about 7 hours. That included upgrading from DerelictSDL to bindbc and converting to use dub instead of make.
>
> I hope my above post does not lead people to believe that I don't like D, because I otherwise wouldn't have lost track of time until midnight working on this project!
>
> I also should mention that this project was probably last touched in 2017. I thought I pulled it out a year ago, but that was a different project.

otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years.

On Thu, Mar 04, 2021 at 06:43:57AM +0000, user1234 via Digitalmars-d-learn wrote:
> On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote:
> > For the record, I was able to resolve all of my issues in about 7 hours.  That included upgrading from DerelictSDL to bindbc and converting to use dub instead of make.
[...]
> > I also should mention that this project was probably last touched in 2017. I thought I pulled it out a year ago, but that was a different project.
> 
> otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years.

Y'know what'd be cool: if people could add their D projects to some kind of master CI (don't know if the existing dmd/druntime/phobos CI config allows this) so that whenever a change in the language causes breakage, the relevant PR will get flagged for review.  I wouldn't say block the PR altogether -- we don't want some obscure no-longer-maintained project to hold back everyone else -- but at least flag it as a breaking change so that the owner can be contacted to see if something could be worked out.

I know we already do this for some key projects, but a large-scale CI test would be nice, if we had the resources for it.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."

On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote:
>
> otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years.
Nice idea. Try do it with all hundreds of used in your projects libraries.

On Thursday, 4 March 2021 at 09:21:12 UTC, Siemargl wrote:
> On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote:
>>
>> otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years.
> Nice idea. Try do it with all hundreds of used in your projects libraries.

isObject, isArray, etc ;) ?

On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:
> 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.

I am porting a large code base from Extended Pascal to D and I know that there will be changes in the language in the future that will take an effort to adapt to. Yet, I am still in the camp of wanting these changes to happen because we don't want to port from a dead language to another dead language, we need the language to be alive.

The way I deal with this is to lock down version numbers with the revision number of our code base. By having dub.selections.json under revision control we make sure that the same version of dependencies are used every time until we upgrade, and by having this in dub.json:

```
	"toolchainRequirements": {
		"frontend": "==2.096"
	},
```

we ensure that the code simply refuses to compile with any other language version.

So, if two years from now we were to check out a revision that was two years old, yes we would have to downgrade the compiler but it would still work. Upgrading to a newer language version or dependency version can be done outside of the main development branch, where it can be properly tested before merging.

Ideally I want the build system to automatically install and/or activate the compiler specified in the code base so that a toolchain upgrade becomes just like a regular feature commit, possibly using one of the existing compiler version managers [1, 2] or by extending dub itself. Then, fellow developers will hardly notice compiler upgrades, the build farm doesn't need attention, and bisecting revisions to pin down the occurrence of a regression can be done without complications.

I think it is important that warts in the language and standard library are removed, and luckily we have a proper deprecation mechanism. My advice is, if you pick up a two-year old project and don't want to deal with breakages, you just continue with the versions from that time; Until you choose to use newer features, but you can plan for the work that this requires.

-- Bastiaan.

[1] https://dlang.org/install.html
[2] https://code.dlang.org/packages/dvm

On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:
> 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.

This works for me:
 rdmd --eval="writeln(format!`%b`(5));"
 101
 rdmd --eval="writeln(__VERSION__);"
 2096

-- Bastiaan.

> ```
> 	"toolchainRequirements": {
> 		"frontend": "==2.096"
> 	},
> ```

Thanks! I didn't know you could specify a toolchain version. I agree it would be cool if it automatically downloaded the correct version of compiler, but this will be helpful. Is it possible to download old versions of the compiler somewhere?

On Thursday, 4 March 2021 at 10:22:51 UTC, Bastiaan Veelo wrote:
> On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:
>> 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.
>
> This works for me:
>  rdmd --eval="writeln(format!`%b`(5));"
>  101
>  rdmd --eval="writeln(__VERSION__);"
>  2096
>
> -- Bastiaan.

I want this almost every week at work. When I run into some trivial statement that I need to know for sure how it works, it's rarely worth it to create a whole new file and make a main method and all that. I just edit and run the entire program again, which is a waste of time.
So about ten seconds later:
PS> rdmd --eval="writeln(format!`%b`(5));"
~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error: template argument expected following `!`
Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", "-d", "-v", "-o-", "~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d", "-I~\\AppData\\Local\\Temp\\.rdmd"]

PS> rdmd --eval="writeln(__VERSION__);"
2095

That was pretty sweet. However, it kind of goes to the point of my post. A one-revision difference means the documentation is not accurate for my compiler.

I'm not saying the language shouldn't evolve, I'm just saying it might make sense to keep compatibility changes to every 6 months or a year. Then you could keep the old documentation around for the old version, and create new documentation for the new version and no matter which version someone is using they would have documentation (within limits.)

Depending on how long I can keep at this project, I would be down to host my source wherever it needs to be hosted (provided it's git) to get the new-version-check feature. I might even pay a bit for it. I doubt that makes it worth it, but I thought I'd throw that out there in case more people agree.

I like D. I like that D is changing. To go along with that, I would like a little more predictability with major version releases. I see there is a lot more documentation than the last time I checked so I'll take a deeper look at that.