D's tail

Brian Tiffin btiffin at gnu.org
Thu Aug 12 12:31:35 UTC 2021


On Thursday, 12 August 2021 at 08:52:29 UTC, FeepingCreature 
wrote:
> On Wednesday, 11 August 2021 at 19:40:36 UTC, Brian Tiffin
>> ...
>> 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.

I lean to stable, but don't disagree with your sentiment, 
FeepingCreature.  COBOL is one of the very few Computer Business 
programming languages.  It has a domain of strength, and has 
owned that domain since the inception of writing programs.  Big 
monies ride on it, and computers are not the purpose of those 
businesses, just a tool to help run said business.

Computer Science needs and wants to evolve faster than Computer 
Business.  But there does need to be stable or promise of stable 
if you want a business to invest in a technology.  Except for a 
very few fields, computers are not the purpose of a business, 
just a tool to automate some tasks or speed up calculations to a 
point that making those calculations can happen in a reasonable 
time frame.

Think about D replacing the user land of a Linux distro.  GNU 
doesn't replace `cat` every 4 years because it was forced on the 
project because a build tool changed.  coreutils is maintained, 
yes, mostly by volunteers, but it wouldn't be GNU/Linux if the 
GNU part failed on every other kernel update.  The keenest of 
programmers age out.

If a team was to try and replace coreutils with D, there would 
likely be an initial round of totally keen programmers, eager to 
try.  If they succeeded and completed all the commands, the 
amount of keen to go back and fix things later would be greatly 
diminished.

coreutils-d would be a very cool thing to see.  But, 7 years 
later it would likely be in a state of bitrot. It might not 
entice enough keen programmers to tweak and improve, if all the 
time is spent on forced maintenance due to constant upstream 
changes to tooling.  When you can't entice the keen programmers, 
the keen programmers do something else.  coreutils-d would start 
to fray, and would likely become an effort of a few critical 
maintainers, who will age out.  coreutils will stay written in C 
and C++, and will compile with gcc for the foreseeable future. 
Decades of future added to the decades of past.

I'm loving exploring D and can see the absolutely immense 
potential.  But, I'm doing this in my spare time at no one's 
expense. I'm not doing D as a person in need of hiring a team to 
work on a business problem or new product.  Programmers are 
expensive, people only want to have to pay them once for each 
feature coded. Then pat them on the back for a job well done, and 
punt them from the payroll as soon as possible.

If D is ok with being used in small system programming fields 
with short-range life expectancy, then it could very well own the 
domain, and be the world class tool.  In that reality, world 
domination is off the table.

I'd be ok with that form of D in the long term, as a hobbyist 
writing little throw away programs, while having a lot of fun 
doing it.

But I would not yet want to publish anything that might become 
famous, only to be chained to maintenance on a schedule randomly 
dictated by others.  I'm a computer programmer, my attention span 
is counted in seconds, intermixed with long periods of deep focus 
that end when they end. And then it is on to the next thing.  
Don't like being forced by circumstance to redo a deep focus; 
that's supposed to be my decision of when and where, unless I've 
already traded my time for someone else's money, then they get to 
decide the where, the when, and the how.

So, I guess I'm not yet strongly for or against stable, long 
term, source level D.  Leaning to for, I will opine as an old 
guy, as-is, D is not yet destined for world domination.  Which is 
ok.  A fraction of the millions of human hours spent programming 
every hour around the world, is still a lot of hours.  Redoing 
hours is no fun though, and this thread is helping set 
expectations.

Have good, make well.


More information about the Digitalmars-d mailing list