D - more power than needed. Really?

[Georg Wrede]

Walter Bright wrote:
> "Craig Black" <cblack at ara.com> wrote
> 
>> A lot of the bias towards OOP purism comes from Java vs. C++ 
>> comparisons, much more convincing than Anything vs. D. Hopefully 
>> the simplicity and power of D can help to eliminate OOP purism.
> 
> The trouble with OOP is, well, not everything is an object. For 
> example, take the trig function sin(x). It's not an object. Of 
> course, we could bash it into being an object, but that doesn't
> accomplish anything but obfuscation.
> 
> Sometimes, I think C++ went hard over in the opposite direction -
> nothing is an object. OOP programming seems to be regarded as
> "oh, so 90's" by the modern C++ crowd.
> 
> Every decade seems to have its programming buzzword:
> 
> 60's: artificial intelligence
> 70's: structured programming
> 80's: user-friendly
> 90's: object oriented programming
> 00's: metaprogramming 

I sometimes view the programming language scene as a small forest. We 
have massive cross-pollination between species there, new "pure" species 
come up every now and then, and once they grow, other new species start 
getting dna from them too. In time most of the good ideas get spread 
around. And those who can receive new dna in adulthood, stay fit and 
prosper.

  Conversely, what one does see is old, big trees that are dry and 
hollow, just rutting or drying as they stand. One can even see trees die 
suddenly, felled by the wind.

But like in the real world, one never sees the moment a language is 
born. Only when it's grown enough to get one's attention do we see it.

With D we're pretty close. With Perl, I happened to stumble on a copy of 
Perl when it was like D was some 4 years ago. I thought "gee, nice 
idea", but never did it cross my mind that Perl "would take the world".

Heh, Practical Extraction and Reporting was all over the pages, the word 
Perl was sort-of incidental looking in comparison. In spite of being big 
(as in huge) today, Perl is also a thriving language. One thing that 
[come to think of it] advertises this is the version numbering. On my 
0.8GHz laptop, Perl is 5.8.6. Being the pathological anarchist that 
Larry Wall is, he couldn't care less about striving to nice round 
version numbers. Which I think is actually an excellent principle. As a 
matter of fact, such would only become a dragstone if one hopes for 
unhindered renewal and improvement.

---

Today, advertising major version numbers (and shoving the minors under 
the rug) is corporate. As in Oracle, Windows, Solaris. Nobody seems to 
mind if this or that script contains a line requiring at least version 
x.x.374 of Perl. Folks just shrug and download it. Look at Apple.

If we, with D, can maintain backwards compatibility (no more than what 
Walter -- and we all, currently aim to), then such would not be a 
problem here either. We could skip the "Major version every 2 years, bug 
fixes in between" mantra, and make D more into a pipeline -- like a 
continuous process. (We're on the Net: no need to plan the manual books 
and boxes, and the ad campaign 18 months in advance.)

This sounds daring, I admit, but we've seen it done. And if we do it on 
purpose (vs. ending up there), then we can do it in style and elegance. 
It is for this thing we have the /deprecated/ keyword. If we only made 
major steps, who'd care about that -- there'd be so much else to plan 
ahead when switching to the new version at the sweat shop. (And most of 
the existing software would stay updated with the old version anyway.)

A three-level numbering is handy. Last position changing each time folks 
would want to read the Fixed list, middle version changing whenever they 
might want to review the readme. And of course, the first position 
changing whenever major things are implemented. Odd middles for 
developers, even for everyone.

---

But anyhow, the fact remains, we don't need to do D in discrete steps. 
We can do a slope.

Any grad school math teacher can write a *proof* (using differential 
calculus) that steps lose compared to the continuous. So it's not just 
good practice (especially in the modern, exponentially accelerating 
world), but also theoretically provable.