On Wednesday, 26 June 2013 at 19:26:37 UTC, Iain Buclaw wrote:
I can't be bothered to read all points the both of you have mentioned thus far, but I do hope to add a voice of reason to calm you down. ;)
Quick, nurse, the screens! ... or perhaps, "Someone throw a bucket of water over them"? :-P
From a licensing perspective, the only part of the source that can be "closed off" is the DMD backend. Any optimisation fixes in the DMD backend does not affect GDC/LDC.
To be honest, I can't see the "sales value" of optimization fixes in the DMD backend given that GDC and LDC already have such strong performance. The one strong motivation to use DMD over the other two compilers is (as you describe) access to the bleeding edge of features, but I'd have thought this will stop being an advantage in time as/when the frontend becomes a genuinely "plug-and-play" component.
By the way, I hope you didn't feel I was trying to speak on behalf of GDC -- wasn't my intention. :-)
Having used closed source languages in the past, I strongly believe that closed languages do not stimulate growth or adoption at all. And where adoption does occur, knowledge is kept within specialised groups.
Last year I had the dubious privilege of having to work with MS Visual Basic for a temporary job. What was strikingly different from the various open source languages was that although there was an extensive quantity of documentation available from Microsoft, it was incredibly badly organized, much of it was out of date, and there was no meaningful community support that I could find.
I got the job done, but I would surely have had a much easier experience with any of the open source languages out there. Suffice to say that the only reason I used VB in this case was because it was an obligatory part of the work -- I'd never use it by choice.
- The development model of D on github has adopted a "pull, review and merge" system, where any changes to the language or compiler do not go in unless it goes through proper coding review and testing (thank's to the wonderful auto-tester). So your suggestion of an "open core" model has a slight fallacy here in that any changes to the closed off compiler would have to go through the same process to be accepted into the open one - and it might even be rejected.
I had a similar thought but from a slightly different angle -- that allowing "open core" in the frontend would damage the effectiveness of the review process. How can you restrict certain features to proprietary versions without having also a two-tier hierarchy of reviewers? And would you be able to maintain the broader range of community review if some select, paid few had privileged review access?
