On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote:
> On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc wrote:
>> On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote:
>>> True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered.
>>
>> Which ones, out if interest ?  And in your opinion were they thought through ?
>
> Specifically, DIP69 and its predecessors, which propose a Rust-inspired lifetime and escape analysis system as a solution to many of D's memory model woes.
>
> It seemed (and still seems) like a good solution to me, but I recognize that I am insufficiently experienced and knowledgeable in the relevant areas to deserve a vote in the matter.
>
> So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution.
>
> As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.)
>
> In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons.

Beyond my pay grade, but looks to me like study group is devoted to just this kind of question and in response to observation that this is something very important to get right and very difficult the discussion is beginning with a simpler but important (there were some stats on chrome that were quite shocking) problem of how to do RC strings.

If there's one area where you shouldn't just accept patches this surely must be it !  And I don't see the people that are grumbling participating in the study group...

On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote:
> Joakim:
> "Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus."
>
> No - I think he used Stallman as an example of someone who although he whined a lot actually did a hell of a lot of work even so and became the change in the world he wanted.  In my view productivity isn't about how many projects you don't manage to finish, but how many you do get done, and I am not sure I am in a position to criticize Stallman from that perspective

He got some stuff done, which I alluded to, but his big project to build an OS on which to run his tools didn't.

> even if his ideological approach isn't entirely my cup of tea, I do recognize he played a critical role there that was necessary.

Eh, there were always the BSDs and essentially nobody runs GNU code today.  Android, that big open-source success, comes with almost no GNU code, just the linux kernel from Linus and company and a bunch of Apache-licensed code.  A lot of the BSD guys went to work at Apple, where they have now spread the permissively-licensed Darwin base of OS X and iOS to more than a billion devices, along with llvm and other permissively-licensed projects.

Stallman's GNU/GPL effort has largely failed, so he was clearly neither critical nor necessary.  Was he important, as a vocal proponent of FOSS early on?  Perhaps, but things would likely have progressed this way regardless, as his extremist, quasi-religious preaching of "free software" is largely dying out.  That religious fervor may even have hurt as much as it helped early on, as that collaborative model only really took off after the more business-friendly rebranding as "open source," which has also led to a move to more permissive licenses, ie not the GPL.

My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well.

On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote:
> So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution.
>
> As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.)

I'll note that not knowing a better solution doesn't mean one must simply accept the solution at hand, especially if that temporary solution will be difficult to unwind later.  Sometimes you simply need more time to come up with something better.  It all depends on the scale of the project and the suitability of the solution presented; you cannot simply say that "some" solution is better than nothing, as the original quoted post does.

But yeah, maybe the reasons for rejection can be communicated better.

> In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons.

This is why you should generally only work on something you actually need, which is a great discipline.  Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs.

For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that.  I was told it was one of many priorities, but nobody knew when it'd be worked on.  Two years later, seeing mobile still hadn't been done (though others had gotten ldc/gdc working on linux/ARM to some extent), I took it up and, along with Dan, alpha releases for iOS and Android are now listed on the main download page.

It doesn't matter to me if nobody here uses D on mobile- though I certainly think that would be a huge missed opportunity- as _I_ want to use D on Android and now I can.

While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language features, it is for pretty much everything in druntime/phobos and some even do it for dmd.  Caring enough about a change to code it yourself is a good test for whether it is worth doing, which is one point the original post alludes to.

On Thursday, 11 February 2016 at 06:01:29 UTC, Laeeth Isharc wrote:
> Beyond my pay grade, but looks to me like study group is devoted to just this kind of question

It's not just devoted to this *kind* of question - it's devoted to this *exact* question. It was formed explicitly for the purpose of trying to work out an acceptable solution to the reference-counting safety problem.

> and in response to observation that this is something very important to get right and very difficult the discussion is beginning

"Starting over" or maybe even "sidetracking" would be more accurate - quite a lot of other stuff got posted in the study group before the RCString thing came up. No consensus was emerging, hence the reset.

> with a simpler but important (there were some stats on chrome that were quite shocking) problem of how to do RC strings.
>
> If there's one area where you shouldn't just accept patches this surely must be it !

True. It's a hard problem, especially since they're shooting for making safe RC a non-breaking change.

