Vision for the D language - stabilizing complexity?

[Chris via Digitalmars-d]

On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
>> Such a language will never see the light of day.
>
> Many such languages exist.

Like? I mean languages that can be used in the real world. 
Certainly not Nim. It's not usable yet, it may change drastically 
any time.

>> What makes a language attractive is that you can actually use 
>> it - here and now.
>
> What makes a language attractive is that it has system support 
> and provides solutions that save time. That's what languages 
> like TypeScript, Python, C#, Java, Swift and Go attractive.

... and they're all usable as in I can write software with them 
right now.

> I follow several languages that are very attractive, but that I 
> cannot use because they don't have system support. I am also 
> using languages that are less attractive than the alternatives 
> for the same reasons.
>
>>> Of course, the first thing you ought to do is to look at 
>>> existing knowhow related to language design.
>>
>> Which is what D did.
>
> No, it did not build on existing knowhow in language design 
> theory, it was a fair reinterpretation of the C++ programming 
> model with a tiny bit of Pythonesque extensions.

Examples?

>> ... which, in fairness, where never meant to be carefully 
>> designed languages. Just convenient hacks for everyday tasks.
>
> Perl and Php started as small and convenient scripting 
> languages, but they were predominantly evolved in an iterative 
> fashion for decades after that, and aggregated a lot of issues 
> related to exactly iterative evolution.

Yes, exactly, they were never meant to be big languages, just 
scripting tools. Same happened to Python in a way. It should 
never have left the lab and infected millions of people.

> Both C++ and D shows clear signs of their abstraction 
> mechanisms not fitting well with the core language. Too many 
> mechanisms, not generic enough. And that happened because 
> significant changes came late in the process, after deployment. 
> You can say the same thing about Go and error-handling, it 
> sticks out like a sore thumb.

There's never _the_ perfect time to deploy a language, just like 
there's never _the_ perfect time to buy a computer, the moment 
you leave the shop it's out of date. You're dreaming of a 
language that only exists in cloud cuckoo land and it will get 
you nowhere. But of course, it's much easier to criticize the 
players on the pitch from your comfy armchair than to actually go 
onto the pitch and play yourself. No language ever gets it 100% 
right, because there are conflicting demands, and it's trivial to 
point out flaws that are bound to arise out of conflicting 
demands.