www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
reddit: 
http://www.reddit.com/r/programming/comments/1gz40q/dconf_2013_closing_keynote_quo_vadis_by_andrei/

facebook: https://www.facebook.com/dlang.org/posts/662488747098143

twitter: https://twitter.com/D_Programming/status/349197737805373441

hackernews: https://news.ycombinator.com/item?id=5933818

youtube: http://youtube.com/watch?v=4M-0LFBP9AU


Andrei
Jun 24 2013
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
Slides seem to be missing from 
http://dconf.org/2013/talks/alexandrescu.pdf; I get a 404.
Jun 24 2013
parent David Gileadi <gileadis NSPMgmail.com> writes:
On 6/24/13 9:19 AM, David Gileadi wrote:
 Slides seem to be missing from
 http://dconf.org/2013/talks/alexandrescu.pdf; I get a 404.
I posted too soon; they're there now. Sorry for the noise.
Jun 24 2013
prev sibling next sibling parent reply "QAston" <qaston gmail.com> writes:
This may be completely ridiculous - I'm a newcomer - please 
destroy me gently.

So, the idea is to make dlang.org a fundation. Here are some 
possible benefits of doing this:
-You get more people to "own" the language and therefore 
seriously care about it's future development.
--Two people are not enough.
---What if someone gets hit by a bus?
---Delegate some administrative tasks to other people, so you can 
focus on improving things
--Programmers are not all what's needed(the ability to write xml 
parser doesn't make you a good webdev)
---Get a real webdesigner involved
---Someone to do proffessional PR and advertising
---An admin to maintain all these things
-You could start taking donations and hire some people to work on 
D.
--Like for example, you could pay for a proffessional 
"enterprise'y" webdesign for dlang.org.
--Companies want to donate to support tools they're using
--Funding for DSoC
-You'd get more interest from companies
--Managers run companies, not programmers, github is not a 
collaboration for managers
--Increase in trust, things are formal and transparent, not done 
behind the scenes
--They may want to put a part-time developer to work on a 
compiler for example
---Much easier with a formal institution, where the dev would 
actually have something to say and can get things done

There are obviously some issues, like the design by comitee 
problem and possibly others. Still, python, perl, haskell and 
others have foundations. That's probably why those are much 
better   operational proffessionalism.
Jun 24 2013
next sibling parent "QAston" <qaston gmail.com> writes:
On Tuesday, 25 June 2013 at 04:34:02 UTC, QAston wrote:
 This may be completely ridiculous - I'm a newcomer - please 
 destroy me gently.

 So, the idea is to make dlang.org a fundation. Here are some 
 possible benefits of doing this:
 -You get more people to "own" the language and therefore 
 seriously care about it's future development.
 --Two people are not enough.
 ---What if someone gets hit by a bus?
 ---Delegate some administrative tasks to other people, so you 
 can focus on improving things
 --Programmers are not all what's needed(the ability to write 
 xml parser doesn't make you a good webdev)
 ---Get a real webdesigner involved
 ---Someone to do proffessional PR and advertising
 ---An admin to maintain all these things
 -You could start taking donations and hire some people to work 
 on D.
 --Like for example, you could pay for a proffessional 
 "enterprise'y" webdesign for dlang.org.
 --Companies want to donate to support tools they're using
 --Funding for DSoC
 -You'd get more interest from companies
 --Managers run companies, not programmers, github is not a 
 collaboration for managers
 --Increase in trust, things are formal and transparent, not 
 done behind the scenes
 --They may want to put a part-time developer to work on a 
 compiler for example
 ---Much easier with a formal institution, where the dev would 
 actually have something to say and can get things done

 There are obviously some issues, like the design by comitee 
 problem and possibly others. Still, python, perl, haskell and 
 others have foundations. That's probably why those are much 
 better   operational proffessionalism.
Note: I don't want to do a cargo-cult here - simple registering doesn't do magic, yet it's a valid consideration i think, especially if it may help solving some problems pointed out by Andrei.
Jun 25 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/24/13 9:34 PM, QAston wrote:
 This may be completely ridiculous - I'm a newcomer - please destroy me
 gently.

 So, the idea is to make dlang.org a fundation.
That would be nice, and I discussed it with Walter prior to DConf 2013. We temporarily concluded that the overheads and headaches would undo the advantages. Of course, if we had an expert in running a foundation on board, the tradeoffs would change. Andrei
Jun 25 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-25 06:34, QAston wrote:

 ---Get a real webdesigner involved
I would say, as long as the web site is written in ddoc, no real web designer will be interested. -- /Jacob Carlborg
Jun 25 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 1:09 PM, Jacob Carlborg wrote:
 On 2013-06-25 06:34, QAston wrote:

 ---Get a real webdesigner involved
I would say, as long as the web site is written in ddoc, no real web designer will be interested.
The dconf.org website was done by a real web designer who was paid real money, and it's in ddoc.
Jun 25 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/25/13 1:16 PM, Walter Bright wrote:
 On 6/25/2013 1:09 PM, Jacob Carlborg wrote:
 On 2013-06-25 06:34, QAston wrote:

 ---Get a real webdesigner involved
I would say, as long as the web site is written in ddoc, no real web designer will be interested.
The dconf.org website was done by a real web designer who was paid real money, and it's in ddoc.
Truth be told the designer delivered HTML, which we converted to DDoc. Andrei
Jun 25 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 1:19 PM, Andrei Alexandrescu wrote:
 On 6/25/13 1:16 PM, Walter Bright wrote:
 On 6/25/2013 1:09 PM, Jacob Carlborg wrote:
 On 2013-06-25 06:34, QAston wrote:

 ---Get a real webdesigner involved
I would say, as long as the web site is written in ddoc, no real web designer will be interested.
The dconf.org website was done by a real web designer who was paid real money, and it's in ddoc.
Truth be told the designer delivered HTML, which we converted to DDoc.
Yup, but as I recall we specified it with an eye towards easy conversion.
Jun 25 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 22:19, Andrei Alexandrescu wrote:

 Truth be told the designer delivered HTML, which we converted to DDoc.
Ok, I see that "web designer" was properly not the correct word(s). "Web developer" is perhaps better. The one who builds the final format. -- /Jacob Carlborg
Jun 26 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 25 June 2013 at 20:09:46 UTC, Jacob Carlborg wrote:
 I would say, as long as the web site is written in ddoc, no 
 real web designer will be interested.
For my work sites, I often don't give the designer access to the html at all. They have one of two options: make it work with pure css, or send me an image of what it is supposed to look like, and I'll take it from there. Pure css doesn't always work, so sometimes I have to add or rearrange some html stuff for them, but it usually actually *does* work, after they get over their initial "this is impossible" stage. ddoc would be even easier than this, since the main website skeleton is just a piece of html anyway (see dmd2/src/phobos/std.ddoc and the macro DDOC = ).
Jun 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-25 23:45, Adam D. Ruppe wrote:

 For my work sites, I often don't give the designer access to the html at
 all. They have one of two options: make it work with pure css, or send
 me an image of what it is supposed to look like, and I'll take it from
 there.
"web designer" was properly not the best word(s). I would say that you're talking about the graphical designer I was talking about the one implementing the design, web developer/frontend developer or what to call it. I wouldn't give the graphical designer access to the code either. It needs to be integrated with the backend code (which is Ruby or similar) anyway, to fetch the correct data and so on. -- /Jacob Carlborg
Jun 26 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 26 June 2013 at 10:18:58 UTC, Jacob Carlborg wrote:
 that you're talking about the graphical designer I was talking 
 about the one implementing the design, web developer/frontend 
 developer or what to call it.
Ah yes. Still though, I don't think ddoc is that big of a deal, especially since there's a few of us here who can do the translations if needed.
 I wouldn't give the graphical designer access to the code 
 either. It needs to be integrated with the backend code (which 
 is Ruby or similar) anyway, to fetch the correct data and so on.
Right.
Jun 26 2013
prev sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 25 June 2013 at 20:09:46 UTC, Jacob Carlborg wrote:
 On 2013-06-25 06:34, QAston wrote:

 ---Get a real webdesigner involved
I would say, as long as the web site is written in ddoc, no real web designer will be interested.
There is no need for designer to know what DDOC is. For the past few years I have worked with many designers which had only basic knowledge about HTML and even less about CSS (most of them don't know anything about JavaScript but they "know jQuery a bit"). They just give me PSD and I do slicing and all coding. So if any redesign of dlang.org is going to happen I volunteer to do all coding, so there is no need to look for designer which is comfortable writing DDOC.
Jun 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-26 00:55, Aleksandar Ruzicic wrote:

 There is no need for designer to know what DDOC is. For the past few
 years I have worked with many designers which had only basic knowledge
 about HTML and even less about CSS (most of them don't know anything
 about JavaScript but they "know jQuery a bit"). They just give me PSD
 and I do slicing and all coding.
Again, "web designer" was not the correct word(s). Something more like web developer/frontend developer, who ever writes the final format.
 So if any redesign of dlang.org is going to happen I volunteer to do all
 coding, so there is no need to look for designer which is comfortable
 writing DDOC.
Ok, good. -- /Jacob Carlborg
Jun 26 2013
prev sibling parent reply "ixid" <nuaccount gmail.com> writes:
-You could start taking donations and hire some people to work on
D. This doesn't work as it's a volunteer project. Why should someone get paid when others give their time for free? It would create conflict while being a less effective application of funds, D already gets more than one or two people years of effort per year. A better use of the money is another D conference which has been a huge success and generated both ideas and much greater interest and exposure for D.
Jun 27 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/27/13, ixid <nuaccount gmail.com> wrote:
-You could start taking donations and hire some people to work on
A better use of the money is another D conference which has been a huge success and generated both ideas and much greater interest and exposure for D.
Yes, and some better glue for the microphones. :P
Jun 27 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 27 June 2013 at 21:39:28 UTC, ixid wrote:
-You could start taking donations and hire some people to work 
on
D. This doesn't work as it's a volunteer project. Why should someone get paid when others give their time for free? It would create conflict while being a less effective application of funds, D already gets more than one or two people years of effort per year. A better use of the money is another D conference which has been a huge success and generated both ideas and much greater interest and exposure for D.
I don't think paying people should be out of the question, if there was money available. There are often jobs that need doing on a project the size of D that aren't fun, stimlating or interesting, but are still absolutely necessary. Trawling through documentation for any errors/omissions etc. comes to mind. These tasks could be split up in to manageable chunks and offered as freelance contracts for a modest but reasonable wage, dependant on urgency, technical skill needed etc. E.g. If someone would pay me even as little as $15-20 an hour to go through phobos enforcing the style guide everywhere or chasing up old bugs in bugzilla, I would happily put in a few hours a week. For a student that sort of money goes a long way. (Not suggesting that paying per hour is a good idea necessarily, just illustrating the point with an example)
Jun 27 2013
prev sibling next sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 25/06/13 02:13, Andrei Alexandrescu wrote:
 reddit:
 http://www.reddit.com/r/programming/comments/1gz40q/dconf_2013_closing_keynote_quo_vadis_by_andrei/


 facebook: https://www.facebook.com/dlang.org/posts/662488747098143

 twitter: https://twitter.com/D_Programming/status/349197737805373441

 hackernews: https://news.ycombinator.com/item?id=5933818

 youtube: http://youtube.com/watch?v=4M-0LFBP9AU


 Andrei
Can you think of a better name than "D Summer Of Code"? It's very northern hemisphere centric and makes us southerners feel like the rest of the world doesn't know there is a southern hemisphere (or if they do that they don't know the seasons work) :-). Peter
Jun 24 2013
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Tuesday, 25 June 2013 at 05:57:30 UTC, Peter Williams wrote:

 Can you think of a better name than "D Summer Of Code"?  It's 
 very northern hemisphere centric and makes us southerners feel 
 like the rest of the world doesn't know there is a southern 
 hemisphere (or if they do that they don't know the seasons 
 work) :-).

 Peter
D Season of Code! Then we don't have to restrict ourselves to one time of the year.
Jun 25 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 25 June 2013 at 08:21:38 UTC, Mike Parker wrote:
 On Tuesday, 25 June 2013 at 05:57:30 UTC, Peter Williams wrote:
 D Season of Code! Then we don't have to restrict ourselves to 
 one time of the year.
D Seasons of Code! Why to restrict to a single season? Let's code all the year long! :)
Jun 26 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 26 June 2013 15:04, eles <eles eles.com> wrote:
 On Tuesday, 25 June 2013 at 08:21:38 UTC, Mike Parker wrote:
 On Tuesday, 25 June 2013 at 05:57:30 UTC, Peter Williams wrote:
 D Season of Code! Then we don't have to restrict ourselves to one time of
 the year.
D Seasons of Code! Why to restrict to a single season? Let's code all the year long! :)
Programmers need to hibernate too, you know. ;) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 26 2013
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Peter Williams, el 25 de June a las 15:57 me escribiste:
 On 25/06/13 02:13, Andrei Alexandrescu wrote:
reddit:
http://www.reddit.com/r/programming/comments/1gz40q/dconf_2013_closing_keynote_quo_vadis_by_andrei/


facebook: https://www.facebook.com/dlang.org/posts/662488747098143

twitter: https://twitter.com/D_Programming/status/349197737805373441

hackernews: https://news.ycombinator.com/item?id=5933818

youtube: http://youtube.com/watch?v=4M-0LFBP9AU


Andrei
Can you think of a better name than "D Summer Of Code"? It's very northern hemisphere centric and makes us southerners feel like the rest of the world doesn't know there is a southern hemisphere (or if they do that they don't know the seasons work) :-).
Or they know, but they just don't give a fuck :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- The average person laughs 13 times a day
Jun 25 2013
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/24/2013 10:57 PM, Peter Williams wrote:

 Can you think of a better name than "D Summer Of Code"?  It's very
 northern hemisphere centric and makes us southerners feel like the rest
 of the world doesn't know there is a southern hemisphere
The only southern country is Mexico, which I am told is in the Northern hemisphere. :p Ali
Jun 25 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 25 Jun 2013 15:57:18 +1000
Peter Williams <pwil3058 bigpond.net.au> wrote:
 
 Can you think of a better name than "D Summer Of Code"?  It's very 
 northern hemisphere centric and makes us southerners feel like the
 rest of the world doesn't know there is a southern hemisphere (or if
 they do that they don't know the seasons work) :-).
 
I'm pretty sure the southern hemisphere has summer too...It's just a lot colder ;) Nobody called it "D Warm-Summer of Code".
Jun 25 2013
next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 26/06/13 06:14, Nick Sabalausky wrote:
 On Tue, 25 Jun 2013 15:57:18 +1000
 Peter Williams <pwil3058 bigpond.net.au> wrote:
 Can you think of a better name than "D Summer Of Code"?  It's very
 northern hemisphere centric and makes us southerners feel like the
 rest of the world doesn't know there is a southern hemisphere (or if
 they do that they don't know the seasons work) :-).
I'm pretty sure the southern hemisphere has summer too...It's just a lot colder ;) Nobody called it "D Warm-Summer of Code".
Not all of it. In tropical Australia, they have two seasons - the wet season (aka the suicide season) and the dry season :-). Peter
Jun 25 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 26 June 2013 09:59, Peter Williams <pwil3058 bigpond.net.au> wrote:

 On 26/06/13 06:14, Nick Sabalausky wrote:

 On Tue, 25 Jun 2013 15:57:18 +1000
 Peter Williams <pwil3058 bigpond.net.au> wrote:

 Can you think of a better name than "D Summer Of Code"?  It's very
 northern hemisphere centric and makes us southerners feel like the
 rest of the world doesn't know there is a southern hemisphere (or if
 they do that they don't know the seasons work) :-).
I'm pretty sure the southern hemisphere has summer too...It's just a lot colder ;) Nobody called it "D Warm-Summer of Code".
Not all of it. In tropical Australia, they have two seasons - the wet season (aka the suicide season) and the dry season :-).
I like to think of it as the soaking bloody wet season, and the slightly less wet season ;) Slightly more tolerable than indonesia, which has only a single 'soaking wet at precisely 4pm every day, but otherwise lovely weather (if you like humidity) season'...
Jun 25 2013
prev sibling next sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
I'm a Danish guy so there is a at least one dane using D :)

/Jonas
Jun 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 11:42, Jonas Drewsen wrote:

 I'm a Danish guy so there is a at least one dane using D :)
Tomas Lindquist Olsen, creator of LDC (LLVMDC back then) is Danish, if I recall correctly. -- /Jacob Carlborg
Jun 25 2013
prev sibling next sibling parent reply "Joakim" <joakim airpost.net> writes:
Just finished watching Andrei's talk, it was up to his usual high 
standard.

I found the bits about professionalism a bit weird though: can we 
really expect that from a volunteer effort?  I'm pretty sure the 
A/V guys at the conference weren't volunteers, ie they were paid.

Along the line that QAston started, if you want more 
professionalism, is there any interest in producing a commercial 
D compiler?  If not, why not?  I notice that Walter sells C and 
C++ compilers and source on digitalmars.com, but strangely not D. 
  There are interesting business/source models nowadays where you 
can be mostly open source and still sell a commercial product.

For example, Walter has often talked about optimizations in the 
compiler that he'd like to get to.  There could be two compilers: 
one where the source is fully publicly available, another made 
available to paying users, which has additional optimizations 
done either by Walter or others who he supervises, but the source 
for those optimizations would not be available publicly, though 
perhaps made available only to the buyers under a non-OSS 
license.  After enough time has passed for the optimization work 
to be paid for, the optimization patches would eventually be 
merged into the slower, non-paid version.  Android uses a similar 
hybrid model, which has obviously been enormously successful.

Another possibility is a bounty system, where users pledge money 
towards needed features or bug fixes.  It'd basically be a more 
distributed version of the hybrid approach I've outlined.

I wonder what the response would be to injecting some money and 
commercialism into the D ecosystem.
Jun 25 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 25 June 2013 at 15:44:02 UTC, Joakim wrote:
 Just finished watching Andrei's talk, it was up to his usual 
 high standard.

 I found the bits about professionalism a bit weird though: can 
 we really expect that from a volunteer effort?  I'm pretty sure 
 the A/V guys at the conference weren't volunteers, ie they were 
 paid.

 Along the line that QAston started, if you want more 
 professionalism, is there any interest in producing a 
 commercial D compiler?  If not, why not?  I notice that Walter 
 sells C and C++ compilers and source on digitalmars.com, but 
 strangely not D.
  There are interesting business/source models nowadays where 
 you can be mostly open source and still sell a commercial 
 product.

 For example, Walter has often talked about optimizations in the 
 compiler that he'd like to get to.  There could be two 
 compilers: one where the source is fully publicly available, 
 another made available to paying users, which has additional 
 optimizations done either by Walter or others who he 
 supervises, but the source for those optimizations would not be 
 available publicly, though perhaps made available only to the 
 buyers under a non-OSS license.  After enough time has passed 
 for the optimization work to be paid for, the optimization 
 patches would eventually be merged into the slower, non-paid 
 version.  Android uses a similar hybrid model, which has 
 obviously been enormously successful.

 Another possibility is a bounty system, where users pledge 
 money towards needed features or bug fixes.  It'd basically be 
 a more distributed version of the hybrid approach I've outlined.

 I wonder what the response would be to injecting some money and 
 commercialism into the D ecosystem.
