DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

[Joseph Rushton Wakeling]

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?