OT: 'conduct unbecoming of a hacker'

[Joakim via Digitalmars-d]

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.