Given how D's whole success stems from its community, I think an "open core" model (even with time-lapse) would be disastrous. It'd be like kicking everyone in the teeth after all the work they put in.
Jun 25 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 25 June 2013 at 20:58:16 UTC, Joseph Rushton Wakeling 
wrote:
 I wonder what the response would be to injecting some money 
 and commercialism into the D ecosystem.
Given how D's whole success stems from its community, I think an "open core" model (even with time-lapse) would be disastrous. It'd be like kicking everyone in the teeth after all the work they put in.
I don't know the views of the key contributors, but I wonder if they would have such a knee-jerk reaction against any paid/closed work. The current situation would seem much more of a kick in the teeth to me: spending time trying to be "professional," as Andrei asks, and producing a viable, stable product used by a million developers, corporate users included, but never receiving any compensation for this great tool you've poured effort into, that your users are presumably often making money with. I understand that such a shift from being mostly OSS to having some closed components can be tricky, but that depends on the particular community. I don't think any OSS project has ever become popular without having some sort of commercial model attached to it. C++ would be nowhere without commercial compilers; linux would be unheard of without IBM and Red Hat figuring out a consulting/support model around it; and Android would not have put the linux kernel on hundreds of millions of computing devices without the hybrid model that Google employed, where they provide an open source core, paid for through increased ad revenue from Android devices, and the hardware vendors provide closed hardware drivers and UI skins on top of the OSS core. This talk prominently mentioned scaling to a million users and being professional: going commercial is the only way to get there.
Jun 25 2013
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jun 25, 2013 at 2:37 PM, Joakim <joakim airpost.net> wrote:

 On Tuesday, 25 June 2013 at 20:58:16 UTC, Joseph Rushton Wakeling wrote:

 I wonder what the response would be to injecting some money and
 commercialism into the D ecosystem.
Given how D's whole success stems from its community, I think an "open core" model (even with time-lapse) would be disastrous. It'd be like kicking everyone in the teeth after all the work they put in.
I don't know the views of the key contributors, but I wonder if they would have such a knee-jerk reaction against any paid/closed work. The current situation would seem much more of a kick in the teeth to me: spending time trying to be "professional," as Andrei asks, and producing a viable, stable product used by a million developers, corporate users included, but never receiving any compensation for this great tool you've poured effort into, that your users are presumably often making money with. I understand that such a shift from being mostly OSS to having some closed components can be tricky, but that depends on the particular community. I don't think any OSS project has ever become popular without having some sort of commercial model attached to it. C++ would be nowhere without commercial compilers; linux would be unheard of without IBM and Red Hat figuring out a consulting/support model around it; and Android would not have put the linux kernel on hundreds of millions of computing devices without the hybrid model that Google employed, where they provide an open source core, paid for through increased ad revenue from Android devices, and the hardware vendors provide closed hardware drivers and UI skins on top of the OSS core. This talk prominently mentioned scaling to a million users and being professional: going commercial is the only way to get there.
IDEs are something you can have a freemium model for. Core languages are not these days. If you have to pay to get the optimized version of the language there are just too many other places to look that don't charge. You want the best version of the language to be in everyone's hands. But there can be some tools you have to pay for. http://www.wingware.com/ is a good example of a commercial Python IDE that adds value to the community with a commercial offering. I paid for a copy back when I was doing a lot of python development. It is definitely not a business I would want to be in, though. I was surprised to see they are still alive, actually. Hard to make much money selling things to developers. --bb
Jun 25 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 26 June 2013 at 01:25:42 UTC, Bill Baxter wrote:
 On Tue, Jun 25, 2013 at 2:37 PM, Joakim <joakim airpost.net> 
 wrote:
 This talk prominently mentioned scaling to a million users and 
 being
 professional: going commercial is the only way to get there.
IDEs are something you can have a freemium model for. Core languages are not these days. If you have to pay to get the optimized version of the language there are just too many other places to look that don't charge. You want the best version of the language to be in everyone's hands... Hard to make much money selling things to developers.
I agree that there is a lot of competition for programming languages. However, Visual Studio brought in $400 million in extensions alone a couple years back: http://blogs.msdn.com/b/somasegar/archive/2011/04/12/happy-1st-birthday-visual-studio-2010.aspx Microsoft doesn't break out numbers for Visual Studio itself, but it might be a billion+ dollars a year, not to mention all the other commercial C++ compilers out there. If the aim is to displace C++ and gain a million users, it is impossible to do so without commercial implementations. All the languages that you are thinking about that do no offer a single commercial implementation- remember, even Perl and Python have commercial options, eg ActiveState- have almost no usage compared to C++. It is true that there are large companies like Apple or Sun/Oracle that give away a lot of tooling for free, but D doesn't have such corporate backing. It is amazing how far D has gotten with no business model: money certainly isn't everything. But it is probably impossible to get to a million users or offer professionalism without commercial implementations. In any case, the fact that the D front-end is under the Artistic license and most of the rest of the code is released under similarly liberal licensing means that someone can do this on their own, without any other permission from the community, and I expect that if D is successful, someone will. I'm simply suggesting that the original developers jump-start that process by doing it themselves, in the hybrid form I've suggested, rather than potentially getting cut out of the decision-making process when somebody else does it.
Jun 25 2013
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Joakim, el 26 de June a las 08:33 me escribiste:
 It is amazing how far D has gotten with no business model: money
 certainly isn't everything.  But it is probably impossible to get to
 a million users or offer professionalism without commercial
 implementations.
Yeah, right, probably Python and Ruby have only 5k users... This argument is BS. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Are you such a dreamer? To put the world to rights? I'll stay home forever Where two & two always makes up five
Jun 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-26 12:16, Leandro Lucarella wrote:

 Yeah, right, probably Python and Ruby have only 5k users...
There are companies backing those languages, at least Ruby, to some extent. -- /Jacob Carlborg
Jun 26 2013
next sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 26 June 2013 at 12:39:05 UTC, Jacob Carlborg wrote:
 On 2013-06-26 12:16, Leandro Lucarella wrote:

 Yeah, right, probably Python and Ruby have only 5k users...
There are companies backing those languages, at least Ruby, to some extent.
They don't own them, though -- they commit resources to them because the language's ongoing development serves their business needs.
Jun 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-26 15:18, Joseph Rushton Wakeling wrote:

 They don't own them, though -- they commit resources to them because the
 language's ongoing development serves their business needs.
Yes, exactly. -- /Jacob Carlborg
Jun 26 2013
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Jacob Carlborg, el 26 de June a las 14:39 me escribiste:
 On 2013-06-26 12:16, Leandro Lucarella wrote:
 
Yeah, right, probably Python and Ruby have only 5k users...
There are companies backing those languages, at least Ruby, to some extent.
Read my other post, I won't repeat myself :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- JUNTAN FIRMAS Y HUELLAS POR EL CACHORRO CONDENADO A MUERTE... -- Crónica TV
Jun 26 2013
prev sibling next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Joakim, el 25 de June a las 23:37 me escribiste:
 On Tuesday, 25 June 2013 at 20:58:16 UTC, Joseph Rushton Wakeling
 wrote:
I wonder what the response would be to injecting some money and
commercialism into the D ecosystem.
Given how D's whole success stems from its community, I think an "open core" model (even with time-lapse) would be disastrous. It'd be like kicking everyone in the teeth after all the work they put in.
I don't know the views of the key contributors, but I wonder if they would have such a knee-jerk reaction against any paid/closed work.
Against being paid no, against being closed YES. Please don't even think about it. It was a hell of a ride trying to make D more open to step back now. What we need is companies paying to people to improve the compiler and toolchain. This is slowly starting to happen, in Sociomantic we are already 2 people dedicating some time to improve D as part of our job (Don and me). We need more of this, and to get this, we need companies to start using D, and to get this, we need professionalism (I agree 100% with Andrei on this one). Is a bootstrap effort, and is not like volunteers need more time to be professional, is just that you have to want to make the jump. I think is way better to do less stuff but with higher quality, nobody is asking people for more time, is just changing the focus a bit, at least for some time. Again, this is only bootstrapping, and is always hard and painful. We need to make the jump to make companies comfortable using D, then things will start rolling by themselves.
 The current situation would seem much more of a kick in the teeth to
 me: spending time trying to be "professional," as Andrei asks, and
 producing a viable, stable product used by a million developers,
 corporate users included, but never receiving any compensation for
 this great tool you've poured effort into, that your users are
 presumably often making money with.
 
 I understand that such a shift from being mostly OSS to having some
 closed components can be tricky, but that depends on the particular
 community.  I don't think any OSS project has ever become popular
 without having some sort of commercial model attached to it.  C++
 would be nowhere without commercial compilers; linux would be
 unheard of without IBM and Red Hat figuring out a consulting/support
 model around it; and Android would not have put the linux kernel on
 hundreds of millions of computing devices without the hybrid model
 that Google employed, where they provide an open source core, paid
 for through increased ad revenue from Android devices, and the
 hardware vendors provide closed hardware drivers and UI skins on top
 of the OSS core.
First of all, your examples are completely wrong. The projects you are mentioning are 100% free, with no closed components (except for components done by third-party). Your examples are just reinforcing what I say above. Linux is completely GPL, so it's not even only open source. Is Free Software, meaning the license if more restrictive than, for example, phobos. This means is harder to adopt by companies and you can't possibly change it in a closed way if you want to distribute a binary. Same for C++, which is not a project, is a standards, but the most successful and widespread compiler, GCC, not only is free, is the battle horse of free software, of the GNU project and created by the most extremist free software advocate ever. Android might be the only valid case (but I'm not really familiar with Android model), but the kernel, since is based on Linux, has to have the source code when released. Maybe the drivers are closed source. You are missing more closely related projects, like Python, Haskel, Ruby, Perl, and probably 90% of the newish programming languages, which are all 100% open source. And very successful I might say. The key is always breaking into the corporate ground and make those corporations contribute. There are valid examples of project using hybrid models but they are usually software as a service models, not very applicable to a compiler/language, like Wordpress, or other web applications. Other valid examples are MySQL, or QT I think used an hybrid model at least once. Lots of them died and were resurrected as 100% free projects, like StarOffice -> OpenOffice -> LibreOffice. And finally making the *optimizer* (or some optimizations) closed will be hardly a good business, being that there are 2 other backends out there that usually kicks DMD backend ass already, so people needing more speed will probably just switch to gdc or ldc.
 This talk prominently mentioned scaling to a million users and being
 professional: going commercial is the only way to get there.
As in breaking into the commercial world? Then agreed. If you imply commercial == closing some parts of the source, then I think you are WAY OFF. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- According to several sources Dr. Harvey Kellogg tried to make a cure for masturbation When he made cornflakes
Jun 26 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 26 June 2013 at 11:08:17 UTC, Leandro Lucarella 
wrote:
 Android might be the only valid case (but I'm not really 
 familiar with Android model), but the kernel, since is based on 
 Linux, has to have the source code when
 released. Maybe the drivers are closed source.
It is perfectly open http://source.android.com/source/licenses.html ;) Drivers tend to be closed source, but drivers are not part fo Android project, they are private to vendors.
Jun 26 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 26 June 2013 at 11:08:17 UTC, Leandro Lucarella 
wrote:
 Joakim, el 25 de June a las 23:37 me escribiste:
 I don't know the views of the key contributors, but I wonder 
 if they
 would have such a knee-jerk reaction against any paid/closed 
 work.
Against being paid no, against being closed YES. Please don't even think about it. It was a hell of a ride trying to make D more open to step back now.
I suggest you read my original post more carefully. I have not suggested closing up the entire D toolchain, as you seem to imply. I have suggested working on optimization patches in a closed-source manner and providing two versions of the D compiler: one that is faster, closed, and paid, with these optimization patches, another that is slower, open, and free, without the optimization patches. Over time, the optimization patches are merged back to the free branch, so that the funding from the closed compiler makes even the free compiler faster, but only after some delay so that users who value performance will actually pay for the closed compiler. There can be a hard time limit, say nine months, so that you know any closed patches from nine months back will be opened and applied to the free compiler. I suspect that the money will be good enough so that any bugfixes or features added by the closed developers will be added to the free compiler right away, with no delay.
 What we need is companies paying to people to improve the
 compiler and toolchain. This is slowly starting to happen, in
 Sociomantic we are already 2 people dedicating some time to 
 improve D as
 part of our job (Don and me).
Thanks for the work that you and Don have done with Sociomantic. Why do you think more companies don't do this? My point is that if there were money coming in from a paid compiler, Walter could fund even more such work.
 We need more of this, and to get this, we need companies to 
 start using
 D, and to get this, we need professionalism (I agree 100% with 
 Andrei on
 this one). Is a bootstrap effort, and is not like volunteers 
 need more
 time to be professional, is just that you have to want to make 
 the jump.
I think this ignores the decades-long history we have with open source software by now. It is not merely "wanting to make the jump," most volunteers simply do not want to do painful tasks like writing documentation or cannot put as much time into development when no money is coming in. Simply saying "We have to try harder to be professional" seems naive to me.
 I think is way better to do less stuff but with higher quality, 
 nobody
 is asking people for more time, is just changing the focus a 
 bit, at
 least for some time. Again, this is only bootstrapping, and is 
 always
 hard and painful. We need to make the jump to make companies 
 comfortable
 using D, then things will start rolling by themselves.
If I understand your story right, the volunteers need to put a lot of effort into "bootstrapping" the project to be more professional, companies will see this and jump in, then they fund development from then on out? It's possible, but is there any example you have in mind? The languages that go this completely FOSS route tend not to have as much adoption as those with closed implementations, like C++.
 First of all, your examples are completely wrong. The projects 
 you are
 mentioning are 100% free, with no closed components (except for
 components done by third-party).
You are misstating what I said: I said "commercial," not "closed," and gave different examples of commercial models. But lets look at them.
 Your examples are just reinforcing what
 I say above. Linux is completely GPL, so it's not even only 
 open source.
 Is Free Software, meaning the license if more restrictive than, 
 for
 example, phobos. This means is harder to adopt by companies and 
 you
 can't possibly change it in a closed way if you want to 
 distribute
 a binary.
And yet the linux kernel ships with many binary blobs, almost all the time. I don't know how they legally do it, considering the GPL, yet it is much more common to run a kernel with binary blobs than a purely FOSS version. The vast majority of linux installs are due to Android and every single one has significant binary blobs and closed-source modifications to the Android source, which is allowed since most of Android is under the more liberal Apache license, with only the linux kernel under the GPL. Again, I don't know how they get away with all the binary drivers in the kernel, perhaps that is a grey area with the GPL. For example, even the most open source Android devices, the Nexus devices sold directly by Google and running stock Android, have many binary blobs: https://developers.google.com/android/nexus/drivers Other than Android, linux is really only popular on servers, where you can "change it in a closed way" because you are not "distributing a binary." Google takes advantage of this to run linux on a million servers powering their search engine, but does not release the proprietary patches for their linux kernel. So if one looks at linux in any detail, hybrid models are more the norm than the exception, even with the GPL. :)
 Same for C++, which is not a project, is a standards, but the
 most successful and widespread compiler, GCC, not only is free, 
 is the
 battle horse of free software, of the GNU project and created 
 by the
 most extremist free software advocate ever.
D is not just a project but a standard also. I wouldn't say gcc is the "most successful and widespread compiler," that's probably Microsoft's compiler, since Windows market share is still much more than linux. But yes, gcc is a very popular open-source implementation: I didn't say there wouldn't be an open-source D compiler also. But I don't think C++ would be where it is today if only open-source implementations like gcc supported it, which is the case today with D.
 Android might be the only
 valid case (but I'm not really familiar with Android model), 
 but the
 kernel, since is based on Linux, has to have the source code 
 when
 released. Maybe the drivers are closed source.
As I said earlier, most devices' drivers are almost always closed and the non-GPL parts of Android, which are the majority, are usually customized and the source is usually not released, because most of Android is Apache-licensed. I think this closed option is a key reason for the success of Android. Hell, the hardware vendors would never have adopted Android if not for this, as Google well knew.
 You are missing more closely related projects, like Python, 
 Haskel,
 Ruby, Perl, and probably 90% of the newish programming 
 languages, which
 are all 100% open source. And very successful I might say. The 
 key is
 always breaking into the corporate ground and make those 
 corporations
 contribute.
I believe all of these projects have commercial implementations, with the possible exception of Haskell. Still, all of them combined have much less market share than C++, possibly because they use the weaker consulting/support commercial model most of the time. One of the main reasons C++ is much more popular is that it has very high-performance closed implementations, do you disagree? I'm suggesting D will need something similar to get as popular.
 There are valid examples of project using hybrid models but 
 they are
 usually software as a service models, not very applicable to
 a compiler/language, like Wordpress, or other web applications. 
 Other
 valid examples are MySQL, or QT I think used an hybrid model at 
 least
 once. Lots of them died and were resurrected as 100% free 
 projects, like
 StarOffice -> OpenOffice -> LibreOffice.
There are all kinds of hybrid models out there, some would work for compilers also. I think it's instructive that you are listing some of the largest and most successful, mostly-OSS projects in this list. :)
 And finally making the *optimizer* (or some optimizations) 
 closed will
 be hardly a good business, being that there are 2 other 
 backends out
 there that usually kicks DMD backend ass already, so people 
 needing more
 speed will probably just switch to gdc or ldc.
Let me turn this argument around on you: if there is always competition from ldc and gdc, why are you so scared of another option of a slightly-closed, paid compiler? If it's not "a good business," it will fail and go away. I think it would be very successful.
 As in breaking into the commercial world? Then agreed. If you 
 imply
 commercial == closing some parts of the source, then I think 
 you are WAY
 OFF.
OK, so it looks like you are fine with commercial models that keep all the source open, but not with those that close _any_ of the source. The problem is that your favored consulting or support models are much weaker business models than a product model, which is much of the reason why Microsoft still makes almost two orders of magnitude more revenue with their software products than Red Hat makes with their consulting/support model. I am suggesting a unique hybrid product model because I think it will bring in the most money for the least discomfort. That ratio is one that D developers often talk about optimizing in technical terms, I'm suggesting the same in business terms. :)
 It is amazing how far D has gotten with no business model: 
 money
 certainly isn't everything.  But it is probably impossible to 
 get to
 a million users or offer professionalism without commercial
 implementations.
Yeah, right, probably Python and Ruby have only 5k users... This argument is BS.
First off, they both have commercial implementations. Second, they still only have a small fraction of the share as C++: part of this is probably because they don't have as many closed, performant implementations as C++ does. I realize this is a religious issue for some people and they cannot be convinced. In a complex, emerging field like this, it is easy to claim that if OSS projects just try harder, they can succeed. But after two decades, it has never happened, without stepping back and employing a hybrid model. I have examined the evidence and presented arguments for those who are willing to listen, as I'm just about pragmatically using whatever model works best. I think recent history has shown that hybrid models work very well, possibly the best. :)
Jun 26 2013
next sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 26 June 2013 at 15:52:33 UTC, Joakim wrote:
 I suggest you read my original post more carefully.  I have not 
 suggested closing up the entire D toolchain, as you seem to 
 imply.  I have suggested working on optimization patches in a 
 closed-source manner and providing two versions of the D 
 compiler: one that is faster, closed, and paid, with these 
 optimization patches, another that is slower, open, and free, 
 without the optimization patches.

 Over time, the optimization patches are merged back to the free 
 branch, so that the funding from the closed compiler makes even 
 the free compiler faster, but only after some delay so that 
 users who value performance will actually pay for the closed 
 compiler.  There can be a hard time limit, say nine months, so 
 that you know any closed patches from nine months back will be 
 opened and applied to the free compiler.  I suspect that the 
 money will be good enough so that any bugfixes or features 
 added by the closed developers will be added to the free 
 compiler right away, with no delay.
Perhaps you'd like to explain to the maintainers of GDC and LDC why, after all they've done for D, you think it would be acceptable to turn to them and say: "Hey guys, we're going to make improvements and keep them from you for 9 months so we can make money" ... ? Or doesn't the cooperative relationship between the 3 main D compilers mean much to you?
 Thanks for the work that you and Don have done with 
 Sociomantic.  Why do you think more companies don't do this?  
 My point is that if there were money coming in from a paid 
 compiler, Walter could fund even more such work.
Leaving aside the moral issues, you might consider that any work paid for by revenues would be offset by a drop in voluntary contributions, including corporate contributors. And sensible companies will avoid "open core" solutions. A few articles worth reading on these factors: http://webmink.com/essays/monetisation/ http://webmink.com/essays/open-core/ http://webmink.com/essays/donating-money/
 I think this ignores the decades-long history we have with open 
 source software by now.  It is not merely "wanting to make the 
 jump," most volunteers simply do not want to do painful tasks 
 like writing documentation or cannot put as much time into 
 development when no money is coming in.  Simply saying "We have 
 to try harder to be professional" seems naive to me.
Odd that you talk about ignoring things, because the general trend we've seen in the decades-long history of free software is that the software business seems to getting more and more open with every year. These days there's a strong expectation of free licensing.
 If I understand your story right, the volunteers need to put a 
 lot of effort into "bootstrapping" the project to be more 
 professional, companies will see this and jump in, then they 
 fund development from then on out?  It's possible, but is there 
 any example you have in mind?  The languages that go this 
 completely FOSS route tend not to have as much adoption as 
 those with closed implementations, like C++.
It's hardly fair to compare languages without also taking into account their relative age. C++ has its large market share substantially due to historical factors -- it was a major "first mover", and until the advent of D, it was arguably the _only_ language that had that combination of power/flexibility and performance. So far as compiler implementations are concerned, I'd say that it was the fact that there were many different implementations that helped C++. On the other hand, proprietary implementations may in some ways have damaged adoption, as before standardization you'd have competing, incompatible proprietary versions which limited the portability of code.
 And yet the linux kernel ships with many binary blobs, almost 
 all the time.  I don't know how they legally do it, considering 
 the GPL, yet it is much more common to run a kernel with binary 
 blobs than a purely FOSS version.  The vast majority of linux 
 installs are due to Android and every single one has 
 significant binary blobs and closed-source modifications to the 
 Android source, which is allowed since most of Android is under 
 the more liberal Apache license, with only the linux kernel 
 under the GPL.
The binary blobs are nevertheless part of the vanilla kernel, not something "value added" that gets charged for. They're irrelevant to the development model of the kernel -- they are an irritation that's tolerated for practical reasons, rather than a design feature.
 Again, I don't know how they get away with all the binary 
 drivers in the kernel, perhaps that is a grey area with the 
 GPL.  For example, even the most open source Android devices, 
 the Nexus devices sold directly by Google and running stock 
 Android, have many binary blobs:

 https://developers.google.com/android/nexus/drivers

 Other than Android, linux is really only popular on servers, 
 where you can "change it in a closed way" because you are not 
 "distributing a binary."  Google takes advantage of this to run 
 linux on a million servers powering their search engine, but 
 does not release the proprietary patches for their linux kernel.

 So if one looks at linux in any detail, hybrid models are more 
 the norm than the exception, even with the GPL. :)