> And I don't see the people that are grumbling participating in the study group...

? But some of them are. The grumbling over RC is a reflection of how hard the problem is to solve, not a collective unwillingness to contribute code on the part of either side.

On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote:
> On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote:
>> As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.)
>
> I'll note that not knowing a better solution doesn't mean one must simply accept the solution at hand, especially if that temporary solution will be difficult to unwind later.  Sometimes you simply need more time to come up with something better.  It all depends on the scale of the project and the suitability of the solution presented; you cannot simply say that "some" solution is better than nothing, as the original quoted post does.
>
> But yeah, maybe the reasons for rejection can be communicated better.

Although I realize it might sound like I am, I'm not really criticizing either side in this.

I don't really know whether either DIP69 or DIP77 actually represents a reasonable solution to the problem; as I said, I am unqualified to make that determination. I was simply giving my impression of where the discussion stands at the moment.

I am certainly not advocating that DIP77 be implemented over the objections of so many of the people in the community who *are* qualified.

>> In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons.
>
> This is why you should generally only work on something you actually need, which is a great discipline.  Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs.

Definitely.

> For example, I asked about ARM and mobile support for D [...]

Your efforts are appreciated! I don't know if anyone else is using your work *yet*, but give it time and I'm confident that they will. ARM and Android are very important platforms.

On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote:
> Eh, there were always the BSDs and essentially nobody runs GNU code today.

Uhm... Many do. And beyond GNU, the GPL/LGPL are the most common licenses in community driven open source productivity applications: Gimp, Inkscape, Blender, Audacity...

> My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well.

It has not done well with corporations, but it has done very well with open source end-user software! Even projects that are not GPL tend to use LGPL code.

Yet, Linux did manage to scare the juggernauts, so now even Microsoft is starting to publish under liberal licenses (first very restrictive, now very liberal).

> This is why you should generally only work on something you actually need, which is a great discipline.  Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs.

Well, yes. Unless you are designing a standard library. The original open source projects were mostly about recreating existing designs, but with a open source license. So the missing features were obvious. In the case of GNU (Unix), it is a cluster of individual small programs. So if people was unhappy they wrote a new version from scratch. And the most popular ones survived.

Creative designs that went open source tended to be research projects... so you had a clear vision (and people who were experts in their field leading the design).

So, the linked rant is pretty clueless IMO. You need to form consensus in order to gain focus. If you don't have focus you'll never end up with something coherent. If the author believed in what he wrote, then why did he write it? He obviously wrote it because he believe that communication  can lead to change. And thereby he undermines his own argument...

What brought original FOSS projects focus was the fact that they were not implementing original designs. And there has been LOTS of advocacy and arguments on usenet about every creek and cranny in software... since way before the Internet existed.

So, it was an entertaining rant... and nothing more.


> For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that.  I was told it was one of many priorities, but nobody knew when it'd be worked on.

Yes, and this is all good, but it is not a language issue. It fits well with what makes contributing to GNU/Unix easy. You can write an isolated piece.


> While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language features, it is for

Several people have created their own languages because they have given up on the D development process...


> for dmd.  Caring enough about a change to code it yourself is a good test for whether it is worth doing, which is one point the original post alludes to.

Writing code without a fork, when you know it will be rejected, is pointless.

Spending days or weeks on a DIP, in order to have it dismissed by a "nice technical DIP, but does not fit with our vision", is very wasteful.

So people create their own languages instead, but without building consensus, meaning they end up in an incomplete state or being to close to D, having a different set of issues. Which is a key aspect of D's problem too, it is too close to C++ to not be compared to it. So fixing some issues and introducing others isn't good enough for adoption.

Building consensus is very important. Just take a look at politics. Communicating a clear vision and a believable path to implementation is essential. And listening. Good leaders are always very good at listening, IMO.

On Thursday, 11 February 2016 at 07:32:00 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote:
>> Eh, there were always the BSDs and essentially nobody runs GNU code today.
>
> Uhm... Many do. And beyond GNU, the GPL/LGPL are the most common licenses in community driven open source productivity applications: Gimp, Inkscape, Blender, Audacity...

