Dicebot on leaving D: It is anarchy driven development in all its glory.

[Chris]

On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote:
> On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright 
> wrote:
>
> In the whole discussion I miss 2 really important things.
>
> If your product compiles fine with a dmd version, no one forces 
> you to update to the next dmd version. In the company I work 
> for, we set for each project the DMD version in the build 
> settings. The speed of DMD releases or breaking changes doesn't 
> affect us at all.

No. Nobody forces you to use the latest version that may have an 
improved GC, new library functions or bug fixes. In fact, why 
bother with improving the language at all? But how do you feel 
about code that you've been compiling with, say dmd 2.071.2 for 
years now - including workarounds for compiler bugs? Doesn't the 
thought of having to upgrade it one day bother you at all? What 
if your customer said that 2.08++ had better features asking you 
to use them?

The burden of finding paths to handle deprecations etc. is on the 
user, not the language developers. And this is where the 
psychological factor that Laeeth was talking about comes in. If 
you're constantly programming thinking "Whatever I write today 
might break tomorrow, uh, and what about the code I wrote in 
2016? Well, I'll have to upgrade it one day, when I have time. 
I'll just keep on using an older version of dmd for now. Yeah, 
no, I cannot benefit from the latest improvements but at least it 
compiles with dmd2.st0neage. But why worry, I'll just have to get 
used to the fact that I have different code for different 
versions, for now...and forever."

You can get used to anything until you find out that it doesn't 
need to be this way. You write unexciting Java code and hey, it 
works and it always will. It took me a while to understand why 
Java has been so successful, but now I know. It's not write once, 
run everywhere. It's write once, run forever. Stability, 
predictability. And maybe that's why Java, Go and once C++ prefer 
a slower pace.

I just don't understand why it is so hard to understand the 
points I and others have made. It's not rocket science, but maybe 
this is the problem, because I already see, the point to take 
home is: There are no real problems, we are just imagining them. 
Real world experience doesn't count, because we just don't see 
the bigger picture which is the eternal glory of academic 
discussions about half baked features of an eternally unfinished 
language that keeps changing randomly. Not practical, but 
intellectually satisfying.