But no one is selling proprietary extensions to the kernel (not that they could anyway, but ...). They're building services that _use_ the kernel, and in building those services they sometimes write patches to serve particular needs. In a similar way, other companies are building services using D and sometimes they write replacements for existing D functionality that better serve their needs (e.g. Leandro's GC work).
 I believe all of these projects have commercial 
 implementations, with the possible exception of Haskell.  
 Still, all of them combined have much less market share than 
 C++, possibly because they use the weaker consulting/support 
 commercial model most of the time.  One of the main reasons C++ 
 is much more popular is that it has very high-performance 
 closed implementations, do you disagree?  I'm suggesting D will 
 need something similar to get as popular.
C++'s popularity is most likely largely down to historical contingency. It was a first-mover in its particular design, and use begets use. What you should rather be thinking of is: can you think of _any_ major new programming language (as in, rising to prominence in the last 10 years and enjoying significant cross-platform success) that wasn't open source? The only one I can think of is C#, which was able to succeed simply because if Microsoft makes a particular language a key tool for Windows development, that language will get used. But the others? The reference versions are all open.
 Let me turn this argument around on you: if there is always 
 competition from ldc and gdc, why are you so scared of another 
 option of a slightly-closed, paid compiler?  If it's not "a 
 good business," it will fail and go away.  I think it would be 
 very successful.
No one is scared of the idea of a slightly or even wholly closed, paid compiler -- anyone is free to implement one and try to sell it. People are objecting to the idea of the reference implementation of the D language being distributed in a two-tier version with advanced features only available to paying customers. You need to understand the difference between proprietary implementations of a language existing, versus the mainstream development work on the language following any kind of proprietary model.
 OK, so it looks like you are fine with commercial models that 
 keep all the source open, but not with those that close _any_ 
 of the source.
For the reference implementation of the D language? Absolutely.
 The problem is that your favored consulting or support models 
 are much weaker business models than a product model, which is 
 much of the reason why Microsoft still makes almost two orders 
 of magnitude more revenue with their software products than Red 
 Hat makes with their consulting/support model.
Microsoft is a virtual monopolist in at least two areas of commercial software -- desktop OS and office document suites. The business models that work for them are not necessarily going to bring success for other organizations. A large part of Red Hat's success comes from the fact that it offers customers a different deal from Microsoft.
 I am suggesting a unique hybrid product model because I think 
 it will bring in the most money for the least discomfort.  That 
 ratio is one that D developers often talk about optimizing in 
 technical terms, I'm suggesting the same in business terms. :)
I suggest that you have not thought through the variety of different business options available. It is a shame that your first thought for commercialization of D was "Let's close bits of it up!" instead of, "How can I make a successful commercial model of D that works _with_ its wonderful open community?"
 First off, they both have commercial implementations.  Second, 
 they still only have a small fraction of the share as C++: part 
 of this is probably because they don't have as many closed, 
 performant implementations as C++ does.
The reference implementations are free software, and if they weren't, they'd never have got any decent traction.
 I realize this is a religious issue for some people and they 
 cannot be convinced.  In a complex, emerging field like this, 
 it is easy to claim that if OSS projects just try harder, they 
 can succeed.  But after two decades, it has never happened, 
 without stepping back and employing a hybrid model.
I think your understanding of free software history is somewhat flawed, and that you conflate rather too many quite different business models under the single title of "hybrid". (To take just one of your examples, Red Hat's consulting/support model is not the same as paying for closed additions to the software. The _software_ of Red Hat Enterprise Linux is still free!) You also don't seem to readily appreciate the differences between what works for software services, versus what works for programming languages -- or the impact that free vs. non-free can have on adoption rates. (D might have gained more traction much earlier, if not for fears around the DMD backend.)
 I have examined the evidence and presented arguments for those 
 who are willing to listen, as I'm just about pragmatically 
 using whatever model works best.  I think recent history has 
 shown that hybrid models work very well, possibly the best. :)
Please name a recent successful programming language (other than those effectively imposed by diktat by big players like Microsoft or Apple) that did not build its success around a reference implementation that is free software. Then we'll talk. :-)
Jun 26 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 26 June 2013 at 17:28:22 UTC, Joseph Rushton 
Wakeling wrote:
 Perhaps you'd like to explain to the maintainers of GDC and LDC 
 why, after all they've done for D, you think it would be 
 acceptable to turn to them and say: "Hey guys, we're going to 
 make improvements and keep them from you for 9 months so we can 
 make money" ... ?
Why are they guaranteed such patches? They have advantages because they use different compiler backends. If they think their backends are so great, let them implement their own optimizations and compete.
 Or doesn't the cooperative relationship between the 3 main D 
 compilers mean much to you?
As I've noted in an earlier response, LDC could also provide a closed version and license those patches.
 Leaving aside the moral issues, you might consider that any 
 work paid for by revenues would be offset by a drop in 
 voluntary contributions, including corporate contributors.  And 
 sensible companies will avoid "open core" solutions.
Or maybe the work paid by revenues would be far more and even more people would volunteer, when D becomes a more successful project through funding from the paid compiler. Considering how dominant "open core" and other hybrid models are these days, it is laughable that you suggest that anyone is avoiding it. :)
 A few articles worth reading on these factors:
 http://webmink.com/essays/monetisation/
 http://webmink.com/essays/open-core/
 http://webmink.com/essays/donating-money/
I have corresponded with the author of that blog before. I found him to be a religious zealot who recounted the four freedoms of GNU to me like a mantra. Perhaps that's why Sun was run into the ground when they followed his ideas about open sourcing most everything. I don't look to him for worthwhile reading on these issues.
 I think this ignores the decades-long history we have with 
 open source software by now.  It is not merely "wanting to 
 make the jump," most volunteers simply do not want to do 
 painful tasks like writing documentation or cannot put as much 
 time into development when no money is coming in.  Simply 
 saying "We have to try harder to be professional" seems naive 
 to me.
Odd that you talk about ignoring things, because the general trend we've seen in the decades-long history of free software is that the software business seems to getting more and more open with every year. These days there's a strong expectation of free licensing.
Yes, it is getting "more and more open," because hybrid models are being used more. :) Pure open source software, with no binary blobs, has almost no adoption, so it isn't your preferred purist approach that is doing well. And the reasons are the ones I gave, volunteers can do a lot of things, but there are a lot of things they won't do.
 It's hardly fair to compare languages without also taking into 
 account their relative age.  C++ has its large market share 
 substantially due to historical factors -- it was a major 
 "first mover", and until the advent of D, it was arguably the 
 _only_ language that had that combination of power/flexibility 
 and performance.
Yes, C++ has been greatly helped by its age.
 So far as compiler implementations are concerned, I'd say that 
 it was the fact that there were many different implementations 
 that helped C++.  On the other hand, proprietary 
 implementations may in some ways have damaged adoption, as 
 before standardization you'd have competing, incompatible 
 proprietary versions which limited the portability of code.
But you neglect to mention that most of those "many different implementations" were closed. I agree that completely closed implementations can also cause incompatibilities, which is why I have suggested a hybrid model with limited closed-source patches.
 The binary blobs are nevertheless part of the vanilla kernel, 
 not something "value added" that gets charged for.  They're 
 irrelevant to the development model of the kernel -- they are 
 an irritation that's tolerated for practical reasons, rather 
 than a design feature.
They are not always charged for, but they put the lie to the claims that linux uses a pure open source model. Rather, it is usually a different kind of hybrid model. If it were so pure, there would be no blobs at all. The blobs are certainly not irrelevant, as linux wouldn't run on all the hardware that needs those binary blobs, if they weren't included. Not sure what to make of your non sequitur of binary blobs not being a "design feature." As for paying for blobs, I'll note that the vast majority of linux kernels installed are in Android devices, where one pays for the hardware _and_ the development effort to develop the blobs that run the hardware. So paying for the "value added" from blobs seems to be a very successful model. :)
 So if one looks at linux in any detail, hybrid models are more 
 the norm than the exception, even with the GPL. :)
But no one is selling proprietary extensions to the kernel (not that they could anyway, but ...). They're building services that _use_ the kernel, and in building those services they sometimes write patches to serve particular needs.
Nobody said they were writing "proprietary extensions to the kernel." The point is that almost all linux kernels in use are used with binary blobs or a proprietary-patched Android stack on top. Therefore, linux implementations benefit from a different kind of hybrid model, but linux certainly isn't purely open source most of the time.
 In a similar way, other companies are building services using D 
 and sometimes they write replacements for existing D 
 functionality that better serve their needs (e.g. Leandro's GC 
 work).
And I'm similarly proposing that there be a D compiler that has better, closed-source optimizations but is paid, with the optimizations guaranteed to be open sourced after some time. I'm not sure why you draw the line there.
 C++'s popularity is most likely largely down to historical 
 contingency.  It was a first-mover in its particular design, 
 and use begets use.
You keep trying to pin C++'s age as the only reason why it is popular, and while I don't deny that its early entry helped, I don't think it is quite as determinative as you do.
 What you should rather be thinking of is: can you think of 
 _any_ major new programming language (as in, rising to 
 prominence in the last 10 years and enjoying significant 
 cross-platform success) that wasn't open source?
Java wasn't open source initially, but it was open sourced after its success. Objective-C has become very popular recently with the rise of iOS. I read that Apple open-sourced their patches to gcc, because of the GPL, but kept their Obj-C runtime libraries closed. More recently, they have switched to the BSD-licensed LLVM/clang and they may be using a hybrid model there, tough to tell. I cannot think of any other language that is in the same stratosphere as C and C++: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
 The only one I can think of is C#, which was able to succeed 
 simply because if Microsoft makes a particular language a key 
 tool for Windows development, that language will get used.

 But the others?  The reference versions are all open.
Nobody has suggested otherwise for D. I've suggested an open reference version and a faster, paid version with some closed-source patches. This sort of mix of commercial and OSS implementations appears to be the dominant model, for a language with any adoption.
 No one is scared of the idea of a slightly or even wholly 
 closed, paid compiler -- anyone is free to implement one and 
 try to sell it.
Of course. You could even take ldc and do it, as the license allows it.
 People are objecting to the idea of the reference 
 implementation of the D language being distributed in a 
 two-tier version with advanced features only available to 
 paying customers.

 You need to understand the difference between proprietary 
 implementations of a language existing, versus the mainstream 
 development work on the language following any kind of 
 proprietary model.
Nobody is unaware of the difference; I have always said that Walter would put out an open reference version alongside a slightly-closed paid version. Why do you object to that?
 Microsoft is a virtual monopolist in at least two areas of 
 commercial software -- desktop OS and office document suites.  
 The business models that work for them are not necessarily 
 going to bring success for other organizations.  A large part 
 of Red Hat's success comes from the fact that it offers 
 customers a different deal from Microsoft.
I can list dozens of other product companies that make orders of magnitude more revenue than the consulting/support companies, OSS or not, that you prefer: Oracle, SAP, Apple, on and on, not to mention all the hybrid models I've already listed. I simply mentioned Microsoft because they sell the most compilers, but if you want to compare all such product companies, it's a rout. :)
 I suggest that you have not thought through the variety of 
 different business options available.  It is a shame that your 
 first thought for commercialization of D was "Let's close bits 
 of it up!" instead of, "How can I make a successful commercial 
 model of D that works _with_ its wonderful open community?"
On the contrary, I have examined many of these business options over the years. I _was_ answering the latter need, I just think the former is the best way to do it, as long as you open source the closed patches after a guaranteed time limit. I suggest instead that it is you who has not thought through or examined the evidence that your preferred pure-OSS models don't work as well.
 First off, they both have commercial implementations.  Second, 
 they still only have a small fraction of the share as C++: 
 part of this is probably because they don't have as many 
 closed, performant implementations as C++ does.
The reference implementations are free software, and if they weren't, they'd never have got any decent traction.
I believe C++ was originally licensed by AT&T, so it wasn't free software when it got popular. The others you may have in mind are nowhere near as popular.
 I realize this is a religious issue for some people and they 
 cannot be convinced.  In a complex, emerging field like this, 
 it is easy to claim that if OSS projects just try harder, they 
 can succeed.  But after two decades, it has never happened, 
 without stepping back and employing a hybrid model.
I think your understanding of free software history is somewhat flawed, and that you conflate rather too many quite different business models under the single title of "hybrid". (To take just one of your examples, Red Hat's consulting/support model is not the same as paying for closed additions to the software. The _software_ of Red Hat Enterprise Linux is still free!)
If my history is flawed, you could provide an example. :) I believe Red Hat uses the same binary blobs that the linux kernel provides, so it is not pure open source and can be classified as hybrid. I think they also bundle in their own closed-source software on top, though I've never paid them.
 You also don't seem to readily appreciate the differences 
 between what works for software services, versus what works for 
 programming languages -- or the impact that free vs. non-free 
 can have on adoption rates.  (D might have gained more traction 
 much earlier, if not for fears around the DMD backend.)
I suggest that this assertion is best leveled at you. :) I think D would gain much more traction now, if it were making money from a paid version.
 I have examined the evidence and presented arguments for those 
 who are willing to listen, as I'm just about pragmatically 
 using whatever model works best.  I think recent history has 
 shown that hybrid models work very well, possibly the best. :)
Please name a recent successful programming language (other than those effectively imposed by diktat by big players like Microsoft or Apple) that did not build its success around a reference implementation that is free software. Then we'll talk. :-)
I am not going to attack your strawman, as I have not suggested that there shouldn't be a reference implementation for D that is open source. I have simply suggested an additional paid version that funds development for both versions. Let me throw your request back at you, with the _appropriate_ details: please name a recent successful programming language that achieved any kind of success and _didn't_ have commercial support or implementations. Alternately, name one that came anywhere close to the massive popularity of C++ with only a consulting/support model. The evidence is not on your side. :)
Jun 26 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 26 June 2013 at 19:01:42 UTC, Joakim wrote:
 Why are they guaranteed such patches?  They have advantages 
 because they use different compiler backends.  If they think 
 their backends are so great, let them implement their own 
 optimizations and compete.
I could respond at greater length, but I think that substantial flaws of your point of view are exposed in this single paragraph. GDC and LDC aren't competitors, they are valuable collaborators.
Jun 26 2013
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Joakim, el 26 de June a las 17:52 me escribiste:
 On Wednesday, 26 June 2013 at 11:08:17 UTC, Leandro Lucarella wrote:
