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