Being a COBOL guy (for fun), I have opinions on this, but I'll try and only let them leak out a little bit lot, as this is meant as a question, not a judgement.

How long do you expect your D programs to last?

How long do you think the D system should support your source code?

D is 20+ now, but how long is its tail? Meaning, if you found D code from 19 years ago, would you expect it to compile today, with a current compiler? How far back in time should D source age? The length of the tail.

Is it better to cut off the growing tail for progress, or should progress allow for long tailed source code and binaries?

To be fair, a 1.0 to 2.0 bump is major enough to warrant lopping off a tail. (Or is it?)

Being new to D, that seems to put D2 at 12-ish years old. Does anyone have 12 year old code that would recompile without touching the sources? Would you expect it to? Or is it ok to write programs with fixed (with a randomness factor) life expectancy?

The idea to ask this question came up from reading the std.datetime article, and how it deprecated std.date. Would it be reasonable to freeze code rather than deprecate and remove? Leave the tail, even though it may be wrinkled and dry at the ends, rather than lop it off?

On one hand, a long tail means hauling luggage, an ever growing, possibly useless (to most) pile of baggage. On that hand, a long tail would mean that D only accumulates, ever growing. On the other, D becomes a smaller in toto codebase that slides through time, leaving it's past behind as it pursues perfection.

Leaking bias; I'm amazed that sophisticated Report Writer code from 1969 (pre structured programming) still compiles in a 2020+1 COBOL compiler. Has that code been superseded by events? Not really, dollars are still dollars, pennies are still pennies, page breaks are still page breaks and sums are still sums. The output format is archaic, but the code is still useful, and cups-pdf will gladly convert a plain old text file to PDF.

But I also realize that IBM charged customers a high premium to advertise and maintain that backward compatibility. Maybe only Computer Business needs those kinds of timelines and guarantees. Perhaps Computer Science can slide, allowing old code to become worthless without surgery after a reasonably short life span, as Science evolves faster in general. Lots of life forms leave behind old shells behind to grow and mature.

So it's a question. What is a reasonable life expectancy for the projects I start in D today?

Have good, make well.

On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:

I have some code that builds with DMD 2.076.0, that's 1 Sep 2017.
You can probably go much earlier with some effort.
Ultimately I hope an event as breaking as D2 circa 2010 won't happen again, many people departed.

On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:

Normally the programs use the standard library and/or DUB libraries. In that usual case, it in my experience takes around an year or so for code to stop compiling. However, it's almost always easy to migrate - just find-replace a library function call, add an alias for it, or stuff like that.

If you copy-paste the library code instead, or don't use it, your code will usually keep compiling for multiple years. DMD is a good example - it may well compile with 20 minors older version of itself.

But all in all, in D one has to be prepared to use older compiler versions if updating old code is not possible or worth the effort. On the other hand, I think one should always be prepared to do so in any language. Even in standartised languages, it does happen that the code accidently uses non-standard features or the new compiler versions include regressions.

On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:

Forever.

Forever.

No. But with a compiler from then.
-> your code should mention the version of D it is supposed to be compiled with.
If it's not too old, I would expect to be able to update the source code to compile with a current compiler without much effort.
Of course it gets more complicated with every library involved...

On Tuesday, 10 August 2021 at 12:19:26 UTC, Dukc wrote:

Old D versions do not receive platform compatibility updates. E.g., it's not possible to build a program with D 2.060 on recent versions of macOS, and old versions of macOS don't run on new hardware, so you actually have to keep the old hardware around. (Or at least that's how I understand it - not a mac user.)

Old versions of D also do not compile on recent systems. I maintain Digger which attempts to solve this problem, though. (This doesn't help solve the problem above.)

On Tuesday, 10 August 2021 at 14:18:47 UTC, Dominikus Dittes Scherkl wrote:

This. We successfully use https://dub.pm/package-format-json.html#toolchain-requirements for this.

-- Bastiaan.

On Wednesday, 11 August 2021 at 10:05:19 UTC, Bastiaan Veelo wrote:

I don't recall seeing that there. Thanks for pointing it out.

On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:

Very much depends on the type of project. How much do you depend on new features (likely to change), how much do you depend on library code, how much do you depend on ABI details, how much are you working around current language/compiler issues...?

At Weka, thusfar any new compiler means compilation failures. It is a demanding codebase.
Some reasons for failures: workarounds for compiler bugs, ABI dependencies, template attribute deduction deltas, dependence on druntime internals, new compiler bugs, change of language semantics (sometimes intended, but also often unintended), no way to disable/enable specific warnings/deprecations, ...
On top of that, performance may change too with compiler version, so even if the build succeeds that does not mean the program still functions within the required performance constraints.
Keeping the code compatible with multiple frontends is a large burden, currently avoided by specifying the compiler version in the codebase and using that exact compiler on build systems and developer's machines (i.e. each dev will have multiple compilers on his machine, automatically downloaded and used by build system). Updating the compiler to a new version is a lengthy process. Weka is currently at LDC 1.24 (with Weka modifications).

-Johan