C++17

[Chris Wright via Digitalmars-d]

On Wed, 27 Jan 2016 19:25:49 +0000, rsw0x wrote:

> On Wednesday, 27 January 2016 at 19:21:11 UTC, Abdulhaq wrote:
>> On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim Grøstad
>> wrote:
>>> On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
>>>> And ironically, in this very thread, a C++ programmer has called D a
>>>> toy language.
>>>
>>> D is incomplete, unfinished, unspecified and unstable. C++14 is an ISO
>>> standard and has several independent implementations that are polished
>>> and stable compiler releases.
>>>
>>> That makes D a toy language and C++ an industry standard.
>>>
>>> Not very difficult to grok, I would think.
>>
>> It make its immature but come on, it's not a toy.
> 
> Fits fairly well under Eric S. Raymond's toy language definition,
> actually.

I've seen almost nothing produced by Eric S Raymond besides a hypertext 
version of the INTERCAL spec and _The Cathedral and the Bazaar_. Oh, and 
some random conspiracy theorist on IRC making outrageous claims and ESR 
accepting them as absolute truth without a second thought. So I'm not 
sure why I should prioritize his definitions.

More to the point, people here are using different definitions, which 
results in a profound lack of communication that looks like an argument 
with content but isn't.

D is quite unlike languages intended and marketed as toys, such as 
GolfScript, Befunge, and Whitespace; or personal projects intended mostly 
as an exercise for the designer. Compared to them, D is a much better 
choice for use in production code. D is also somewhat unlike languages 
such as C++ and Java, which have reliable implementations, are well 
specified, and change at a pace that a Fortune 500 company can keep up 
with.

Of the two, D's heart is in the C++/Java camp: it's intended for serious 
use, has features to make that feasible, and has a reliable core of 
features that work. However, it's not close enough -- not well versioned 
enough, doesn't have sufficiently stable tools -- for it to be generally 
wise to bet your company on it.

D as a programming language is unlikely to stabilize any time soon. The 
release structure doesn't support it. The language spec is a living 
document rather than being versioned. This is useful for keeping everyone 
compatible with the newest features (you do it or nobody can use your 
library) but is bad for keeping your company's code working over the 
course of years without people having to update it to the latest language 
features. Companies typically stick to one version for quite some time, 
but in D's case, this means cutting off a number of third-party libraries.

The tooling has improved over time. Five years ago, dsss was newfangled; 
now dub has consumed all. dfix and dfmt have only come up recently, and 
there's talk of including them in the standard distribution.

And this is related, but it's not about the language as such: the library 
situation is improving, but slowly. In 2008 dsource.org hosted probably 
fifty projects. Eight years later, code.dlang.org indexes 650 packages. 
There are database adapters for a scant handful of databases. There are 
no Google or Amazon API clients. There are many missing things. *That* 
makes it hard to use D in production, even if the tooling and stability 
were there.