DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

[Iain Buclaw]

On Jun 26, 2013 9:00 PM, "Joakim" <joakim at airpost.net> wrote:
>
> On Wednesday, 26 June 2013 at 19:26:37 UTC, Iain Buclaw wrote:
>>
>> 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.
>
> This is flat wrong. I suggest you read the Artistic license, it was
chosen for a reason, ie it allows closing of source as long as you provide
the original, unmodified binaries with any modified binaries.  I suspect
optimization fixes will be in both the frontend and backend.
>

Code generation is in the back end, so the answer to that is simply 'no'.

>> You should try reading The Cathedral and the Bazaar if you don't
understand why an open approach to development has caused the D programming
language to grow by ten fold over the last year or so.
>>
>> If you still don't understand, read it again ad infinitum.
>
> Never read it but I have corresponded with the author, and I found him to
be as religious about pure open source as Stallman is about the GPL.  I
suggest you try examining why D is still such a niche language even with
"ten fold" growth.  If you're not sure why, I suggest you look at the
examples and reasons I've given, as to why closed source and hybrid models
do much better.
>

Then you should read it, as the 'cathedral' in question was GCC - a project
started by Stallman. :)

>> Think I might just point out that GDC had SIMD support before DMD. And
that Remedy used GDC to get their D development off the ground.  It was
features such as UDAs, along with many language bug fixes that were only
available in DMD development that caused them to switch over.
>>
>> In other words, they needed a faster turnaround for bugs at the time
they were adopting D, however the D front-end in GDC stays pretty much
stable on the current release.
>
> Not sure what point you are trying to make, as both gdc and dmd are open
source.  I'm suggesting closing such patches, for a limited time.
>

Closing patches benefit no one.  And more to the point,  you can't say that
two compiler's implement the same language if both have different language
features.

>>> I see no reason why another "upcoming" project like D couldn't do the
same. :)
>>
>>
>> You seem to be confusing D for an Operating System, Smartphone, or any
general consumer product.
>
> You seem to be confusing the dmd compiler to not be a piece of software,
just like the rest, or the many proprietary C++ compilers out there.
>

You seem to think when I say D I'm referring to dmd, or any other D
compiler out there.

>
>> - The language implementation is open source. This allows anyone to take
the current front-end code - or even write their own clean-room
implementation from ground-up - and integrate it to their own backend X.
>
> Sort of.  The dmd frontend is open source, but the backend is not under
an open source license.  Someone can swap out the backend and go completely
closed, for example, using ldc (ldc used to have one or two GPL files,
those would obviously have to be removed).
>

The backend is not part of the D language implementation / specification.
(for starters, it's not documented anywhere except as code).

>> - The compiler itself is not associated with the development of the
language, so those who are owners of the copyright are free to do what they
want with their binary releases.
>>
>> - 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'm not sure why you think "open core" patches that are opened after a
time limit would be any more likely to be rejected from that review
process.  The only fallacy I see here is yours.
>

Where did I say that? I only invited you to speculate on what would happen
if a 'closed patch' got rejected.  This leads back to the point that you
can't call it a compiler for the D programming language if it derives from
the specification / implementation.

>
>> DMD - as in refering to the binary releases - can be closed / paid /
whatever it likes.
>>
>> The D Programming Language - as in the D front-end implementation - is
under a dual GPL/Artistic license and cannot be used by any closed source
product without said product releasing their copy of the front-end sources
also.  This means that your "hybrid" proposal only works for code that is
not under this license - eg: the DMD backend - which is not what the vast
majority of contributors actually submit patches for.
>
> Wrong, you have clearly not read the Artistic license.
>

I'll allow you to keep on thinking that for a while longer...

>> If you strongly believe that a programming language can't be big (as in
1M users) without being partly closed source, I suggest you do your
research better.
>
> I have done my research and provided examples: you provide none.  I
suggest it is you who needs to research this topic.  Start with reading the
Artistic license. :)
>

All I've seen from you from my skim,  snore, skip,  skim are projects
started by multi-millionaire companies who have both resource, influence,
and marketing behind them.  The contributors who have helped design and
shape the D programming language are neither of these.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20130626/093d14dc/attachment.html>