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.