Joakim, el 25 de June a las 23:37 me escribiste:
I don't know the views of the key contributors, but I wonder if
they
would have such a knee-jerk reaction against any paid/closed
work.
Against being paid no, against being closed YES. Please don't even think about it. It was a hell of a ride trying to make D more open to step back now.
I suggest you read my original post more carefully. I have not suggested closing up the entire D toolchain, as you seem to imply.
Well, I'm not. I'm sticking with what you said.
 I have suggested working on optimization patches in a closed-source
 manner and providing two versions of the D compiler: one that is
 faster, closed, and paid, with these optimization patches, another
 that is slower, open, and free, without the optimization patches.
I know, and that's what my e-mail was all about. I don't know why you got another impression. I even end the e-mail saying is a very bad business model too to just offer a paid better optimizer.
What we need is companies paying to people to improve the
compiler and toolchain. This is slowly starting to happen, in
Sociomantic we are already 2 people dedicating some time to
improve D as
part of our job (Don and me).
Thanks for the work that you and Don have done with Sociomantic. Why do you think more companies don't do this? My point is that if
Because D is a new language and isn't as polished as other programming languages. I think Sociomantic was a bit crazy to adopt it so early really (my personal opinion). But it worked well (we had to do quite a lot extra efforts but I guess the time it saves in the daily usage paid for it).
 there were money coming in from a paid compiler, Walter could fund
 even more such work.
Well, I think with a paid compiler you remove one of the main reasons why early adopters can be tempted to use D, because is free. What I'm sure is Sociomantic wouldn't pick D if they had to paid at that time, because it was a statup and startup usually don't have much money at first.
We need more of this, and to get this, we need companies to start
using D, and to get this, we need professionalism (I agree 100% with
Andrei on this one). Is a bootstrap effort, and is not like
volunteers need more time to be professional, is just that you have
to want to make the jump.
I think this ignores the decades-long history we have with open source software by now. It is not merely "wanting to make the jump," most volunteers simply do not want to do painful tasks like writing documentation or cannot put as much time into development when no money is coming in. Simply saying "We have to try harder to be professional" seems naive to me.
Well, I guess we have very different views about the decades-long history of open source software, because I know tons of examples of applications being free, without "commercial implementations" or "paid modules" and very few with a more commercial model. Even more, the few examples I know of "paid modules" are quite recent, not decades-old.
I think is way better to do less stuff but with higher quality,
nobody is asking people for more time, is just changing the focus
a bit, at least for some time. Again, this is only bootstrapping, and
is always hard and painful. We need to make the jump to make
companies comfortable using D, then things will start rolling by
themselves.
If I understand your story right, the volunteers need to put a lot of effort into "bootstrapping" the project to be more professional, companies will see this and jump in, then they fund development from then on out? It's possible, but is there any example you have in mind? The languages that go this completely FOSS route tend not to have as much adoption as those with closed implementations, like C++.
Are you kidding me? Python, Ruby, PHP, Perl. Do I have to say more than that? Do you really think C++ took off because there are commercial implementations? Do you think being a standardized language didn't help? Do you think the fact that there was a free implementation around that it supported virtually any existing platform didn't help? Do you think the fact was it was (almost) compatible with C (which was born freeish, since back then software was freely shared between universities) didn't help?
First of all, your examples are completely wrong. The projects you
are mentioning are 100% free, with no closed components (except for
components done by third-party).
You are misstating what I said: I said "commercial," not "closed,"
You said close. Not just in the previous e-mail, but you just repeated it in this one:
 I have suggested working on optimization patches in a CLOSED-SOURCE
 manner and providing two versions of the D compiler: one that is
 faster, CLOSED, and paid, with these optimization patches, another
 that is slower, open, and free, without the optimization patches.
I think you are misstating yourself ;)
Your examples are just reinforcing what
I say above. Linux is completely GPL, so it's not even only open
source.  Is Free Software, meaning the license if more restrictive
than, for example, phobos. This means is harder to adopt by companies
and you can't possibly change it in a closed way if you want to
distribute a binary.
And yet the linux kernel ships with many binary blobs, almost all the time. I don't know how they legally do it, considering the GPL, yet it is much more common to run a kernel with binary blobs than a purely FOSS version. The vast majority of linux installs are due to
That's because the binary blobs are not part of the kernel, is firmware for certain (crappy) hardware that needs the firmware to be loaded to work. For convenience, the kernel distribute it so this (crappy) hardware can work out of the box. But this is produced by third-parties, not kernel developers. This is a completely different example and is giving NO MONEY AT ALL to linux development.
 Android and every single one has significant binary blobs and
 closed-source modifications to the Android source, which is allowed
 since most of Android is under the more liberal Apache license, with
 only the linux kernel under the GPL.
OK, so by Android you mean the entire platform, not the kernel.
 Again, I don't know how they get away with all the binary drivers in
 the kernel, perhaps that is a grey area with the GPL.  For example,
 even the most open source Android devices, the Nexus devices sold
 directly by Google and running stock Android, have many binary
 blobs:
 
 https://developers.google.com/android/nexus/drivers
Again, but this gives is not a model adopted to make money to improve Android, this is just drivers third-party do so android can run in their devices. See the difference? Is not like Android developers said: "we need money to be able to code Android more professionally, so we are going to write closed source driver and sell them!". The companies making the closed source drivers are the hardware retailers.
 Other than Android, linux is really only popular on servers, where
 you can "change it in a closed way" because you are not
 "distributing a binary."  Google takes advantage of this to run
 linux on a million servers powering their search engine, but does
 not release the proprietary patches for their linux kernel.
They do contribute with the mainline kernel though (not as much as they should). But then I think you are digressing a little. You were saying D should offer an improved, closed source, paid optimizer to raise money to improve the quality of the compiler. How this Google example applies to this?
 So if one looks at linux in any detail, hybrid models are more the
 norm than the exception, even with the GPL. :)
Google taking advantage of the flaws of GPL 2.0 doesn't mean the Linux kernel is implemented an hybrid closed/open source model. What you are saying doesn't make any sense, you are mixing everything together. Seriously. The Linux kernel have NO hybrid model, is 100% opensource. Then, there are companies using it, and when they are forced, or it is convenient for them, they contribute to Linux. And this is what I'm suggesting is best for D too. We have to either force or make it convenient to companies to contribute.
Same for C++, which is not a project, is a standards, but the most
successful and widespread compiler, GCC, not only is free, is the
battle horse of free software, of the GNU project and created by the
most extremist free software advocate ever.
D is not just a project but a standard also.
No. A standard is something that was standardized by a standard committee which, ideally, have some credits to do so. C++ is standardized by ISO. I guess Walter and Andrei can give you more details, since I think they both were involved in the standardization of C++. D is a language specification and a reference implementation. Which is not the same.
 I wouldn't say gcc is the "most successful and widespread compiler,"
 that's probably Microsoft's compiler, since Windows market share is
 still much more than linux.
Are you counting devices or just personal computing? You know all Android phones don't use Microsoft compiler, you know all your gadgets don't user Microsoft compiler, you know your car software was not compiled with Microsoft compiler, same your TV and so many other stuff.
 But yes, gcc is a very popular open-source implementation: I didn't
 say there wouldn't be an open-source D compiler also.  But I don't
 think C++ would be where it is today if only open-source
 implementations like gcc supported it, which is the case today with D.
And how do you explain the success of languages that don't have (at least major) commercial implementations like Perl, PHP, Python or Ruby? Or even Go? I think Go is much more suitable for companies right now than D, because in Go they put a lot of emphasis in the toolchain and polishing the tools. You might say "Go was done by Google" and is true. But there are NO COMMERCIAL implementations. Only free. And they are tempting for companies because Go development is professional (thanks to Google support of course). The thing is, again, we need companies support. Not commercial implementations. Well, commercial implementations are welcome though, what we certainly don't need is the reference implementation being (partly) closed.
Android might be the only valid case (but I'm not really familiar
with Android model), but the kernel, since is based on Linux, has to
have the source code when released. Maybe the drivers are closed
source.
As I said earlier, most devices' drivers are almost always closed and the non-GPL parts of Android, which are the majority, are usually customized and the source is usually not released, because most of Android is Apache-licensed. I think this closed option is a key reason for the success of Android. Hell, the hardware vendors would never have adopted Android if not for this, as Google well knew.
Again, I think this is a bad example because those closed sourced elements are not making money to support Android developers. Is what hardware retailers need to do to make their phones work with Android and they don't want to release the code of their drivers.
You are missing more closely related projects, like Python, Haskel,
Ruby, Perl, and probably 90% of the newish programming languages,
which are all 100% open source. And very successful I might say. The
key is always breaking into the corporate ground and make those
corporations contribute.
I believe all of these projects have commercial implementations, with the possible exception of Haskell.
Name them please. I would like to know them.
 Still, all of them combined have much less market share than C++
[citation needed] Not that they are extremely reliable, but sites measuring language popularity say Python+PHP+Perl+Ruby have more share than C++. TIOBE sais: P+P+P+R=13.922 vs C++=8.819 The Transparent Language Popularity Index sais: P+P+P=R=11.354 vs C++=7.544 Also C++ have 10 years advantage, and 10 REALLY good years, where there were almost no alternatives, so I'm guessing there is a lot of legacy C++ code. It would be good to have numbers on the popularity of languages for NEW projects. The 4 most popular languages are old C/C-derived. Java is the only exception, but it had a massive marketing campaign among corporations, and even when now is free, I think is, with C#, the only languages that were born as one-only closed source implementation.
 possibly because they use the weaker consulting/support commercial
 model most of the time.  One of the main reasons C++ is much more
 popular is that it has very high-performance closed implementations,
 do you disagree?
Yes. I think Java is the example you have in mind, not C++. For the reasons I explain above. I think C++ was popular because it had a high-performance open source implementation. 30 years ago.
 I'm suggesting D will need something similar to get as popular.
And I'm trying to prove you are wrong, that D needs to be popular is to get professional without sacrificing openness. Is because this model is dying that one of the most popular languages switched from a closed source model to an open source one (Java).
There are valid examples of project using hybrid models but they are
usually software as a service models, not very applicable to
a compiler/language, like Wordpress, or other web applications.
Other valid examples are MySQL, or QT I think used an hybrid model at
least once. Lots of them died and were resurrected as 100% free
projects, like StarOffice -> OpenOffice -> LibreOffice.
There are all kinds of hybrid models out there, some would work for compilers also. I think it's instructive that you are listing some of the largest and most successful, mostly-OSS projects in this list. :)
As failed or counter examples :)
And finally making the *optimizer* (or some optimizations) closed
will be hardly a good business, being that there are 2 other backends
out there that usually kicks DMD backend ass already, so people
needing more speed will probably just switch to gdc or ldc.
Let me turn this argument around on you: if there is always competition from ldc and gdc, why are you so scared of another option of a slightly-closed, paid compiler?
I'm not scared. I'm against it for the reference implementation that went through a lot of pain to become more open. DMD started as closed source. There is a big difference. I'll be more than happy to receive a closed source commercial implementation that is not based on open source contributed by the community, which is what you suggested really.
 If it's not "a good business," it will fail and go away.  I think it
 would be very successful.
Start your own company and make a D compiler then! I wish you very good luck! :)
As in breaking into the commercial world? Then agreed. If you imply
commercial == closing some parts of the source, then I think you are
WAY OFF.
OK, so it looks like you are fine with commercial models that keep all the source open, but not with those that close _any_ of the source.
Again, I think you are mixing a lot of stuff together. If you speak about a random company, I'm fine with them doing whatever they like, free, closed, open, whatever. If we are talking about the reference implementation for D that now is mostly-opensource and free software, yes, I'm against closing sources and no, I'm not against commercial models and earning money to pay to contributors.
 The problem is that your favored consulting or support models are
 much weaker business models than a product model, which is much of
 the reason why Microsoft still makes almost two orders of magnitude
 more revenue with their software products than Red Hat makes with
 their consulting/support model.
So now we want D to be an enterprise which goal is to make as much money as possible? Yes, I favor slightly less lucrative models in favor of having an open source reference implementation.
 I am suggesting a unique hybrid product model because I think it
 will bring in the most money for the least discomfort.  That ratio
 is one that D developers often talk about optimizing in technical
 terms, I'm suggesting the same in business terms. :)
Well, we disagree for both ethical and business reasons. Your only example of a commercial compiler making money is Microsoft. You know, we are not Microsoft, we don't have the market share Microsoft have and we can't impose our products like they can. I think selling a slightly more optimized DMD will be a huge failure for the reasons I already said. I think it would be even a better model to offer a more polished toolchain instead of a slightly faster compiler. I don't think speed is an issue for anyone right now. Maybe Walter can have a meaningful opinion about this, being he has been selling compiler for quite some time now.
It is amazing how far D has gotten with no business model: money
certainly isn't everything.  But it is probably impossible to get to
a million users or offer professionalism without commercial
implementations.
Yeah, right, probably Python and Ruby have only 5k users... This argument is BS.
First off, they both have commercial implementations. Second, they
I've been looking for commercial implementations of Ruby and Python. Hard. I only found one for Ruby, RubyMotion, which is only for iOS, which seems to be unsupported by the official Ruby interpreter (or any other free implementation). So is not really relevant in this case. I couldn't find any commercial python implementation. If you have some, please share, but the fact that I couldn't find any suggests if they exist, they are not very popular, and thus not really helping Python or Ruby adoption.
 still only have a small fraction of the share as C++: part of this
 is probably because they don't have as many closed, performant
 implementations as C++ does.
Again I think your reasoning behind C++ is more popular, C++ have closed implementations -> C++ is more popular because it has closed implementations, is way too simplistic (and wrong). I'm also not convinced the closed implementations are more "performant" than the open ones. MS Visual C++, done by the company that makes loads of money, seems to be crap from the benchmarks I found: http://www.g-truc.net/post-0372.html ICC is supposed to be one of the fastest compilers. If you look at their own benchmarks, they say they are better than GCC, at least for some integer and floating point benchmarks), but I don't trust people doing their own benchmarks very much: http://software.intel.com/en-us/intel-composer-xe (go to benchmark tab) A question in stackoverflow seems to indicate that the different isn't that clear: http://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc Also there is this presentation from MySQL comparing ICC and GCC: http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2004-Intel.pdf In this case they see an important improvement using ICC, but the GCC version used is quite old, I wonder how they compare now. Is strange that there are not really many benchmarks comparing compiler out there. Another indication that speed in C++ is not much of a selling point for compilers. And from what I could find out is not clear there is a huge gain in performance when using closed source compilers. With Visual C++ is even clearly worse, and according to you that's the most widespread C++ compiler.
 I realize this is a religious issue for some people and they cannot
 be convinced.  In a complex, emerging field like this, it is easy to
 claim that if OSS projects just try harder, they can succeed.  But
 after two decades, it has never happened, without stepping back and
 employing a hybrid model.
 
 I have examined the evidence and presented arguments for those who
 are willing to listen, as I'm just about pragmatically using
 whatever model works best.  I think recent history has shown that
 hybrid models work very well, possibly the best. :)
Is true, there are people that base his view on religious believes. Here I presented you lots of proof, with numbers and examples to justify what I say. You, on the contrary, just claimed unfunded statements. There is also our own experience. When DMD was closed source it received almost 0 contributions, of course. Each and every step taken to make the compiler more open shielded more and more contributions. You want more proof and more numbers, you can take a look at this: http://www.llucax.com.ar/blog/blog/post/6cac01e1 This is even pre-git, with git the number of contributions AND THE COMPILER quality increased exponentially. Unfortunately I don't have any numbers on D adoption. I also explained why I think your particular hybrid model is bad business. D's adoption and improvement advanced slow because it WAS closed source, it improved a lot with openness. Because all of this, I find it very hard to believe the model you are proposing would be beneficial for D, from a reason stand point there is no evidence that could happen. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS -- Crónica TV
Jun 27 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
I agree with your post, I just want to make a couple of minor corrections.

On 6/27/2013 4:58 AM, Leandro Lucarella wrote:
 Do you really think C++ took off because there are commercial
 implementations?