All of which are decades-old projects from the heyday of the GPL, when many mistakenly attributed linux's success to the GPL and copied its license blindly.  Almost nobody starts new projects with the GPL today, and it seems they've also given up on such OSS productivity apps.

>> My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well.
>
> It has not done well with corporations, but it has done very well with open source end-user software! Even projects that are not GPL tend to use LGPL code.

Define "very well." :) Because I've listed multiple permissively-licensed projects that are a couple orders of magnitude more widely used, and I see almost no GPL software even close.  It's basically just the linux kernel and that's it, and that only because it was piled high with permissively-licensed and even closed software on top, with Android.

> Yet, Linux did manage to scare the juggernauts, so now even Microsoft is starting to publish under liberal licenses (first very restrictive, now very liberal).

It did nothing of the sort, as GNU/linux basically went nowhere and MS didn't care.  It is only once permissively-licensed software like Android and parts of iOS hit billions of devices that MS started doing so, under permissive licenses like those projects, not the GPL.

>> This is why you should generally only work on something you actually need, which is a great discipline.  Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs.
>
> Well, yes. Unless you are designing a standard library.

Anything you want to add to a standard library can easily be maintained in a private fork or put up on dub, as you've suggested doing to all of phobos.  So even if you don't get a change into the standard library, there's nothing stopping you from using it or distributing it, so this comment seems pointless.

> The original open source projects were mostly about recreating existing designs, but with a open source license. So the missing features were obvious. In the case of GNU (Unix), it is a cluster of individual small programs. So if people was unhappy they wrote a new version from scratch. And the most popular ones survived.
>
> Creative designs that went open source tended to be research projects... so you had a clear vision (and people who were experts in their field leading the design).
>
> So, the linked rant is pretty clueless IMO. You need to form consensus in order to gain focus. If you don't have focus you'll never end up with something coherent. If the author believed in what he wrote, then why did he write it? He obviously wrote it because he believe that communication  can lead to change. And thereby he undermines his own argument...

I agree with everything till you start espousing consensus.  If anything, consensus often leads to the most incoherent designs, ie design by committee.

> What brought original FOSS projects focus was the fact that they were not implementing original designs. And there has been LOTS of advocacy and arguments on usenet about every creek and cranny in software... since way before the Internet existed.
>
> So, it was an entertaining rant... and nothing more.

It had some good points, but was inconsistent.  Perhaps one reason OSS projects have become less willing to take his patches is that they've become much more widely used, where if your project ships on Android, it will be used by a billion and a half people.  Given that these projects are still way understaffed- look at OpenSSL and its Heartbleed bug- it's understandable that some would be conservative.  Of course, it's possible that the projects he talked to had almost no users, so it all depends on the scale of the project, as I said before.

>> For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that.  I was told it was one of many priorities, but nobody knew when it'd be worked on.
>
> Yes, and this is all good, but it is not a language issue. It fits well with what makes contributing to GNU/Unix easy. You can write an isolated piece.

Even with language issues, there is potential for deviation.  For example, if you think there might be commercial users for that feature, you could sell them a slightly forked version of dmd with your feature.  It's what the zapcc devs did with clang:

https://www.phoronix.com/scan.php?page=news_item&px=New-Zapcc-Clang-Benchmarks

If it works out well enough, maybe you could integrate it back upstream eventually.

>> While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language features, it is for
>
> Several people have created their own languages because they have given up on the D development process...

And how far have they gotten?  Entire forks don't get very far, but a tracking branch with a few additional features can do just fine.

>> for dmd.  Caring enough about a change to code it yourself is a good test for whether it is worth doing, which is one point the original post alludes to.
>
> Writing code without a fork, when you know it will be rejected, is pointless.

Then perhaps you didn't really need that code, if you wouldn't have gotten much use out of it on your own.  Yes, I've admitted that maintaining some language features is too painful or different to maintain in a private branch, but many can.

> Spending days or weeks on a DIP, in order to have it dismissed by a "nice technical DIP, but does not fit with our vision", is very wasteful.

I agree that it would be better to nip that in the bud where possible or better explain why the DIP doesn't fit, but many times such rejection is an inevitable byproduct of maintaining a high technical standard.

