D's tail

FeepingCreature feepingcreature at gmail.com
Thu Aug 12 08:52:29 UTC 2021


On Wednesday, 11 August 2021 at 19:40:36 UTC, Brian Tiffin wrote:
> On Wednesday, 11 August 2021 at 14:22:31 UTC, Bastiaan Veelo 
> wrote:
>> On Wednesday, 11 August 2021 at 11:33:42 UTC, Johan wrote:
>>> … specifying the compiler version in the codebase and using
>> ...
>> Imagine checking out any project at any revision and it builds 
>> without intervention at any time.
>>
>> — Bastiaan.
>
> :-)
>
> As mentioned at the top, a COBOL guy, source code from 1972 
> *just works*.  COBOL programmers live in that *imaginary* world.
>
> Ok, that's exaggerating the truth, but it's the disappointing 
> exception that is the exception, not the rule.  The rule is, 
> code it now and it compiles and works, in perpetuity.
>
> And thanks for the hints on how to go about increasing the life 
> expectancy for D source codes.
>
> To be honest, I'm hoping to be able to assume that D source 
> will be as resilient to the ever changing surrounding 
> environments for as long as I'd assume C source to be. Source 
> code should age gracefully, not fearing each and every revision 
> of build tools or run-time support libraries.  Yes, you retest 
> after upgrades, but the assumption should be more life in a 
> newly renovated house, not assuming you have to count the 
> number of broken fingers that need attention before getting 
> back to work.  :-)
>
> Have good, make well.

Personally speaking, I am strongly against this.

I think that works for a compact, well-defined language that is 
"done", that generally works well, or at least good enough that 
you can live with the corner-cases. Like C. In comparison, D is 
to some large extent also an *exploration* of language design, an 
attempt to see what works and what doesn't, and when you lean 
yourself out of the window like that you have to be able and 
willing to course correct, to say "well we tried that but it 
didn't work out", or you get stuck in mediocrity.

D is too big and too speculative to support true long-term 
stability. As a compromise, we have the deprecation mechanism, 
which gives you early warning for which parts are going away in 
future versions. I am very glad for this mechanism, and honestly 
think the rate of change of D could even be a bit higher than it 
is today, maybe up to twice as fast.


More information about the Digitalmars-d mailing list