On Fri, Jul 17, 2009 at 6:32 AM, Jarrett Billingsley<[email protected]> wrote: > On Fri, Jul 17, 2009 at 9:08 AM, Bill Baxter<[email protected]> wrote: >> On Fri, Jul 17, 2009 at 5:36 AM, Stewart Gordon<[email protected]> wrote: >>> Steven Schveighoffer wrote: >>> Simple. Once we have a complete D1 spec, major software companies will be >>> ready to implement D. When a major software company implements D, it'll >>> become more widely known to the masses. This'll also pave the way for D to >>> taken up by the software industry on a significant scale. >> >> This is delusional. Major software companies aren't going to start >> implementing D just because the spec is finished. There's no market >> for it when the original compiler is given away for free. And if >> someone really thought there was a major market for a D compiler with >> fewer bugs, I don't think the holes in the spec would stop them from >> trying to implement it. I mean why do you think we have all this >> #ifdef mess in cross -platform C/C++ projects? Everyone implemented >> the spec slightly differently. They clearly were not deterred by the >> fact that they didn't understand the spec 100%. > > But I thought that's exactly what D was trying to *avoid*: being an > implementation nightmare. The very first quote on the front page of > the D site is "Maybe it's time for a new language born out of > practical experience implementing compilers." If D wants to be easy > to implement, shouldn't it have a decent roadmap for doing so? > > Fleshing out the spec is useful for more than just making new > implementations. It also shines light on dark, forgotten corners, > exposing potential bugs and incorrect implementation of the spec in > the reference compiler. It also brings attention to features which > maybe were misdesigned from the start, or which didn't take into > account other features, or which have "rotted" as other features were > added. Improving the spec is not just a matter of documenting what > the compiler does; it improves the language as a whole. > > And from a personal perspective, I've found that in specifying > language features, if it's difficult to explain to others, chances are > it's better off either being left out or being redesigned. It's had a > very beneficial effect on the quality of my own language.
Seems to me like popularity of languages tends to precede detailed specifications generally. Having a 100% complete spec has merits I'm sure but it doesn't really correlate much with language adoption as far as I can tell. Having a language and tool chain that work well and make life easy for programmers seems to have much more importance. Is this incorrect from what you've seen? --bb