Now, maybe it's impossible to maintain a high technical standard with a community-driven OSS project and you need a business model to be able to afford such exploration and possible waste of time. That may be a fundamental tension between technical quality and the OSS development model that cannot be resolved.  But I see no way around such rejection if you want to maintain a high level of quality.

> So people create their own languages instead, but without building consensus, meaning they end up in an incomplete state or being to close to D, having a different set of issues. Which is a key aspect of D's problem too, it is too close to C++ to not be compared to it. So fixing some issues and introducing others isn't good enough for adoption.

One of the reasons it's close is that new versions of C++ are copying D. :) I don't blame them for doing so or think there's anything wrong with it, but there are still enough problems with C++ that I don't think it'll be enough.

> Building consensus is very important. Just take a look at politics. Communicating a clear vision and a believable path to implementation is essential. And listening. Good leaders are always very good at listening, IMO.

Yes, politics, look at how much the politicians get done! ;) I think we all know and Walter and Andrei have said that they're not managers.

But I don't think consensus is useful, what matters is making the right technical decisions.  Sometimes that comes from long technical debate where everybody shoots holes in everybody else's ideas and eventually somebody decides to implement the least bullet-ridden idea.  Sometimes it comes from one person going down a path only they see the end to.

Consensus is for getting everybody doing the same thing, which is not the road to technical quality.  Linus has talked about the "wasteful" OSS approach, which he compares to evolution:

http://bobweigel.net/projects/index.php?title=Weigel/Notes#Linus_on_Development

Everything else about vision and listening, sure, but in an OSS project everybody is free to ignore that vision.  It's one reason why I wish the official vision statement was much more specific and daring, because no matter what, we're free to ignore it, so there's no risk.

At least you laid out a specific, original vision, and we can see if we want to follow it.  But if you make bland, shapeless statements like "Improve quality," weren't we trying to do that anyway?  It then becomes one of those corporate mission statements, which are notable only for stating the bland and the obvious.

On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote:
> Consensus is for getting everybody doing the same thing, which is not the road to technical quality.  Linus has talked about the "wasteful" OSS approach, which he compares to evolution:
>
> http://bobweigel.net/projects/index.php?title=Weigel/Notes

Btw, in looking for a link with that old Linus quote, I also found this other one, that I'd never read before and is relevant for those who think D should specialize more:

Linus:
Quite frankly, Sun is doomed. And it has nothing to do with their
engineering practices or their coding style.

Tim:
I'd love to hear your thoughts on why.

Linus:
You heard them above. Sun is basically inbreeding. That tends to be good
to bring out specific characteristics of a breed, and tends to be good for
_specialization_. But it's horrible for actual survival, and generates a
very one-sided system that does not adapt well to change.

Microsoft, for all the arguments against them, is better off simply
because of the size of its population - they have a much wider consumer
base, which in turn has caused them largely to avoid specialization. As a
result, Microsoft has a much wider appeal - and suddenly most of the
niches that Sun used to have are all gone, and its fighting for its life
in many of its remaining ones.

Why do you think Linux ends up being the most widely deployed Unix? It's
avoided niches, it's avoided inbreeding, and not being too directed means
that it doesn't get the problems you see with unbalanced systems.

Face it, being one-sided is a BAD THING. Unix was dying because it was
becoming much too one-sided.
http://yarchive.net/comp/evolution.html

On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote:
> All of which are decades-old projects from the heyday of the GPL, when many mistakenly attributed linux's success to the GPL and copied its license blindly.

Yes, it does take decades to create complicated productivity apps.

The only open source productivity app I use that isn't GPL is Open Office (IIRC), but it uses LGPL components, and is more corporate than community...

> It did nothing of the sort, as GNU/linux basically went nowhere and MS didn't care.  It is only once permissively-licensed software like Android and parts of iOS hit billions of devices that MS started doing so, under permissive licenses like those projects, not the GPL.

Android is based on Linux... but this is not how I remember it. Bill Gates went public with statements against FOSS way before Android appeared. He was clearly frustrated by how Linux made inroads in the server market.

> Anything you want to add to a standard library can easily be maintained in a private fork or put up on dub, as you've suggested doing to all of phobos.  So even if you don't get a change into the standard library, there's nothing stopping you from using it or distributing it, so this comment seems pointless.

