DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

Joakim joakim at airpost.net
Thu Jun 27 01:21:02 PDT 2013


On Wednesday, 26 June 2013 at 21:15:34 UTC, Iain Buclaw wrote:
> On Jun 26, 2013 9:00 PM, "Joakim" <joakim at airpost.net> wrote:
>> 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'.
 From what I understand about the kinds of optimizations that 
Walter was talking about, at least some of them would require 
work on the frontend also.

But lets assume that you are right and the optimization patches 
I'm talking about would tend to end up only in the backend. In 
that case, the frontend would not have any closed patches and the 
paid version of dmd would simply have a slightly-closed, 
more-optimized backend.  There go all of Joseph's previous 
arguments about the paid version not making the same OSS frontend 
available to the free reference compiler or ldc and gdc.

You are making my case for me. :)

>> 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. :)
I'm familiar with its arguments from a summary, not particularly 
interested in reading the whole thing.  Insofar as he made the 
case for various benefits of open source, some of the arguments 
I've heard make sense and I have no problem with it.  Insofar as 
he and others believe that it is an argument for _pure_ open 
source or that _all_ source will eventually be open, I think 
history has shown that argument to be dead wrong along with the 
reasons why.

It boils down to the facts that there is nowhere near as much 
money in pure OSS models and volunteers cannot possibly provide 
all the materials necessary for a full product, both of which 
I've mentioned before.  This is why hybrid models are now taking 
off, blending the benefits of open and closed source.

>> 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.
The closed patches benefit those making money from the paid 
compiler and since the free compiler would get these patches 
after a time limit, they eventually benefit the community also.  
As for your purist approach to compiler implementation, by that 
rationale, no two C++ compilers and all the D compilers do not 
implement the "same language," since there are always differences 
in the features supported by the different compilers.

I'd say that some differentiation between compilers is normal and 
necessary.

>>>> 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.
I referred to the D project and have been talking about the 
compiler all along.  The fact that you decided to make a 
meaningless statement, presumably about how D is a spec and 
therefore cannot be compared with Android, is irrelevant and 
frankly laughable. :)

>>> - 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).
Of course the backend is part of the language implementation.  
It's not part of the spec, but you never mentioned the spec 
originally.

>>> - 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.
Your sentence didn't really make sense as written- it is not a 
"fallacy" that patches might get rejected- so I had to guess what 
you were trying to say.  So what if an optimization patch gets 
rejected?  The OSS reference version would simply continue being 
slower than the slightly-closed, paid version.  They would still 
conform to the same spec.

If it were a new feature like SIMD, I'm sure the reference 
version would implement their own open implementation of that 
feature, if they couldn't wait for the closed patch to be 
released or didn't like it for whatever reason.

As I said earlier, compilers for all languages differ in various 
ways all the time, just as ldc, gdc, and dmd differ in various 
ways today.  It's hardly a deal-breaker.

>>> 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...
Well, in that case, you do not understand it.  The Artistic 
license is not a copyleft license.  You can close up the entire 
dmd frontend and sell a modified binary based on ldc, as long as 
you provide unmodified binaries also.  You repeatedly stated that 
the source must be released, which even a cursory skim of the 
Artistic license would show isn't true.

>> 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.
Perhaps you should read what I wrote more carefully, as your 
arguments are as slipshod as how you claim to have read my posts.

It is true that many of the hybrid projects I've listed have been 
put together by large companies.  But these large companies chose 
hybrid models for a reason, they aren't dumb.  Get the community 
involvement from open source, _and_ the much increased funding 
from the closed source portions.

Also, many of the hybrid projects have pulled in previously 
purely-open, purely community projects like KHTML/WebKit or 
mostly-open projects like the linux kernel.  The linux kernel 
repo evolved over time to include many binary blobs and 
effectively become a hybrid model.

And not all hybrid companies are that large: MySQL before it got 
bought out was pulling in hundreds of millions of dollars in 
revenue using an "open core" model but certainly wasn't in the 
super-sized class of Google or Oracle.  There are a handful of 
small companies that provided closed, optimized versions of the 
PostgreSQL database (since most of the underlying code is open 
source, it can be considered a hybrid model).

There is no reason that a hybrid model wouldn't help a smaller 
project like dmd.  In fact, smaller projects are helped the most 
by hybrid models, as it's the only way for D to professionalize, 
whereas the large companies could have just gone closed-source 
and had the resources to pull that off.


More information about the Digitalmars-d-announce mailing list