I got into the C++ fray in the 1987-88 time frame. At the time, there was a great debate between C++ and Objective-C, and they were running neck-and-neck. I was casting about looking for a way to get a competitive edge with my C compiler, and investigated. Objective-C was put out by Stepstone. They wanted royalties from anyone who implemented a clone, and kept a tight fist over the licensing. C++ only existed in its AT&T cfront implementation. I wrote a letter to AT&T's lawyers, asking if I could create a C++ clone, and they phoned me up and were very nice. They said sure, and I wouldn't have to pay any license or royalties. So I went with C++. I don't really know if cfront was open source at the time or not, but I never looked at its source. I think cfront source came with a paid license for unix, but I'm not positive. Anyhow, I wound up implementing the first native C++ compiler for the PC. Directly afterward, C++ took off like a rocket. Was it because of Zortech C++? I think there's strong evidence it was. A lot of programmers turned up their noses at the peasants programming on DOS, but that's where the action was in the 1980's, and ZTC++ had no realistic competitors. You could also see the results in Usenet. Postings about C++ and O-C were neck-and-neck until ZTC++ came out, and then things tilted heavily in C++'s favor, and O-C disappeared into oblivion (later to be resurrected by Steve Jobs, but that's another tale). ZTC++ was so successful that Borland and Microsoft (according to rumor) abandoned their efforts at making a proprietary OOP C, and went with C++. ZTC++ was closed source, as were Borland's Turbo C++ and Microsoft C++.
 Do you think being a standardized language didn't help?
C++ wasn't standardized until 1998, 10 years later. The 90's were pretty much the heyday of C++.
 Do you think the fact that there was a free implementation around that
 it supported virtually any existing platform didn't help? Do you think
 the fact was it was (almost) compatible with C (which was born freeish,
 since back then software was freely shared between universities) didn't
 help?
ZTC++ was cheap as dirt, and at the time people didn't mind paying for compilers. Those days are over, though. People have different expectations today.
 No. A standard is something that was standardized by a standard
 committee which, ideally, have some credits to do so. C++ is
 standardized by ISO. I guess Walter and Andrei can give you more
 details, since I think they both were involved in the standardization of
 C++.
I've attended a few ISO C++ meetings, but I never became a voting member, and have had pretty much zero influence over the direction C++ took after the 1980's. The bottom line was the open source movement was not a very significant force in the 1980's when C++ gained traction. Open source really exploded around 2000, along with the internet. I wonder if open source perhaps needed the internet in order to be viable.
Jun 29 2013
next sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Saturday, 29 June 2013 at 08:37:48 UTC, Walter Bright wrote:
 The bottom line was the open source movement was not a very 
 significant force in the 1980's when C++ gained traction. Open 
 source really exploded around 2000, along with the internet. I 
 wonder if open source perhaps needed the internet in order to 
 be viable.
That's a very good point. It's before my time really, but if I understand the history right, the main way to get hold of copies of stuff like GCC in the early days was to pay for a set of disks with it on -- and there was no infrastructure for easily sharing changes. So neither the free-as-in-beer or free-as-in-freedom advantages were as readily apparent or effective as they are today.
Jun 29 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2013 5:08 AM, Joseph Rushton Wakeling wrote:
 On Saturday, 29 June 2013 at 08:37:48 UTC, Walter Bright wrote:
 The bottom line was the open source movement was not a very significant force
 in the 1980's when C++ gained traction. Open source really exploded around
 2000, along with the internet. I wonder if open source perhaps needed the
 internet in order to be viable.
That's a very good point. It's before my time really, but if I understand the history right, the main way to get hold of copies of stuff like GCC in the early days was to pay for a set of disks with it on -- and there was no infrastructure for easily sharing changes. So neither the free-as-in-beer or free-as-in-freedom advantages were as readily apparent or effective as they are today.
True, distribution was mainly by physical mail. There was some via BBS's and Usenet, but these were severely limited by bandwidth. I'd receive bug reports by fax, paper listings, and mailed floppies.
Jun 29 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 30 June 2013 at 03:29:06 UTC, Walter Bright wrote:
 On 6/29/2013 5:08 AM, Joseph Rushton Wakeling wrote:
 True, distribution was mainly by physical mail. There was some 
 via BBS's and Usenet, but these were severely limited by 
 bandwidth.

 I'd receive bug reports by fax, paper listings, and mailed 
 floppies.
This was also the heyday of the BBC Micro in UK schools, and I remember well the shelves full of books of sample programs in BBC Basic. We had lots of fun typing them up, working out how they worked, and then twisting them to our more evil designs.
Jul 02 2013
prev sibling next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el 29 de June a las 01:37 me escribiste:
 The bottom line was the open source movement was not a very
 significant force in the 1980's when C++ gained traction. Open
 source really exploded around 2000, along with the internet. I
 wonder if open source perhaps needed the internet in order to be
 viable.
Yes, I think that's the whole point, without Internet open source was extremely niche, without resources to distribute it, it was almost impossible to take off, and almost impossible to collaborate, which is the big different open source have vs traditional commercial software. Even when extremely interesting, I think the ZTC++ history before open source existed or was really viable (the free software movement started in 1983, the FSF was founded in 1985 and the open source definition was made in 1998) is irrelevant in terms to analyze if right now it would be valuable to make the reference compiler partly closed. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- EL PRIMER MONITO DEL MILENIO... -- Crónica TV
Jun 29 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2013 9:10 AM, Leandro Lucarella wrote:
 Even when extremely interesting, I think the ZTC++ history before open
 source existed or was really viable (the free software movement started
 in 1983, the FSF was founded in 1985 and the open source definition was
 made in 1998) is irrelevant in terms to analyze if right now it would be
 valuable to make the reference compiler partly closed.
Yes, I agree. Things are fundamentally different now.
Jun 29 2013
prev sibling next sibling parent reply "CJS" <Prometheus85 hotmail.com> writes:
On Saturday, 29 June 2013 at 08:37:48 UTC, Walter Bright wrote:
 I agree with your post, I just want to make a couple of minor 
 corrections.

 On 6/27/2013 4:58 AM, Leandro Lucarella wrote:
 Do you really think C++ took off because there are commercial
 implementations?
I got into the C++ fray in the 1987-88 time frame. At the time, there was a great debate between C++ and Objective-C, and they were running neck-and-neck. I was casting about looking for a way to get a competitive edge with my C compiler, and investigated. Objective-C was put out by Stepstone. They wanted royalties from anyone who implemented a clone, and kept a tight fist over the licensing. C++ only existed in its AT&T cfront implementation. I wrote a letter to AT&T's lawyers, asking if I could create a C++ clone, and they phoned me up and were very nice. They said sure, and I wouldn't have to pay any license or royalties. So I went with C++. I don't really know if cfront was open source at the time or not, but I never looked at its source. I think cfront source came with a paid license for unix, but I'm not positive. Anyhow, I wound up implementing the first native C++ compiler for the PC. Directly afterward, C++ took off like a rocket. Was it because of Zortech C++? I think there's strong evidence it was. A lot of programmers turned up their noses at the peasants programming on DOS, but that's where the action was in the 1980's, and ZTC++ had no realistic competitors. You could also see the results in Usenet. Postings about C++ and O-C were neck-and-neck until ZTC++ came out, and then things tilted heavily in C++'s favor, and O-C disappeared into oblivion (later to be resurrected by Steve Jobs, but that's another tale). ZTC++ was so successful that Borland and Microsoft (according to rumor) abandoned their efforts at making a proprietary OOP C, and went with C++. ZTC++ was closed source, as were Borland's Turbo C++ and Microsoft C++.
 Do you think being a standardized language didn't help?
C++ wasn't standardized until 1998, 10 years later. The 90's were pretty much the heyday of C++.
 Do you think the fact that there was a free implementation 
 around that
 it supported virtually any existing platform didn't help? Do 
 you think
 the fact was it was (almost) compatible with C (which was born 
 freeish,
 since back then software was freely shared between 
 universities) didn't
 help?
ZTC++ was cheap as dirt, and at the time people didn't mind paying for compilers. Those days are over, though. People have different expectations today.
 No. A standard is something that was standardized by a standard
 committee which, ideally, have some credits to do so. C++ is
 standardized by ISO. I guess Walter and Andrei can give you 
 more
 details, since I think they both were involved in the 
 standardization of
 C++.
I've attended a few ISO C++ meetings, but I never became a voting member, and have had pretty much zero influence over the direction C++ took after the 1980's. The bottom line was the open source movement was not a very significant force in the 1980's when C++ gained traction. Open source really exploded around 2000, along with the internet. I wonder if open source perhaps needed the internet in order to be viable.
Wow. That's interesting reading. Thanks for the history lesson!
Jun 29 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2013 7:56 PM, CJS wrote:
 Wow. That's interesting reading. Thanks for the history lesson!
There are other versions of this history, none of which mention the role ZTC++ played in C++ attaining critical mass, so I like to repeat my version now and then :-)
Jun 29 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
I was wondering if Walter or Andrei would respond to this thread.

On Saturday, 29 June 2013 at 08:37:48 UTC, Walter Bright wrote:
 I agree with your post, I just want to make a couple of minor 
 corrections.
What exactly do you agree with Luca about, considering all your "minor corrections" basically demolish all his points? ;) Your C++ history was really interesting, as I first used it in '97, right when it was peaking.
 ZTC++ was cheap as dirt, and at the time people didn't mind 
 paying for compilers. Those days are over, though. People have 
 different expectations today.
There's no doubt that developers have been spoiled by all the free and shareware tools out there these days. What do you think of my idea of segmenting the market though? Keep providing a free-as-in-beer dmd, like you are now, for the people who want it, while Remedy and others who want performance pay for a dmd that puts out more performant code, with those improvements slowly merged back into the free dmd over time. If you are not interested in selling a paid compiler yourself, I've noted that there's nothing stopping someone else from doing this. They can take the dmd frontend under the Artistic license, compile it with the BSD-licensed llvm backend and boost-licensed druntime and phobos, and sell a paid compiler, without any permission from you or any other D contributors. You could not do anything legally to stop this, as the permissive OSS licenses allow it. However, as one of the main authors of this code, do you have any preference for or against someone taking your code to do this?
Jun 29 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2013 11:39 PM, Joakim wrote:
 What do you think of my idea of segmenting the market though? Keep providing a
 free-as-in-beer dmd, like you are now, for the people who want it, while Remedy
 and others who want performance pay for a dmd that puts out more performant
 code, with those improvements slowly merged back into the free dmd over time.
It won't work. Those days are gone.
 If you are not interested in selling a paid compiler yourself, I've noted that
 there's nothing stopping someone else from doing this.  They can take the dmd
 frontend under the Artistic license, compile it with the BSD-licensed llvm
 backend and boost-licensed druntime and phobos, and sell a paid compiler,
 without any permission from you or any other D contributors.

 You could not do anything legally to stop this, as the permissive OSS licenses
 allow it.  However, as one of the main authors of this code, do you have any
 preference for or against someone taking your code to do this?
Part of issuing it under a permissive license is I won't try to block someone from doing whatever they want to that is allowed by the license.
Jun 30 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Sunday, 30 June 2013 at 09:34:14 UTC, Walter Bright wrote:
 On 6/29/2013 11:39 PM, Joakim wrote:
 What do you think of my idea of segmenting the market though? 
 Keep providing a
 free-as-in-beer dmd, like you are now, for the people who want 
 it, while Remedy
 and others who want performance pay for a dmd that puts out 
 more performant
 code, with those improvements slowly merged back into the free 
 dmd over time.
It won't work. Those days are gone.
I disagree. We'll find out.
 If you are not interested in selling a paid compiler yourself, 
 I've noted that
 there's nothing stopping someone else from doing this.  They 
 can take the dmd
 frontend under the Artistic license, compile it with the 
 BSD-licensed llvm
 backend and boost-licensed druntime and phobos, and sell a 
 paid compiler,
 without any permission from you or any other D contributors.

 You could not do anything legally to stop this, as the 
 permissive OSS licenses
 allow it.  However, as one of the main authors of this code, 
 do you have any
 preference for or against someone taking your code to do this?
Part of issuing it under a permissive license is I won't try to block someone from doing whatever they want to that is allowed by the license.
I understand, but that wasn't exactly my question. I wondered if you have any opinion on such code reuse, if someone takes your code and closes it, even if you wouldn't try to block it because you have already released it under a permissive license. Some wouldn't try to close the source if you expressed a preference that it not be done- I have no such compunction, if the license allows closing source, but others might- just wondering if you have an opinion or preference on your source being closed up. Thanks for all the great work you have done on D and the dmd compiler. As much as I'd like to see a commercial implementation, it is amazing how much you have given away for free. :)
Jun 30 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2013 2:50 AM, Joakim wrote:
 I wondered if you have any opinion on such code reuse, if someone takes your
 code and closes it, even if you wouldn't try to block it because you have
 already released it under a permissive license.
No, I don't have an opinion on it, other than that I'd rather they didn't try to create an incompatible language and still call it "D".
Jun 30 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Sunday, 30 June 2013 at 19:24:54 UTC, Walter Bright wrote:
 On 6/30/2013 2:50 AM, Joakim wrote:
 I wondered if you have any opinion on such code reuse, if 
 someone takes your
 code and closes it, even if you wouldn't try to block it 
 because you have
 already released it under a permissive license.
No, I don't have an opinion on it, other than that I'd rather they didn't try to create an incompatible language and still call it "D".
OK, glad to hear that you wouldn't be against it. You'd be surprised how many who use permissive licenses still go nuts when you propose to do exactly what the license allows, ie close up parts of the source. Since you have been so gracious to use such permissive licenses for almost all of D, I'm sure someone will try the closed/paid experiment someday and see if which of us is right. :)
Jun 30 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 30 June 2013 at 19:45:06 UTC, Joakim wrote:
 OK, glad to hear that you wouldn't be against it.  You'd be 
 surprised how many who use permissive licenses still go nuts 
 when you propose to do exactly what the license allows, ie 
 close up parts of the source.
Because people don't just care about the strict legal constraints, but also about the social compact around software. Often people choose permissive licenses because they want to ensure other free software authors can use their software without encountering the licensing incompatibilities that can result from the various forms of copyleft. Closing up their software is rightly seen as an abuse of their goodwill. In other cases there may be a broad community consensus that builds up around a piece of software, that this work should be shared and contributed to as a common good (e.g. X.org). Attempts to close it up violate those social norms and are rightly seen as an attack on that community and the valuable commons they have cultivated. Community anger against legal but antisocial behaviour is hardly limited to software, and is a fairly important mechanism for ensuring that people behave well towards one another.
 Since you have been so gracious to use such permissive licenses 
 for almost all of D, I'm sure someone will try the closed/paid 
 experiment someday and see if which of us is right. :)
Good luck with that :-) By the way, you mentioned a project of your own where you employed the short-term open core model you describe. Want to tell us more about that? Regardless of differences of opinion, it's always good to hear about someone's particular experience with a project.
Jul 01 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Monday, 1 July 2013 at 10:15:34 UTC, Joseph Rushton Wakeling 
wrote:
 On Sunday, 30 June 2013 at 19:45:06 UTC, Joakim wrote:
 OK, glad to hear that you wouldn't be against it.  You'd be 
 surprised how many who use permissive licenses still go nuts 
 when you propose to do exactly what the license allows, ie 
 close up parts of the source.
Because people don't just care about the strict legal constraints, but also about the social compact around software. Often people choose permissive licenses because they want to ensure other free software authors can use their software without encountering the licensing incompatibilities that can result from the various forms of copyleft. Closing up their software is rightly seen as an abuse of their goodwill.
Then they should choose a mixed license like the Mozilla Public License or CDDL, which keeps OSS files open while allowing linking with closed source files within the same application. If they instead chose a license that allows closing all source, one can only assume they're okay with it. In any case, I could care less if they're okay with it or not, I was just surprised that they chose the BSD license and then were mad when someone was thinking about closing it up.
 In other cases there may be a broad community consensus that 
 builds up around a piece of software, that this work should be 
 shared and contributed to as a common good (e.g. X.org).  
 Attempts to close it up violate those social norms and are 
 rightly seen as an attack on that community and the valuable 
 commons they have cultivated.
There's no doubt that even if they chose a permissive license like the MIT or BSD license, these communities work primarily with OSS code and tend to prefer that code be open. I can understand if they then tend to rebuff attempts to keep source from them, purely as a social phenomenon, however irrational it may be. That's why I asked Walter if he had a similar opinion, but he didn't care. I still think it's ridiculous to put your code under an extremely permissive license and then get mad when people take you up on it, particularly since they never publicly broadcast that they want everything to be open. It is only after you talk to them that you realize that the BSD gang are often as much freetards as the GPL gang, just in their own special way. ;)
 Community anger against legal but antisocial behaviour is 
 hardly limited to software, and is a fairly important mechanism 
 for ensuring that people behave well towards one another.
I wouldn't call closing source that they legally allowed to be closed antisocial. I'd call their contradictory, angry response to what their license permits antisocial. :)
 Since you have been so gracious to use such permissive 
 licenses for almost all of D, I'm sure someone will try the 
 closed/paid experiment someday and see if which of us is 
 right. :)
Good luck with that :-) By the way, you mentioned a project of your own where you employed the short-term open core model you describe. Want to tell us more about that? Regardless of differences of opinion, it's always good to hear about someone's particular experience with a project.
I wrote up an article a couple years back talking about the new hybrid model I used, it's up on Phoronix and my project is mentioned there: http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing Note that this article was written when Android had less than 10% of the almost billion users it has today, by using a similar hybrid model, and I was thinking up these ideas years before, long before I'd heard of Android. My project was a small one, so it couldn't be a resounding proof of my time-limited version of the hybrid model, but it worked for its purpose and I'm fairly certain it will be the dominant model someday. :)
Jul 01 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/1/2013 10:45 AM, Joakim wrote:
 Then they should choose a mixed license like the Mozilla Public License or
CDDL,
 which keeps OSS files open while allowing linking with closed source files
 within the same application.  If they instead chose a license that allows
 closing all source, one can only assume they're okay with it.  In any case, I
 could care less if they're okay with it or not, I was just surprised that they
 chose the BSD license and then were mad when someone was thinking about closing
 it up.
I should point out that the Boost license was chosen for Phobos specifically because it allowed people to copy it and use it for whatever purpose, including making closed source versions, adapting them for use with Go :-), whatever. It would be pretty silly of us to complain about that after the fact. People who don't want closed source versions should use GPL licenses.
Jul 01 2013
parent reply Brad Roberts <braddr puremagic.com> writes:
On 7/1/13 11:42 AM, Walter Bright wrote:
 On 7/1/2013 10:45 AM, Joakim wrote:
 Then they should choose a mixed license like the Mozilla Public License or
CDDL,
 which keeps OSS files open while allowing linking with closed source files
 within the same application.  If they instead chose a license that allows
 closing all source, one can only assume they're okay with it.  In any case, I
 could care less if they're okay with it or not, I was just surprised that they
 chose the BSD license and then were mad when someone was thinking about closing
 it up.
I should point out that the Boost license was chosen for Phobos specifically because it allowed people to copy it and use it for whatever purpose, including making closed source versions, adapting them for use with Go :-), whatever.
Actually, Boost was specifically chosen because it didn't require attribution when redistributing. If BSD hadn't had that clause we probably would be using it instead.
Jul 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/1/2013 2:04 PM, Brad Roberts wrote:
 On 7/1/13 11:42 AM, Walter Bright wrote:
 On 7/1/2013 10:45 AM, Joakim wrote:
 Then they should choose a mixed license like the Mozilla Public License or
CDDL,
 which keeps OSS files open while allowing linking with closed source files
 within the same application.  If they instead chose a license that allows
 closing all source, one can only assume they're okay with it.  In any case, I
 could care less if they're okay with it or not, I was just surprised that they
 chose the BSD license and then were mad when someone was thinking about closing
 it up.
I should point out that the Boost license was chosen for Phobos specifically because it allowed people to copy it and use it for whatever purpose, including making closed source versions, adapting them for use with Go :-), whatever.
Actually, Boost was specifically chosen because it didn't require attribution when redistributing. If BSD hadn't had that clause we probably would be using it instead.
That was indeed another important reason for it. But we were well aware of and approved of the idea that people could take it and make closed source versions.
Jul 01 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Monday, 1 July 2013 at 21:20:39 UTC, Walter Bright wrote:
 On 7/1/2013 2:04 PM, Brad Roberts wrote:
 Actually, Boost was specifically chosen because it didn't 
 require attribution
 when redistributing. If BSD hadn't had that clause we probably 
 would be using it
 instead.
That was indeed another important reason for it. But we were well aware of and approved of the idea that people could take it and make closed source versions.
It was always clear (and logical) to me why the core libraries were permissively licensed, but the no-need-to-give-attribution-for-non-source-distribution feature was a subtlety I hadn't considered before.
Jul 02 2013
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 1 July 2013 at 17:45:59 UTC, Joakim wrote:
 I wouldn't call closing source that they legally allowed to be 
 closed antisocial.  I'd call their contradictory, angry 
 response to what their license permits antisocial. :)
Just because you're doing something legal doesn't mean you're not being antisocial. It's a pretty psychopathic attitude to conflate legality and morality, it's effectively saying "I have the moral right to do whatever I can get away with"
Jul 01 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/1/2013 2:29 PM, John Colvin wrote:
 On Monday, 1 July 2013 at 17:45:59 UTC, Joakim wrote:
 I wouldn't call closing source that they legally allowed to be closed
 antisocial.  I'd call their contradictory, angry response to what their
 license permits antisocial. :)