I've repeatedly stated that libraries, phobos inclusive, are inconsequential.

What matters is the language, compiler and runtime.

Libraries are luxury items.

> I agree with everything till you start espousing consensus.  If anything, consensus often leads to the most incoherent designs, ie design by committee.

No. A standards committee is a collection of representatives that are trying to balance out different conflicting agendas.

If you build at team you are better off establishing consensus. So step one is to attract people with the same agenda. So if you want to fork you should try to build consensus within a faction and then branch off. If only 1 or 2 people create a fork it will most likely go nowhere.

> For example, if you think there might be commercial users for that feature, you could sell them a slightly forked version of dmd with your feature.

Yes, I've given that some thought. But for it to pay off you need a refactor high quality code documented code base. If a 1-2 person team is to serve customers you cannot waste hours on poor infrastructure.

> And how far have they gotten?  Entire forks don't get very far, but a tracking branch with a few additional features can do just fine.

One project got pretty far, but then it went dead because their life situation changed as far as I can tell.

Another one is alive, but is too close to C++, but not close enough:

http://loci-lang.org/

I think Loci looks quite ok, but it might be too influenced by personal taste. I think the same applies to many languages, even Rust, Go and D. Too opinionated, by not entirely well founded priorities.


> Then perhaps you didn't really need that code, if you wouldn't have gotten much use out of it on your own.  Yes, I've admitted that maintaining some language features is too painful or different to maintain in a private branch, but many can.

Yep, that's true. I don't need any other languages than C++, TypeScript and Python. But what I need is not the same as what I want!


> Now, maybe it's impossible to maintain a high technical standard with a community-driven OSS project and you need a business model to be able to afford such exploration and possible waste of time. That may be a fundamental tension between technical quality and the OSS development model that cannot be resolved.  But I see no way around such rejection if you want to maintain a high level of quality.

Well, I think it matters that people can sit around a table and talk. And one can probably find solutions for doing cooperative work in a better way with the high bandwidths we have on the Internet today. But building a team with a shared vision and the right knowledge/attitude is not so easy either.

Doing innovative things as a collective is very challenging. I think it takes much higher communication/people skills than is commonly found in these kind of projects.

> One of the reasons it's close is that new versions of C++ are copying D. :) I don't blame them for doing so or think there's anything wrong with it, but there are still enough problems with C++ that I don't think it'll be enough.

Which features are you thinking of? I think D has rushed to implement proposed C++ features... (It can take a decade for things to make it into C++)


> Yes, politics, look at how much the politicians get done! ;) I think we all know and Walter and Andrei have said that they're not managers.

So, what is the process? Where is the quality assurance?

They have to do managment if they want to lead. Architects do manage the process. They don't lay down bricks. That's how great buildings become... great.

And no, a programming language cannot be a "bazaar" (that's Php and Perl).


> But I don't think consensus is useful, what matters is making the right technical decisions.

It matters if you don't want to go solo.

> Consensus is for getting everybody doing the same thing, which is not the road to technical quality.

Consensus is for building a shared vision of what the future will look like so that people thing the project is worth backing and will go somewhere. Then you can have more independent processes on the details.

> Everything else about vision and listening, sure, but in an OSS project everybody is free to ignore that vision.  It's one reason why I wish the official vision statement was much more specific and daring, because no matter what, we're free to ignore it, so there's no risk.

Yes. But it could be simple. Like.

1. full feature freeze
2. heavy refactoring
3. full documentation of module x, y and z.

+ some details on goals and planning

> anyway?  It then becomes one of those corporate mission statements, which are notable only for stating the bland and the obvious.

Yes, bland missions statements have little value by themselves, although for very big and fractured groups they can get some sense of a "we", although I think often the process is more important, i.e. the social communication between groups can be more important than the resulting mission statement.

On Thursday, 11 February 2016 at 10:21:19 UTC, Joakim wrote:
> You heard them above. Sun is basically inbreeding. That tends to be good
> to bring out specific characteristics of a breed, and tends to be good for
> _specialization_.

Linus is not a very good analyst. All the big iron corporations had transition problems: Cray, SGI, IBM, Sun and many more.

It would be very difficult to take the expertise SUN had and rapidly turn SUN into a competitive force in a different field.

Of course, none of this is relevant to programming languages. Perl died because Python was better. Not because the niches changed. C++11 is replacing C/C++98 for newer projects that need performance. Better hardware means the niche has shrunk, but it will remain a significant niche.

On Thursday, 11 February 2016 at 10:52:31 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote:
>> All of which are decades-old projects from the heyday of the GPL, when many mistakenly attributed linux's success to the GPL and copied its license blindly.
>
> Yes, it does take decades to create complicated productivity apps.

That almost nobody uses?  I can do that in a day. ;)