Just because you're doing something legal doesn't mean you're not being antisocial. It's a pretty psychopathic attitude to conflate legality and morality, it's effectively saying "I have the moral right to do whatever I can get away with"
(A nit: it is not illegal to break a contract's terms. You're quite right, though, that morality and legality are very different things, and are too often in contradiction.) Anyhow, the reason we have written contracts is because people often (and honestly) misremember or misinterpret verbally agreed upon terms. Having a written record is a lot better when the two parties find themselves in a dispute. There are many licenses to choose from, and we chose Boost knowing full well what was said (and not said) in it about closed source usage.
Jul 01 2013
prev sibling parent reply "Joakim" <joakim airpost.net> writes:
On Monday, 1 July 2013 at 21:29:21 UTC, John Colvin wrote:
 On Monday, 1 July 2013 at 17:45:59 UTC, Joakim wrote:
 I wouldn't call closing source that they legally allowed to be 
 closed antisocial.  I'd call their contradictory, angry 
 response to what their license permits antisocial. :)
Just because you're doing something legal doesn't mean you're not being antisocial.
Read my previous post. Of course it's possible for a license to technically allow something but for the authors to disapprove of it, not that its antisocial to simply do something they disapprove of. But, as I said earlier, the BSD crowd does not publicly broadcast that they disapprove of closing source. In fact, they will occasionally link to press releases about contributions back from corporations who closed the source. For people using the BSD license to then get mad when yet another person comes along to close source is the only "antisocial" behavior I'm seeing here. It'd be one thing if they publicly said that while the BSD license allows closing source, they're against it. Feel free to provide such a public statement, you won't find it. It's only after you talk to them privately about closing source that you realize how many of them are against it. As I've said repeatedly, I don't much care that their behavior is so "antisocial," :) as long as its legal to close source. But it is pretty funny to cast that tag on somebody else, who is simply doing what their license allows and what their press releases trumpet.
 It's a pretty psychopathic attitude to conflate legality and 
 morality, it's effectively saying "I have the moral right to do 
 whatever I can get away with"
On the contrary, it's a pretty psychopathic attitude to make such claims about morality when 1. nobody was talking about morality 2. the BSD crowd doesn't publicly talk about their problems with closing source either, whether they think it's immoral or antisocial or whatever.
Jul 01 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 2 July 2013 at 05:21:35 UTC, Joakim wrote:
 On Monday, 1 July 2013 at 21:29:21 UTC, John Colvin wrote:
 On Monday, 1 July 2013 at 17:45:59 UTC, Joakim wrote:
 I wouldn't call closing source that they legally allowed to 
 be closed antisocial.  I'd call their contradictory, angry 
 response to what their license permits antisocial. :)
Just because you're doing something legal doesn't mean you're not being antisocial.
Read my previous post. Of course it's possible for a license to technically allow something but for the authors to disapprove of it, not that its antisocial to simply do something they disapprove of. But, as I said earlier, the BSD crowd does not publicly broadcast that they disapprove of closing source. In fact, they will occasionally link to press releases about contributions back from corporations who closed the source. For people using the BSD license to then get mad when yet another person comes along to close source is the only "antisocial" behavior I'm seeing here. It'd be one thing if they publicly said that while the BSD license allows closing source, they're against it. Feel free to provide such a public statement, you won't find it. It's only after you talk to them privately about closing source that you realize how many of them are against it. As I've said repeatedly, I don't much care that their behavior is so "antisocial," :) as long as its legal to close source. But it is pretty funny to cast that tag on somebody else, who is simply doing what their license allows and what their press releases trumpet.
 It's a pretty psychopathic attitude to conflate legality and 
 morality, it's effectively saying "I have the moral right to 
 do whatever I can get away with"
On the contrary, it's a pretty psychopathic attitude to make such claims about morality when 1. nobody was talking about morality 2. the BSD crowd doesn't publicly talk about their problems with closing source either, whether they think it's immoral or antisocial or whatever.
This is all a bit moot as I was making a general point, not specifically related to BSD. However, in their case, I think it is perfectly fine that some don't like closed source personally, but as a group they decide to endorse it. A group where everyone is forced to agree on everything isn't an organisation, it's a cult. I think what I'm really trying to say is this: A license is a description of what you will *allow*, not what you *want*. I personally like to take in to account what people *want* me to do, not just what they will *allow* me to do.
Jul 02 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Tuesday, 2 July 2013 at 09:59:19 UTC, John Colvin wrote:
 This is all a bit moot as I was making a general point, not 
 specifically related to BSD. However, in their case, I think it 
 is perfectly fine that some don't like closed source 
 personally, but as a group they decide to endorse it. A group 
 where everyone is forced to agree on everything isn't an 
 organisation, it's a cult.
Of course there will be a wide variety of opinions within any community but the point is those who push such permissively-licensed software but privately dislike closing of source, then lash out at those who try to do it, are being silly.
 I think what I'm really trying to say is this:

 A license is a description of what you will *allow*, not what 
 you *want*.
 I personally like to take in to account what people *want* me 
 to do, not just what they will *allow* me to do.
You're really splitting hairs at this point. If you _allow_ almost anything, as most permissive licenses like the BSD or MIT license do, nobody is going to then ask permission of the community for every possible thing they might do, to see who "wants" it, particularly since the community hasn't stated anything publicly. Since the community likely has a variety of opinions, as you yourself just admitted, such a poll of "wants" would likely be meaningless anyway. Unless the particular community puts out a public statement of "wants" that most of them can get behind, which very few of them do, it is silly to talk about what they might "want" which isn't in the license. The license is essentially all that matters.
Jul 02 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 2 July 2013 at 14:40:42 UTC, Joakim wrote:
 You're really splitting hairs at this point.  If you _allow_ 
 almost anything, as most permissive licenses like the BSD or 
 MIT license do, nobody is going to then ask permission of the 
 community for every possible thing they might do, to see who 
 "wants" it, particularly since the community hasn't stated 
 anything publicly.  Since the community likely has a variety of 
 opinions, as you yourself just admitted, such a poll of "wants" 
 would likely be meaningless anyway.

 Unless the particular community puts out a public statement of 
 "wants" that most of them can get behind, which very few of 
 them do, it is silly to talk about what they might "want" which 
 isn't in the license.  The license is essentially all that 
 matters.
The difference between what people allow and what people want is much more significant than just "splitting hairs". However, I agree that there is often no coherent set of "wants" in a community, which makes it hard to consider them meaningfully. However, I do believe there's a level of common courtesy that should be honoured when using other people's work in a significant project, including at the very least making them aware that you will be doing so (anonymously, if secrecy is important). I know many people will just take whatever they can get and give as little as they can, but that doesn't make it right. I suspect we will never see eye to eye on this. You are convinced that the letter of the licence is all that matters, I am not.
Jul 02 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 1 July 2013 18:45, Joakim <joakim airpost.net> wrote:
 In other cases there may be a broad community consensus that builds up
 around a piece of software, that this work should be shared and contributed
 to as a common good (e.g. X.org).  Attempts to close it up violate those
 social norms and are rightly seen as an attack on that community and the
 valuable commons they have cultivated.
There's no doubt that even if they chose a permissive license like the MIT or BSD license, these communities work primarily with OSS code and tend to prefer that code be open. I can understand if they then tend to rebuff attempts to keep source from them, purely as a social phenomenon, however irrational it may be. That's why I asked Walter if he had a similar opinion, but he didn't care. I still think it's ridiculous to put your code under an extremely permissive license and then get mad when people take you up on it, particularly since they never publicly broadcast that they want everything to be open. It is only after you talk to them that you realize that the BSD gang are often as much freetards as the GPL gang, just in their own special way. ;)
To be 'retarded' is to be held back or hindered in the development or progress of an action or process. F/OSS comes with no such hindrance, unlike some other model that people falsely advertise as Everything Open and Free. All the Time!* -- Iain Buclaw *except whatever I am selling.
Jul 02 2013
prev sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Monday, 1 July 2013 at 17:45:59 UTC, Joakim wrote:
 Then they should choose a mixed license like the Mozilla Public 
 License or CDDL, which keeps OSS files open while allowing 
 linking with closed source files within the same application.  
 If they instead chose a license that allows closing all source, 
 one can only assume they're okay with it.  In any case, I could 
 care less if they're okay with it or not, I was just surprised 
 that they chose the BSD license and then were mad when someone 
 was thinking about closing it up.
The trouble is, even very weak copyleft licenses like MPL and CDDL can result in licensing incompatibilities. Only by granting very permissive licensing terms can you guarantee that your software will be usable by the full range of free software alternatives. For what it's worth, I have also made the argument on many occasions that projects shouldn't pick permissive licenses unless they're happy to see their work turned into proprietary products. But if a developer releases software under a liberal license, saying "I'm doing this so that everyone can use it but please keep it free," I think they have a right to be pissed off when someone ignores their moral request.
 There's no doubt that even if they chose a permissive license 
 like the MIT or BSD license, these communities work primarily 
 with OSS code and tend to prefer that code be open.  I can 
 understand if they then tend to rebuff attempts to keep source 
 from them, purely as a social phenomenon, however irrational it 
 may be.  That's why I asked Walter if he had a similar opinion, 
 but he didn't care.
Yes, the conscious choice of an extremely permissive license for druntime and Phobos is a different situation. It's completely right in this case to facilitate all forms of development and re-use, under all licensing scenarios.
 I still think it's ridiculous to put your code under an 
 extremely permissive license and then get mad when people take 
 you up on it, particularly since they never publicly broadcast 
 that they want everything to be open.  It is only after you 
 talk to them that you realize that the BSD gang are often as 
 much freetards as the GPL gang, just in their own special way. 
 ;)
It's a shame that you feel the need to resort to name-calling because someone has come to a considered moral or strategic position that's different from yours. It also doesn't really help your position -- you're better off just getting on with developing software using your strategy and showing how it serves free software in the long run.
 I wouldn't call closing source that they legally allowed to be 
 closed antisocial.  I'd call their contradictory, angry 
 response to what their license permits antisocial. :)
Personally speaking, I find there are a lot of things in life which I prefer to be legally permitted, but still nevertheless consider antisocial -- and I don't think there need be a contradiction there.
 http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing

 Note that this article was written when Android had less than 
 10% of the almost billion users it has today, by using a 
 similar hybrid model, and I was thinking up these ideas years 
 before, long before I'd heard of Android.

 My project was a small one, so it couldn't be a resounding 
 proof of my time-limited version of the hybrid model, but it 
 worked for its purpose and I'm fairly certain it will be the 
 dominant model someday. :)
Thanks for the interesting read. I think you have a point inasmuch as this is a model that clearly works very well from a business perspective where apps are concerned -- and if you're going to have open core, I'd rather it be one where the closed parts are guaranteed to eventually be opened up. Of course, this is not the same as moral approval :-) What I'd say, though, is that what works for apps isn't going to be what works for languages or their core development tools. Most apps seem to be single- or small-team developments, not community projects, they are targeting niche requirements, and ultimately they're being delivered to a target audience that's used to paying for software. On the other hand with a language your overwhelming goal is to grow the user community, and (unless you're Microsoft or Apple, who can dictate terms to software developers) the best way by far to do that is to secure the language quality while keeping the development tools available free of charge. You'll get more mileage out of monetising other things -- e.g. bug-fixing services, support, consultancy -- than you will out of restricting access to tools that enable people to use the language effectively. You also have to consider the user perspective. If I was offered a new language whose tools were delivered with open core terms, I would almost certainly refuse -- I'd feel unable to trust that I wouldn't at some point find all future releases locked up, leaving me with the Hobson's choice of either porting all my software to another language or coughing up the licensing fee.
Jul 02 2013
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Tuesday, 25 June 2013 at 21:38:01 UTC, Joakim wrote:
 I don't know the views of the key contributors, but I wonder if 
 they would have such a knee-jerk reaction against any 
 paid/closed work.  The current situation would seem much more 
 of a kick in the teeth to me: spending time trying to be 
 "professional," as Andrei asks, and producing a viable, stable 
 product used by a million developers, corporate users included, 
 but never receiving any compensation for this great tool you've 
 poured effort into, that your users are presumably often making 
 money with.
Obviously I can't speak for the core developers, or even for the community as a group. But I can make the following observations. D's success as a language is _entirely_ down to volunteer effort -- as Walter highlighted in his keynote. Volunteer effort is responsible for the development of the compiler frontend, the runtime, and the standard library. Volunteers have put in the hard work of porting these to other compiler backends. Volunteers have made and reviewed language improvement proposals, and have been vigilant in reporting and resolving bugs. Volunteers also contribute to vibrant discussions on these very forums, providing support and advice to those in need of help. And many of these volunteers have been doing so over the course of years. Now, in trying to drive more funding and professional effort towards D development, do you _really_ think that the right thing to do is to turn around to all those people and say: "Hey guys, after all the work you put in to make D so great, now we're going to build on that, but you'll have to wait 6 months for the extra goodies unless you pay"? How do you think that will affect the motivation of all those volunteers -- the code contributors, the bug reporters, the forum participants? What could you say to the maintainers of GDC or LDC, after all they've done to enable people to use the language, that could justify denying their compilers up-to-date access to the latest features? How would it affect the atmosphere of discussion about language development -- compared to the current friendly, collegial approach? ... and -- how do you think it would affect uptake, if it was announced that access to the best features would come at a price? There are orders of magnitude of difference between uptake of free and non-free services no matter what the domain, and software is one where free (as in freedom and beer) is much more strongly desired than in many other fields.
 I understand that such a shift from being mostly OSS to having 
 some closed components can be tricky, but that depends on the 
 particular community.  I don't think any OSS project has ever 
 become popular without having some sort of commercial model 
 attached to it.  C++ would be nowhere without commercial 
 compilers; linux would be unheard of without IBM and Red Hat 
 figuring out a consulting/support model around it; and Android 
 would not have put the linux kernel on hundreds of millions of 
 computing devices without the hybrid model that Google 
 employed, where they provide an open source core, paid for 
 through increased ad revenue from Android devices, and the 
 hardware vendors provide closed hardware drivers and UI skins 
 on top of the OSS core.
There's a big difference between introducing commercial models with a greater degree of paid professional work, and introducing closed components. Red Hat is a good example of that -- I can get, legally and for free, a fully functional copy of Red Hat Enterprise Linux without paying a penny. It's just missing the Red Hat name and logos and the support contract. In another email you mentioned Microsoft's revenues from Visual Studio but -- leaving aside for a moment all the moral and strategic concerns of closing things up -- Visual Studio enjoys that success because it's a virtually essential tool for professional development on Microsoft Windows, which still has an effective monopoly on modern desktop computing. Microsoft has the market presence to be able to dictate terms like that -- no one else does. Certainly no upcoming programming language could operate like that!
 This talk prominently mentioned scaling to a million users and 
 being professional: going commercial is the only way to get 
 there.
It's more likely that closing off parts of the offering would limit that uptake, for reasons already given. On the other hand, with more and more organizations coming to use and rely on D, there are plenty of other ways professional development could be brought in. Just to take one example: companies with a mission-critical interest in D have a corresponding interest in their developers giving time to the language itself. How many such companies do you think there need to be before D has a stable of skilled professional developers being paid explicitly to maintain and develop the language? Your citation of the Linux kernel is relevant here. Do you think that Linux would have had all that diverse success if parts of it had been closed up and sold at a premium? D's status as a purely community-run project is an asset compared to corporate-backed languages, not a liability.
Jun 26 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 26 June 2013 at 12:02:38 UTC, Joseph Rushton 
Wakeling wrote:
 Now, in trying to drive more funding and professional effort 
 towards D development, do you _really_ think that the right 
 thing to do is to turn around to all those people and say: "Hey 
 guys, after all the work you put in to make D so great, now 
 we're going to build on that, but you'll have to wait 6 months 
 for the extra goodies unless you pay"?
Yes, I think it is the right thing to do. I am only talking about closing off the optimization patches, all bugfixes and feature patches would likely be applied to both the free and paid compilers, certainly bugfixes. So not _all_ the "extra goodies" have to be paid for, and even the optimization patches are eventually open-sourced.
 How do you think that will affect the motivation of all those 
 volunteers -- the code contributors, the bug reporters, the 
 forum participants?  What could you say to the maintainers of 
 GDC or LDC, after all they've done to enable people to use the 
 language, that could justify denying their compilers up-to-date 
 access to the latest features?  How would it affect the 
 atmosphere of discussion about language development -- compared 
 to the current friendly, collegial approach?
I don't know how it will affect their motivation, as they probably differ in the reasons they contribute. If D becomes much more popular because the quality of implementation goes up and their D skills and contributions become much more prized, I suspect they will be very happy. :) If they are religious zealots about having only a single, completely open-source implementation- damn the superior results from hybrid models- perhaps they will be unhappy. I suspect the former far outnumber the latter, since D doesn't employ the purely-GPL approach the zealots usually insist on. We could poll them and find out. You keep talking about closed patches as though they can only piss off the volunteers. But if I'm right and a hybrid model would lead to a lot more funding and adoption of D, their volunteer work places them in an ideal position, where their D skills and contributions are much more valued and they can then probably do paid work in D. I suspect most will end up happier. I have not proposed denying GDC and LDC "access to the latest features," only optimization patches. LDC could do the same as dmd and provide a closed, paid version with the optimization patches, which it could license from dmd. GDC couldn't do this, of course, but that is the result of their purist GPL-only approach. Why do you think a hybrid model would materially "affect the atmosphere of discussion about language development?" Do you believe that the people who work on hybrid projects like Android, probably the most widely-used, majority-OSS project in the world, are not able to collaborate effectively?
 ... and -- how do you think it would affect uptake, if it was 
 announced that access to the best features would come at a 
 price?
Please stop distorting my argument. There are many different types of patches added to the dmd frontend every day: bugfixes, features, optimizations, etc. I have only proposed closing the optimization patches. However, I do think some features can also be closed this way. For example, Walter has added features like SIMD modifications only for Remedy. He could make this type of feature closed initially, available only in the paid compiler. As the feature matures and is paid for, it would eventually be merged into the free compiler. This is usually not a problem as those who want that kind of performance usually make a lot of money off of it and are happy to pay for that performance: that is all I'm proposing with my optimization patches idea also. As for how it would "affect uptake," I think most people know that free products are usually less capable than paid products. The people who don't need the capability use Visual Studio Express, those who need it pay for the full version of Visual Studio. There's no reason D couldn't employ a similar segmented model.
  There are orders of magnitude of difference between uptake of 
 free and non-free services no matter what the domain, and 
 software is one where free (as in freedom and beer) is much 
 more strongly desired than in many other fields.
Yes, you're right, non-free services have orders of magnitude more uptake. :p I think there are advantages to both closed and open source, which is why hybrid open/closed source models are currently very popular. Open source allows more collaboration from outside, while closed source allows for _much_ more funding from paying customers. I see no reason to dogmatically insist that these source models not be mixed.
 There's a big difference between introducing commercial models 
 with a greater degree of paid professional work, and 
 introducing closed components.  Red Hat is a good example of 
 that -- I can get, legally and for free, a fully functional 
 copy of Red Hat Enterprise Linux without paying a penny.  It's 
 just missing the Red Hat name and logos and the support 
 contract.
Yes, it's a consulting or support model. These don't scale as well as a product model with closed components. If all closed components are guaranteed to be open sourced after some time limit, as I've suggested above, I see no reason for OSS proponents to protest.
 In another email you mentioned Microsoft's revenues from Visual 
 Studio but -- leaving aside for a moment all the moral and 
 strategic concerns of closing things up -- Visual Studio enjoys 
 that success because it's a virtually essential tool for 
 professional development on Microsoft Windows, which still has 
 an effective monopoly on modern desktop computing.  Microsoft 
 has the market presence to be able to dictate terms like that 
 -- no one else does.  Certainly no upcoming programming 
 language could operate like that!
Yes, Microsoft has unusual leverage. But Visual Studio's compiler is not the only paid C++ compiler in the market, hell, Walter still sells C and C++ compilers. I'm not proposing D operate just like Microsoft. I'm suggesting a subtle compromise, a mix of that familiar closed model and the open source model you prefer, a hybrid model that you are no doubt familiar with, since you correctly pegged the licensing lingo earlier, when you mentioned "open core." These hybrid models are immensely popular these days: the two most popular software projects of the last decade, iOS and Android, are hybrid models. Of course, that is partly because mobile is such a hot field, but the explosion of mobile software didn't mean success for the closed models of RIM, Nokia, or Microsoft. Android's hybrid model is a big reason why it succeeded. I see no reason why another "upcoming" project like D couldn't do the same. :)
 It's more likely that closing off parts of the offering would 
 limit that uptake, for reasons already given.  On the other 
 hand, with more and more organizations coming to use and rely 
 on D, there are plenty of other ways professional development 
 could be brought in.  Just to take one example: companies with 
 a mission-critical interest in D have a corresponding interest 
 in their developers giving time to the language itself.  How 
 many such companies do you think there need to be before D has 
 a stable of skilled professional developers being paid 
 explicitly to maintain and develop the language?
I disagree that having a slightly-closed paid version would limit uptake, I think it would greatly increase it, for the same reasons that closed-source Windows is still on the vast majority of PCs and the hybrid model of Android led it to dominating on mobile devices. It is possible that your alternative of corporate backers providing paid development for D will materialize, even if solely for their own benefit, though it would benefit the wider community also. I'm suggesting that the hybrid model I'm proposing will provide such funding much faster and better, for the reasons given.
 Your citation of the Linux kernel is relevant here.  Do you 
 think that Linux would have had all that diverse success if 
 parts of it had been closed up and sold at a premium?  D's 
 status as a purely community-run project is an asset compared 
 to corporate-backed languages, not a liability.
As I noted in my response to Luca, linux has always had binary blobs. Do I think it would have been as successful if more parts of it had been closed up? Well, much of it cannot be closed because of the GPL, so it is just not possible in many respects. But to take a recent example where it is possible, a recent rumor is that Sony is using FreeBSD for the Playstation 4: http://www.vgleaks.com/some-details-about-playstation-4-os-development/ Even if it isn't used on the final PS4, FreeBSD is known to be used in commercial, closed products like Juniper routers or NetApp file servers. I don't think this has limited its uptake, if anything, it has helped as they have eventually contributed back towards the project. I don't think a "purely community-run project" is a worthwhile goal, particularly if you are aiming for a million users and professionalism. I think there is always opportunity for mixing of commercial implementations and community involvement, as very successful hybrid projects like Android or Chrome have shown.
Jun 26 2013
parent reply "Iain Buclaw" <ibuclaw gdcproject.org> writes:
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. ;)



On Wednesday, 26 June 2013 at 17:42:23 UTC, Joakim wrote:
 On Wednesday, 26 June 2013 at 12:02:38 UTC, Joseph Rushton 
 Wakeling wrote:
 Now, in trying to drive more funding and professional effort 
 towards D development, do you _really_ think that the right 
 thing to do is to turn around to all those people and say: 
 "Hey guys, after all the work you put in to make D so great, 
 now we're going to build on that, but you'll have to wait 6 
 months for the extra goodies unless you pay"?
Yes, I think it is the right thing to do. I am only talking about closing off the optimization patches, all bugfixes and feature patches would likely be applied to both the free and paid compilers, certainly bugfixes. So not _all_ the "extra goodies" have to be paid for, and even the optimization patches are eventually open-sourced.
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.
 How do you think that will affect the motivation of all those 
 volunteers -- the code contributors, the bug reporters, the 
 forum participants?  What could you say to the maintainers of 
 GDC or LDC, after all they've done to enable people to use the 
 language, that could justify denying their compilers 
 up-to-date access to the latest features?  How would it affect 
 the atmosphere of discussion about language development -- 
 compared to the current friendly, collegial approach?
I don't know how it will affect their motivation, as they probably differ in the reasons they contribute. If D becomes much more popular because the quality of implementation goes up and their D skills and contributions become much more prized, I suspect they will be very happy. :) If they are religious zealots about having only a single, completely open-source implementation- damn the superior results from hybrid models- perhaps they will be unhappy. I suspect the former far outnumber the latter, since D doesn't employ the purely-GPL approach the zealots usually insist on.
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.
 ... and -- how do you think it would affect uptake, if it was 
 announced that access to the best features would come at a 
 price?
Please stop distorting my argument. There are many different types of patches added to the dmd frontend every day: bugfixes, features, optimizations, etc. I have only proposed closing the optimization patches. However, I do think some features can also be closed this way. For example, Walter has added features like SIMD modifications only for Remedy. He could make this type of feature closed initially, available only in the paid compiler. As the feature matures and is paid for, it would eventually be merged into the free compiler. This is usually not a problem as those who want that kind of performance usually make a lot of money off of it and are happy to pay for that performance: that is all I'm proposing with my optimization patches idea also.
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.
 In another email you mentioned Microsoft's revenues from 
 Visual Studio but -- leaving aside for a moment all the moral 
 and strategic concerns of closing things up -- Visual Studio 
 enjoys that success because it's a virtually essential tool 
 for professional development on Microsoft Windows, which still 
 has an effective monopoly on modern desktop computing.  
 Microsoft has the market presence to be able to dictate terms 
 like that -- no one else does.  Certainly no upcoming 
 programming language could operate like that!
Yes, Microsoft has unusual leverage. But Visual Studio's compiler is not the only paid C++ compiler in the market, hell, Walter still sells C and C++ compilers. I'm not proposing D operate just like Microsoft. I'm suggesting a subtle compromise, a mix of that familiar closed model and the open source model you prefer, a hybrid model that you are no doubt familiar with, since you correctly pegged the licensing lingo earlier, when you mentioned "open core." These hybrid models are immensely popular these days: the two most popular software projects of the last decade, iOS and Android, are hybrid models. Of course, that is partly because mobile is such a hot field, but the explosion of mobile software didn't mean success for the closed models of RIM, Nokia, or Microsoft. Android's hybrid model is a big reason why it succeeded. 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. 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.
 I don't think a "purely community-run project" is a worthwhile 
 goal, particularly if you are aiming for a million users and 
 professionalism.  I think there is always opportunity for 
 mixing of commercial implementations and community involvement, 
 as very successful hybrid projects like Android or Chrome have 
 shown.
Your argument seems lost on me as you seem to be taking a very strange angle of association with the D language and/or compiler, and you don't seem to understand how the development process of D works either. My thoughts in summary: - 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. - 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. - Likewise, because of licensing and copyright assignments in place on the D front-end implementation. Any closed D compiler using it would have to make its sources of the front-end, with local modifications, available upon request. So it makes no sense whatsoever to make language features - such as SIMD - closed off. tl/dr; 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. 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. </ End argument on feasibility of a hybrid development model > Regards Iain "That GDC Developer" Bucław
Jun 26 2013
next sibling parent reply "Joakim" <joakim airpost.net> writes:
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.
 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.
 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.
 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.
 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.
Perhaps there is some truth to that. But nobody is suggesting a purely closed-source language either.
 I don't think a "purely community-run project" is a worthwhile 
 goal, particularly if you are aiming for a million users and 
 professionalism.  I think there is always opportunity for 
 mixing of commercial implementations and community 
 involvement, as very successful hybrid projects like Android 
 or Chrome have shown.
Your argument seems lost on me as you seem to be taking a very strange angle of association with the D language and/or compiler, and you don't seem to understand how the development process of D works either.
I am associating D, an open source project, with Android and Chrome, two of the most successful open source projects at the moment, which both benefit from hybrid models. I find it strange that you cannot follow. If I don't understand how the development process of D works, you could point out an example, instead of making basic mistakes in not knowing what licenses it uses and what they allow. :)
 - 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 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.
 - Likewise, because of licensing and copyright assignments in 
 place on the D front-end implementation.  Any closed D compiler 
 using it would have to make its sources of the front-end, with 
 local modifications, available upon request.  So it makes no 
 sense whatsoever to make language features - such as SIMD - 
 closed off.
I suggest you read the Artistic license. You have no idea what you are talking about.
 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.
 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. :)
 </ End argument on feasibility of a hybrid development model >
</ End my demolition of your ignorant arguments >
Jun 26 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Jun 26, 2013 9:00 PM, "Joakim" <joakim 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.
Jun 26 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Wednesday, 26 June 2013 at 21:15:34 UTC, Iain Buclaw wrote:
 On Jun 26, 2013 9:00 PM, "Joakim" <joakim 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.
Jun 27 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 27 June 2013 09:21, Joakim <joakim airpost.net> wrote:
 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. :)
Now you are just re-hashing what my initial thoughts were... ;)
 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.
But it's not blending the benefits at all. Open-core, however you try to sway or pitch it, does not qualify as open source. It is closed source. It is the opposite of open source. Personally, it is not acceptable that you market yourself as an open source product when in fact your business model is to sell closed source. This is confusing, I'd say it is border line lying. Well, marketing often is lying, but in the open source community we call out such lies, however subtle. Most open core vendors still market themselves as open source leaders, then come to you to sell closed source software. (They deserve to be critizised if you ask me).
 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.
This is were C/C++ went horribly wrong. Different compilers having a vagary of macros to identify the same platform or architecture, the question of what is valid syntax being different between compilers, code written in a certain way working in one compiler but throws an error with another... We are striving to be better than that from the start.
 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.
Binary blobs are the exception rather than the rule in Linux, and many hardware vendors would flat out say 'no' to doing any support on them. Moreover, the position of the Linux Foundation is that any closed-source kernel module is harmful and undesirable, and they are always urging for vendors to adopt a policy of supporting their customers on Linux with open-source kernel code. Which goes to show how useful a hybrid model has been for them...
 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).
MySQL iirc was the first to practice this model. But they were initially open source from the start, and made their business through a support model. When they switched, their business model turned to selling closed source software, and so their incentives moved away from being able to produce open source software, and to instead produce as much closed source software as they could get away with. In MySQL's case they eventually had to backtrack on the plans of closed source backup, because they didn't get away with it. The public pressure became a burden for Sun and MySQL management had to give up those plans. Though now this is in the hands of Oracle, they have now revitalized the plans for closed source backup tools - so now we are seeing products that evolved from the same codebase, but are now considered two separate products (LibreOffice, OpenIndiana...) The most successful open source projects, like Linux and Apache, are not Capital backed businesses to begin with, and even among companies, the most successful ones, such as Red Hat, Canonical, are not "open core" companies but so called "pure play" open source companies that have committed themselves to stay open source. But in the end... De Gustibus Non Est Disputandum. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 27 2013
prev sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 27 June 2013 at 08:21:12 UTC, Joakim wrote:
 I'm familiar with its arguments from a summary, not 
 particularly interested in reading the whole thing.
You know, I think I see what your problem is ... :-)
Jun 27 2013
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
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?
Jun 26 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Jun 26, 2013 9:50 PM, "Joseph Rushton Wakeling" <
joseph.wakeling webdrake.net> wrote:
 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
Don't call be Shirley...
 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.

Sometimes it feels like achieving this is as trying to break down a brick
barrier with a shoelace.

 By the way, I hope you didn't feel I was trying to speak on behalf of GDC
-- wasn't my intention. :-)

I did, and it hurt.  :o)

 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.

Yes, it's like trying to learn D, but the only reference you have of the
language is the grammar page, and an IDE which offers thousands of
auto-complete options for things that *sound* like what you want, but don't
compile when it comes to testing.  :o)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 26 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 26 June 2013 at 21:29:12 UTC, Iain Buclaw wrote:
 Don't call be Shirley...
Serious? :-)
 By the way, I hope you didn't feel I was trying to speak on 
 behalf of GDC -- wasn't my intention. :-)
I did, and it hurt. :o)
Oh no. 50 shades of #DDDDDD ? :-)
Jun 26 2013
parent reply Mathias Lang <pro.mathias.lang gmail.com> writes:
I've read (almost), everything, so I hope I won't miss a point here:
a) I've heard about MSVC, Red Hat, Qt, Linux and so on. From my
understanding, none of the projects mentionned have gone from free (as in
free beer) to hybrid/closed. And I'm not currently able to think of one
successful, widespread project that did.
b) Thinking that being free (as a beer and/or as freedom), hybrid, closed
source of whatever is a single critera of success seems foolish. I'm not
asking for a complete comparison (I think my mailbox won't stand it ;-) ),
but please stop comparing a free operating software with a paid compiler,
and assume the former have more users than the later because it's free (and
vice-versa). In addition, I don't see the logic behind comparing something
born in the 90s with something from the 2000s. Remember the Dot-com bubble ?
c) There are other way to get more people involved, for exemple if
dlang.orgbecomes a foundation (see related thread), we would be able
to apply for
GSoC.
d) People pay for something they need. They don't adopt something because
they can pay for it. That's why paid compiler must follow language
promotion, not the other way around.


2013/6/27 Joseph Rushton Wakeling <joseph.wakeling webdrake.net>

 On Wednesday, 26 June 2013 at 21:29:12 UTC, Iain Buclaw wrote:

 Don't call be Shirley...
Serious? :-) By the way, I hope you didn't feel I was trying to speak on behalf of GDC
 -- wasn't my intention. :-)
I did, and it hurt. :o)
Oh no. 50 shades of #DDDDDD ? :-)
Jun 26 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Thursday, 27 June 2013 at 03:20:37 UTC, Mathias Lang wrote:
 I've read (almost), everything, so I hope I won't miss a point 
 here:
 a) I've heard about MSVC, Red Hat, Qt, Linux and so on. From my
 understanding, none of the projects mentionned have gone from 
 free (as in
 free beer) to hybrid/closed. And I'm not currently able to 
 think of one
 successful, widespread project that did.
Then you are not paying attention. As I've already noted several times, Visual Studio, which is the way most use MSVC, has both paid and free versions. Red Hat contains binary blobs and possibly other non-OSS software and charges companies for consulting and support. Qt is an "open core" project that is dual-licensed under both OSS and commercial licenses, the latter of which you pay for. Linux contains binary blobs in the vast majority of installs and most people running it paid for it. If your implied point is that the original authors aren't the ones taking the project hybrid or paid, it depends on the license. Sometimes it is those owning the original copyright, as it had to be in the Qt, MySQL, and other dual-licensing cases, other times it isn't.
 b) Thinking that being free (as a beer and/or as freedom), 
 hybrid, closed
 source of whatever is a single critera of success seems 
 foolish. I'm not
 asking for a complete comparison (I think my mailbox won't 
 stand it ;-) ),
 but please stop comparing a free operating software with a paid 
 compiler,
 and assume the former have more users than the later because 
 it's free (and
 vice-versa). In addition, I don't see the logic behind 
 comparing something
 born in the 90s with something from the 2000s. Remember the 
 Dot-com bubble ?
Obviously nothing is a "single criteria of success," as has been stated already. In complex social fields like business or technology ventures, where there are many confounding factors, judgement and interpretation are everything. By your rationale, we might as well do _anything_ because how could we possibly know that C++ wasn't immensely successful only because Bjarne Stroustrup is a Dane? Obviously none of this discussion matters, as D has very little Danish involvement and therefore can never be as popular. ;) You have to have the insight to be able to weigh all these competing factors and while I agree that most cannot, those who are successful do.
 d) People pay for something they need. They don't adopt 
 something because
 they can pay for it. That's why paid compiler must follow 
 language
 promotion, not the other way around.
These assertions are somewhat meaningless. Those who value performance will pay for the optimized version of the dmd compiler that I've proposed. Those who don't will use the slower, pure-OSS version. There is no reason for a paid compiler to only follow promotion, both must be done at the same time. In any case, I've lost interest in this debate. I've made my case, those involved with the D compiler can decide if this would be a worthwhile direction. From their silence so far, I can only assume that they are not interested in rousing the ire of the freetards and will simply maintain the status quo of keeping all source public. This will lead to D's growth being slowed, compared to the alternative of providing a paid compiler also. That's their choice to make. If somebody stumbles across this thread later, perhaps they will close up optimization patches to ldc and sell a paid version. Given that those behind dmd have not expressed any interest in a paid version, maybe these ldc vendors will not involve them with the money or feature decisions of their paid ldc. It would be likely that this paid compiler becomes the dominant one and the original dmd project is forgotten. If you don't choose the best approach, a hybrid model, you leave it open for somebody else to do it and take the project in a different direction.
Jun 27 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 27 June 2013 09:53, Joakim <joakim airpost.net> wrote:
 those involved with the D compiler can decide if this would be a worthwhile
 direction.  From their silence so far, I can only assume that they are not
 interested in rousing the ire of the freetards and will simply maintain the
 status quo of keeping all source public.
True, I tend to just ignore comments from opportunists who jump in and shout "Hey guys! I'm new around here, have you guys tried to do something completely radical on the off chance that it will work? I have a good feeling about this..!!" But as it stands, I'm taking a quick break from my usual GDC work before I reach stage 12 of burnout. ;)
 This will lead to D's growth being slowed, compared to the alternative of
 providing a paid compiler also.  That's their choice to make.
In your opinion.
 If somebody stumbles across this thread later, perhaps they will close up
 optimization patches to ldc and sell a paid version.  Given that those
 behind dmd have not expressed any interest in a paid version, maybe these
 ldc vendors will not involve them with the money or feature decisions of
 their paid ldc.  It would be likely that this paid compiler becomes the
 dominant one and the original dmd project is forgotten.
This was said when GDC got the D2 language stable. The reality? I wouldn't hold my breath... I'm still a one-man team, and there is no contingency in place should something happen to me. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 27 2013
parent reply "Joakim" <joakim airpost.net> writes:
As I said earlier, I'm done with this debate.