> The only open source productivity app I use that isn't GPL is Open Office (IIRC), but it uses LGPL components, and is more corporate than community...

I never use any productivity apps, including an IDE, never saw the point to them.  And almost nobody uses the OSS ones you list either.

>> It did nothing of the sort, as GNU/linux basically went nowhere and MS didn't care.  It is only once permissively-licensed software like Android and parts of iOS hit billions of devices that MS started doing so, under permissive licenses like those projects, not the GPL.
>
> Android is based on Linux... but this is not how I remember it. Bill Gates went public with statements against FOSS way before Android appeared. He was clearly frustrated by how Linux made inroads in the server market.

They may have made statements before, but didn't change their behavior till permissively-licensed projects actually started doing really well in the market, as they're nothing if not observers of market success.  As for Android using linux, I addressed that below: Android has much more permissively-licensed and closed software on top of its linux kernel.

>> Anything you want to add to a standard library can easily be maintained in a private fork or put up on dub, as you've suggested doing to all of phobos.  So even if you don't get a change into the standard library, there's nothing stopping you from using it or distributing it, so this comment seems pointless.
>
> I've repeatedly stated that libraries, phobos inclusive, are inconsequential.
>
> What matters is the language, compiler and runtime.
>
> Libraries are luxury items.

I was responding to your statement that people could code something up and use it themselves, "unless you are designing a standard library."  If libraries don't matter, I don't see why you'd bring that up as an exception.

>> I agree with everything till you start espousing consensus.  If anything, consensus often leads to the most incoherent designs, ie design by committee.
>
> No. A standards committee is a collection of representatives that are trying to balance out different conflicting agendas.

Which is precisely what leads to incoherence.  It is theoretically possible that one can come up with a balanced design by committee that is also the best, but the problem is that many of the representatives are either wrong or don't matter, so by balancing in their concerns, you almost always end up with a product unbalanced for the real world.

> If you build at team you are better off establishing consensus. So step one is to attract people with the same agenda. So if you want to fork you should try to build consensus within a faction and then branch off. If only 1 or 2 people create a fork it will most likely go nowhere.

That's why I differentiated between getting a team on the same page and high-quality coherent designs.  The former may get more done, but usually not at high quality.  Read up more at the Linus links I gave to get the alternate perspective, of how to do it _without_ consensus.

>> For example, if you think there might be commercial users for that feature, you could sell them a slightly forked version of dmd with your feature.
>
> Yes, I've given that some thought. But for it to pay off you need a refactor high quality code documented code base. If a 1-2 person team is to serve customers you cannot waste hours on poor infrastructure.

On the other hand, that means only those who really know or are willing to spend the time learning the codebase can compete with you, ie new competition can't get going as fast.  There are both pros and cons to being early.

>> And how far have they gotten?  Entire forks don't get very far, but a tracking branch with a few additional features can do just fine.
>
> One project got pretty far, but then it went dead because their life situation changed as far as I can tell.
>
> Another one is alive, but is too close to C++, but not close enough:
>
> http://loci-lang.org/
>
> I think Loci looks quite ok, but it might be too influenced by personal taste. I think the same applies to many languages, even Rust, Go and D. Too opinionated, by not entirely well founded priorities.

How is Loci in any way a fork of D?  It may be similar in its features and goals, but it doesn't appear to fork any dmd or D code.

If you believe those languages' priorities are "not entirely well founded," that's an opportunity for you to get it right. :)

>> Then perhaps you didn't really need that code, if you wouldn't have gotten much use out of it on your own.  Yes, I've admitted that maintaining some language features is too painful or different to maintain in a private branch, but many can.
>
> Yep, that's true. I don't need any other languages than C++, TypeScript and Python. But what I need is not the same as what I want!