There is no point talking to people who make blatantly ignorant 
statements like, "Binary blobs are the exception rather than the 
rule in Linux, and many hardware vendors would flat out say 'no' 
to doing any support on them."  This assertion is so ignorant of 
the facts, it's laughable. :) I have no idea what to make of 
Iain's talking about gdc or that it is a "one-man team" in 
response to my prediction that ldc could go closed/paid and 
obsolete dmd: there is absolutely no connection between the 
topics.

As for Luca's long response, it is filled with basic mistakes, 
silly and incorrect rehashes of material already covered, or 
trivial twits, like the fact that D has a spec but isn't 
standardized by any international body.  For example, I 
originally pointed out several examples of other projects with 
existing commercial models and I was told that they're not 
"closed."  I responded that I never said that they were all 
closed, only commercial, and I'm now told that since my proposed 
model for D is closed, I'm "misstating" myself. (Slaps head)

These responses seem written by people who have a very tenuous 
grasp on the text I wrote.

Look, I get it, you guys are religious zealots- you tip your hand 
when you allude to ethical or moral reasons for using open 
source, a crazy idea if there ever was one- and you will come up 
with all kinds of silly arguments in the face of overwhelming 
evidence that _pure_ open source has failed.  Instead, you claim 
success when hybrid models bring more open source into the world, 
then nonsensically reverse course and claim that either they 
aren't actually hybrid or that such hybrid models are not really 
"open source," that it's a lie to call it that. (Slaps head again)

I'm not trying to convince you zealots.  You want to keep banging 
your heads against the wall for the greater glory of your 
religion, have fun with that.

I'm simply putting forward a case for D going the route of the 
most successful projects these days, by using a hybrid model, 
with a unique variation that I came up with :) and have 
successfully used for a project of my own.

Those who aren't religious about _pure_ open source can consider 
what I've proposed and my evidence and see if it makes sense to 
them.
Jun 27 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 27 June 2013 at 13:18:01 UTC, Joakim wrote:
 As I said earlier, I'm done with this debate.

 There is no point talking to people who make blatantly ignorant 
 statements like, "Binary blobs are the exception rather than 
 the rule in Linux, and many hardware vendors would flat out say 
 'no' to doing any support on them."  This assertion is so 
 ignorant of the facts, it's laughable. :) I have no idea what 
 to make of Iain's talking about gdc or that it is a "one-man 
 team" in response to my prediction that ldc could go 
 closed/paid and obsolete dmd: there is absolutely no connection 
 between the topics.

 As for Luca's long response, it is filled with basic mistakes, 
 silly and incorrect rehashes of material already covered, or 
 trivial twits, like the fact that D has a spec but isn't 
 standardized by any international body.  For example, I 
 originally pointed out several examples of other projects with 
 existing commercial models and I was told that they're not 
 "closed."  I responded that I never said that they were all 
 closed, only commercial, and I'm now told that since my 
 proposed model for D is closed, I'm "misstating" myself. (Slaps 
 head)

 These responses seem written by people who have a very tenuous 
 grasp on the text I wrote.

 Look, I get it, you guys are religious zealots- you tip your 
 hand when you allude to ethical or moral reasons for using open 
 source, a crazy idea if there ever was one- and you will come 
 up with all kinds of silly arguments in the face of 
 overwhelming evidence that _pure_ open source has failed.  
 Instead, you claim success when hybrid models bring more open 
 source into the world, then nonsensically reverse course and 
 claim that either they aren't actually hybrid or that such 
 hybrid models are not really "open source," that it's a lie to 
 call it that. (Slaps head again)

 I'm not trying to convince you zealots.  You want to keep 
 banging your heads against the wall for the greater glory of 
 your religion, have fun with that.

 I'm simply putting forward a case for D going the route of the 
 most successful projects these days, by using a hybrid model, 
 with a unique variation that I came up with :) and have 
 successfully used for a project of my own.

 Those who aren't religious about _pure_ open source can 
 consider what I've proposed and my evidence and see if it makes 
 sense to them.
Most replies to you have been quite measured and reasonable. I'm not sure what justifies you calling people zealots.
Jun 27 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Thursday, 27 June 2013 at 13:25:06 UTC, John Colvin wrote:
 On Thursday, 27 June 2013 at 13:18:01 UTC, Joakim wrote:
 Look, I get it, you guys are religious zealots- you tip your 
 hand when you allude to ethical or moral reasons for using 
 open source, a crazy idea if there ever was one- and you will 
 come up with all kinds of silly arguments in the face of 
 overwhelming evidence that _pure_ open source has failed.
Most replies to you have been quite measured and reasonable. I'm not sure what justifies you calling people zealots.
Read the rest of the sentence which you quoted, my reasons are stated. When I come across so many arguments that are _factually_ wrong- "the Artistic license doesn't allow closing source," "most linux installs don't use binary blobs"- I know I'm dealing with religious zealots.
Jun 27 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 27 June 2013 14:40, Joakim <joakim airpost.net> wrote:
 On Thursday, 27 June 2013 at 13:25:06 UTC, John Colvin wrote:
 On Thursday, 27 June 2013 at 13:18:01 UTC, Joakim wrote:
 Look, I get it, you guys are religious zealots- you tip your hand when
 you allude to ethical or moral reasons for using open source, a crazy idea
 if there ever was one- and you will come up with all kinds of silly
 arguments in the face of overwhelming evidence that _pure_ open source has
 failed.
Most replies to you have been quite measured and reasonable. I'm not sure what justifies you calling people zealots.
Read the rest of the sentence which you quoted, my reasons are stated. When I come across so many arguments that are _factually_ wrong- "the Artistic license doesn't allow closing source," "most linux installs don't use binary blobs"- I know I'm dealing with religious zealots.
Which is quite amusing, as those quotes aren't found anywhere in this thread. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 27 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 27 June 2013 at 13:18:01 UTC, Joakim wrote:
 There is no point talking to people who make blatantly ignorant 
 statements
Yeah, I keep wondering why someone even bothered to waste time explaining all this to someone who is incapable of both providing own reasoning and studying opponent one. I hope that anyone that has followed D history is perfectly aware of numbers that prove how beneficial transition to a community-based open development was.
Jun 27 2013
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Joakim, el 27 de June a las 15:17 me escribiste:
 As I said earlier, I'm done with this debate.
 
 There is no point talking to people who make blatantly ignorant
 statements like, "Binary blobs are the exception rather than the
 rule in Linux, and many hardware vendors would flat out say 'no' to
 doing any support on them."  This assertion is so ignorant of the
 facts, it's laughable. :) I have no idea what to make of Iain's
 talking about gdc or that it is a "one-man team" in response to my
 prediction that ldc could go closed/paid and obsolete dmd: there is
 absolutely no connection between the topics.
 
 As for Luca's long response, it is filled with basic mistakes, silly
 and incorrect rehashes of material already covered, or trivial
How convenient is to put a lot of adjectives together and not a single fact to say someone is wrong. Almost as convenient as calling people religious zaelots when you run out of arguments. :) And is so funny that you keep talking about the D contributors not participating in the thread when evidently you don't know who the contributors are. I'm just so glad that you are done with this debate... My eyes were hurting from reading so much crap. Bye, bye! Have fun with Visual C++! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Did you know the originally a Danish guy invented the burglar-alarm unfortunately, it got stolen
Jun 27 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 27 June 2013 14:17, Joakim <joakim airpost.net> wrote:
 As I said earlier, I'm done with this debate.

 There is no point talking to people who make blatantly ignorant statements
 like, "Binary blobs are the exception rather than the rule in Linux, and
 many hardware vendors would flat out say 'no' to doing any support on them."
 This assertion is so ignorant of the facts, it's laughable. :)
Fact: That quote you find laughable isn't my opinion. It was what Linus said during a Q&A after one of his talks (at least, if I remember it correctly ;).
 I have no idea what to make of Iain's talking about gdc or that it is a
"one-man team"
 in response to my prediction that ldc could go closed/paid and obsolete dmd:
 there is absolutely no connection between the topics.
I suppose that was my ignorance there, I assumed that you at least *knew* a little bit of history behind the development of D1/D2. I'm sure people would raise their eyebrows and sigh to have the age old question "why don't we just drop development of DMD and move it to X?" asked again. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 27 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/24/13 9:13 AM, Andrei Alexandrescu wrote:
 reddit:
 http://www.reddit.com/r/programming/comments/1gz40q/dconf_2013_closing_keynote_quo_vadis_by_andrei/


 facebook: https://www.facebook.com/dlang.org/posts/662488747098143

 twitter: https://twitter.com/D_Programming/status/349197737805373441

 hackernews: https://news.ycombinator.com/item?id=5933818

 youtube: http://youtube.com/watch?v=4M-0LFBP9AU


 Andrei
HD version available: http://archive.org/details/dconf2013-day03-talk06 Andrei
Jun 25 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 24 Jun 2013 09:13:48 -0700
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 reddit: 
 http://www.reddit.com/r/programming/comments/1gz40q/dconf_2013_closing_keynote_quo_vadis_by_andrei/
 
Torrents and links up, plus a torrent now for the original MP4 of the previous talk: http://semitwist.com/download/misc/dconf2013/
Jun 25 2013
prev sibling parent reply "CJS" <Prometheus85 hotmail.com> writes:
In the talk Andrei seems to mentions that D's associative arrays 
are lacking in performance somehow. I'm very new to D, but it's 
not obvious to me what the shortcoming is. I assume it's that for 
some reason it's hard to specialize associative arrays to specfic 
types to give increased performance in specfic cases, but I'm 
unclear why that would be difficult. Could someone please 
elaborate?
Jun 30 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 30, 2013 21:05:41 CJS wrote:
 In the talk Andrei seems to mentions that D's associative arrays
 are lacking in performance somehow. I'm very new to D, but it's
 not obvious to me what the shortcoming is. I assume it's that for
 some reason it's hard to specialize associative arrays to specfic
 types to give increased performance in specfic cases, but I'm
 unclear why that would be difficult. Could someone please
 elaborate?
There's one implementation, and you can't swap it out, whereas different use cases may perform better with different implementations. On top of that, the current implementation is rather buggy and fragile, but that's an implementation issue rather than an inherent one. - Jonathan M Davis
Jun 30 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jun 2013 15:51:32 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Sunday, June 30, 2013 21:05:41 CJS wrote:
 In the talk Andrei seems to mentions that D's associative arrays
 are lacking in performance somehow. I'm very new to D, but it's
 not obvious to me what the shortcoming is. I assume it's that for
 some reason it's hard to specialize associative arrays to specfic
 types to give increased performance in specfic cases, but I'm
 unclear why that would be difficult. Could someone please
 elaborate?
There's one implementation, and you can't swap it out, whereas different use cases may perform better with different implementations. On top of that, the current implementation is rather buggy and fragile, but that's an implementation issue rather than an inherent one.
No, the main issue is the current one is runtime-only, and so simple function calls such as toHash and opCmp cannot be inlined. You absolutely can change implementations (Walter did a few years ago from tree-based collision resolution to linked-list based). What you can't do is switch to a fully generated AA, or change the compiler-expected API. -Steve
Jun 30 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 30, 2013 19:20:47 Steven Schveighoffer wrote:
 On Sun, 30 Jun 2013 15:51:32 -0400, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 On Sunday, June 30, 2013 21:05:41 CJS wrote:
 In the talk Andrei seems to mentions that D's associative arrays
 are lacking in performance somehow. I'm very new to D, but it's
 not obvious to me what the shortcoming is. I assume it's that for
 some reason it's hard to specialize associative arrays to specfic
 types to give increased performance in specfic cases, but I'm
 unclear why that would be difficult. Could someone please
 elaborate?
There's one implementation, and you can't swap it out, whereas different use cases may perform better with different implementations. On top of that, the current implementation is rather buggy and fragile, but that's an implementation issue rather than an inherent one.
No, the main issue is the current one is runtime-only, and so simple function calls such as toHash and opCmp cannot be inlined.
Yeah. That's a big problem. We really need to templatize all that - though the current implementation is enough of a mess to make that difficult.
 You absolutely can change implementations (Walter did a few years ago from
 tree-based collision resolution to linked-list based).  What you can't do
 is switch to a fully generated AA, or change the compiler-expected API.
Okay. I didn't know that. But I think that they key issue with swapping out the implementation is not whether you can swap out the implementation for your whole program but rather being able to choose different implementations for different parts of your program. If you really care about your containers enough to worry about optimizing them for your particular use cases, then unless you only have one use case within your program, there's a good chance that you're going to want different implementations for different parts of your program. With library containers, that's as simple as swapping which one you use. With the bulit-in stuff like AAs, you can't do that. You only get one (even if you can make it different across programs). Now, if you just use library types, you don't have that problem, so in the long run, folks who really want to optimize their containers will probably do that. And if they _really_ want to optimize their containers, they're probably writing them themselves anyway. Regardless, while having a built-in AA simplifies the common case, it _is_ more limiting, and if you really care about how your AAs function, you're going to have to use a library solution (even if the bult-in AAs have a solid implementation). - Jonathan M Davis
Jun 30 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jun 2013 21:43:53 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 But I think that they key issue with swapping out
 the implementation is not whether you can swap out the implementation  
 for your
 whole program but rather being able to choose different implementations  
 for
 different parts of your program.
This would never happen. AAs are only ever going to be one implementation. If you want to use another map type, you will have to use a struct/class. I suppose AA's could simply be polymorphic, but I don't see the benefit. -Steve
Jun 30 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 30, 2013 21:54:08 Steven Schveighoffer wrote:
 On Sun, 30 Jun 2013 21:43:53 -0400, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 But I think that they key issue with swapping out
 the implementation is not whether you can swap out the implementation
 for your
 whole program but rather being able to choose different implementations
 for
 different parts of your program.
This would never happen. AAs are only ever going to be one implementation. If you want to use another map type, you will have to use a struct/class. I suppose AA's could simply be polymorphic, but I don't see the benefit.
I know. My point was that that's an inherent problem with built-in AAs that can't be overcome (regardless of how well they're implemented). If you want that level of control, you _have_ to use a library solution. - Jonathan M Davis
Jun 30 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jun 2013 22:02:11 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Sunday, June 30, 2013 21:54:08 Steven Schveighoffer wrote:
 On Sun, 30 Jun 2013 21:43:53 -0400, Jonathan M Davis  
 <jmdavisProg gmx.com>

 wrote:
 But I think that they key issue with swapping out
 the implementation is not whether you can swap out the implementation
 for your
 whole program but rather being able to choose different  
implementations
 for
 different parts of your program.
This would never happen. AAs are only ever going to be one implementation. If you want to use another map type, you will have to use a struct/class. I suppose AA's could simply be polymorphic, but I don't see the benefit.
I know. My point was that that's an inherent problem with built-in AAs that can't be overcome (regardless of how well they're implemented). If you want that level of control, you _have_ to use a library solution.
OK. I guess I was just reading your statement like it was a "problem" :) -Steve
Jun 30 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 30, 2013 22:45:04 Steven Schveighoffer wrote:
 On Sun, 30 Jun 2013 22:02:11 -0400, Jonathan M Davis <jmdavisProg gmx.com>
 I know. My point was that that's an inherent problem with built-in AAs
 that
 can't be overcome (regardless of how well they're implemented). If you
 want
 that level of control, you _have_ to use a library solution.
OK. I guess I was just reading your statement like it was a "problem" :)
Well, it is in the sense that it _is_ a deficiency of built-in AAs for those who want to be able to use different implementations for different use cases, but it's not something that can actually be fixed, and having to use a library solution isn't exactly all that bad anyway, especially when most languages don't have AAs built-in in the first place. It's just a convenience feature. - Jonathan M Davis
Jun 30 2013
parent "CJS" <Prometheus85 hotmail.com> writes:
 Well, it is in the sense that it _is_ a deficiency of built-in 
 AAs for those
 who want to be able to use different implementations for 
 different use cases,
 but it's not something that can actually be fixed, and having 
 to use a library
 solution isn't exactly all that bad anyway, especially when 
 most languages
 don't have AAs built-in in the first place. It's just a 
 convenience feature.

 - Jonathan M Davis
Thanks for the dicussion! I thankfully haven't run into problems with needed highly optimized assiociative arrays, but it's good to know what the limitations are and why.
Jun 30 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jun 2013 21:43:53 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Sunday, June 30, 2013 19:20:47 Steven Schveighoffer wrote:
 No, the main issue is the current one is runtime-only, and so simple
 function calls such as toHash and opCmp cannot be inlined.
Yeah. That's a big problem. We really need to templatize all that - though the current implementation is enough of a mess to make that difficult.
The current implementation suffers from two problems: 1. The compiler doesn't treat T[U] as a direct instantiation of AssocArray!(T, U) in all cases. 2. The compiler has bugs in terms of pure/ safe/ctfe/etc that it "overlooks" when using built-in AAs. I think those who have tried to make a complete library-replacement for AAs have found this out. The best path to resolution I think is: 1. make a complete replacement for AAs that can be instantiated and operate without mapping to the AA syntax. It may not build, but it should be written and bugs against the compiler filed. 2. Fix all bugs to make 1. compile/possible 3. Switch compiler to use type in 1. whenever AA's are used. I believe some have made a very good attempt to do 1 (H.S. Teoh I think? maybe someone else) -Steve
Jun 30 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 30, 2013 21:59:45 Steven Schveighoffer wrote:
 On Sun, 30 Jun 2013 21:43:53 -0400, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 On Sunday, June 30, 2013 19:20:47 Steven Schveighoffer wrote:
 No, the main issue is the current one is runtime-only, and so simple
 function calls such as toHash and opCmp cannot be inlined.
Yeah. That's a big problem. We really need to templatize all that - though the current implementation is enough of a mess to make that difficult.
The current implementation suffers from two problems: 1. The compiler doesn't treat T[U] as a direct instantiation of AssocArray!(T, U) in all cases. 2. The compiler has bugs in terms of pure/ safe/ctfe/etc that it "overlooks" when using built-in AAs. I think those who have tried to make a complete library-replacement for AAs have found this out. The best path to resolution I think is: 1. make a complete replacement for AAs that can be instantiated and operate without mapping to the AA syntax. It may not build, but it should be written and bugs against the compiler filed. 2. Fix all bugs to make 1. compile/possible 3. Switch compiler to use type in 1. whenever AA's are used. I believe some have made a very good attempt to do 1 (H.S. Teoh I think? maybe someone else)
Yeah. He was working on it and seems to have pretty much decided that the job is too big for one man (and/or that he doesn't have enough time). I believe that there was a post on D.Learn a few months back where you pointed to where he had his changes thus far (so that others could look at it and potentially continue his work), but AFAIK, he's given up on the whole thing for now. - Jonathan M Davis
Jun 30 2013