As the original post noted, both need and want are irrelevant, if you're unwilling to code.

>> Now, maybe it's impossible to maintain a high technical standard with a community-driven OSS project and you need a business model to be able to afford such exploration and possible waste of time. That may be a fundamental tension between technical quality and the OSS development model that cannot be resolved.  But I see no way around such rejection if you want to maintain a high level of quality.
>
> Well, I think it matters that people can sit around a table and talk. And one can probably find solutions for doing cooperative work in a better way with the high bandwidths we have on the Internet today. But building a team with a shared vision and the right knowledge/attitude is not so easy either.
>
> Doing innovative things as a collective is very challenging. I think it takes much higher communication/people skills than is commonly found in these kind of projects.

I think the biggest issue is money: you can't pay the bills with open source work.  If there were a business model for open source, which I happen to have conveniently provided years ago, :) then things change:

http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing

>> One of the reasons it's close is that new versions of C++ are copying D. :) I don't blame them for doing so or think there's anything wrong with it, but there are still enough problems with C++ that I don't think it'll be enough.
>
> Which features are you thinking of? I think D has rushed to implement proposed C++ features... (It can take a decade for things to make it into C++)

I don't use or follow C++, but stuff like CTFE has been mentioned in this forum before.

>> Yes, politics, look at how much the politicians get done! ;) I think we all know and Walter and Andrei have said that they're not managers.
>
> So, what is the process? Where is the quality assurance?
>
> They have to do managment if they want to lead. Architects do manage the process. They don't lay down bricks. That's how great buildings become... great.
>
> And no, a programming language cannot be a "bazaar" (that's Php and Perl).

I believe my second Linus link below has the answers to these questions, yes, the bazaar.  Now, I agree that the current OSS bazaar usually ends up with low-quality results, which is why I mentioned that high-quality OSS needs the help of another kind of bazaar, the market, where actual money changes hands.

>> But I don't think consensus is useful, what matters is making the right technical decisions.
>
> It matters if you don't want to go solo.

A lot of solo devs using D to go in the same general direction will work too, probably a lot better than consensus.

>> Consensus is for getting everybody doing the same thing, which is not the road to technical quality.
>
> Consensus is for building a shared vision of what the future will look like so that people thing the project is worth backing and will go somewhere. Then you can have more independent processes on the details.

According to Linus, linux never had such a consensus, why did it succeed?

>> Everything else about vision and listening, sure, but in an OSS project everybody is free to ignore that vision.  It's one reason why I wish the official vision statement was much more specific and daring, because no matter what, we're free to ignore it, so there's no risk.
>
> Yes. But it could be simple. Like.
>
> 1. full feature freeze
> 2. heavy refactoring
> 3. full documentation of module x, y and z.
>
> + some details on goals and planning

Such restarts rarely work out in the best of circumstances, ie a company with lots of money, even more so in a volunteer community.  Not saying it can't or shouldn't be done, just that incremental improvement is more likely.

On Thursday, 11 February 2016 at 11:14:13 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 February 2016 at 10:21:19 UTC, Joakim wrote:
>> You heard them above. Sun is basically inbreeding. That tends to be good
>> to bring out specific characteristics of a breed, and tends to be good for
>> _specialization_.
>
> Linus is not a very good analyst. All the big iron corporations had transition problems: Cray, SGI, IBM, Sun and many more.
>
> It would be very difficult to take the expertise SUN had and rapidly turn SUN into a competitive force in a different field.

That's _exactly_ what he said, not sure what you disagree with.

> Of course, none of this is relevant to programming languages. Perl died because Python was better. Not because the niches changed. C++11 is replacing C/C++98 for newer projects that need performance. Better hardware means the niche has shrunk, but it will remain a significant niche.

But python has not emerged from that scripting language niche either, and I think you greatly overestimate how well C++11 is doing.  All the interest in Rust, Go, D, and Swift is because C++ is having problems attracting those newer projects.

You can call C++ a "niche," but the fact is that it is not specialized for game development or cloud services, ie it's still fairly general purpose.  Those who want D to specialize more should heed Linus's words.