OT: 'conduct unbecoming of a hacker'

[Joakim via Digitalmars-d]

On Thursday, 11 February 2016 at 12:47:20 UTC, Ola Fosheim 
Grøstad wrote:
> On Thursday, 11 February 2016 at 11:46:44 UTC, Joakim wrote:
>> 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.
>
> Linux is not a good example. Linux is too high profile and can 
> afford massive churn. That is highly inefficient use of 
> programmer resources.

It was not always high-profile, it started off with one guy and 
grew big through the same decentralized process.

>> 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.
>
> Mostly cons. There are very few potential customers. And most 
> likely no local customers, which are the most attractive ones.

The chicken has to start somewhere, or there will be no eggs. ;)

>> 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.
>
> I didn't say fork. I was talking about people who have given up 
> on the D development process and created their own language in 
> the same catagory as C++ and D.

You mentioned it in response to forks and how far they've gotten. 
  That guy gave up on D?

>> If you believe those languages' priorities are "not entirely 
>> well founded," that's an opportunity for you to get it right. 
>> :)
>
> Sure, I'm thinking about it. But I currently think 
> WebAssembly/JavaScript + Linux server are the most important 
> targets, so maybe going from scratch is less work, actually.
>
> But sure, building a new language over Rust, D or Go is an 
> option.

The loci guy, just a couple years out of university did it, 
surely you could too, if nobody else is getting it right.

>> As the original post noted, both need and want are irrelevant, 
>> if you're unwilling to code.
>
> Nobody are unwilling to code. Most people are unwilling to 
> manage a project or invest in a project that isn't properly 
> managed.  What you need is a well managed project with a clear 
> vision, clear goals and good leadership.
>
> And please don't point at Linus, he is not a particularly 
> effective leader, but probably does well as a manager. But 
> Posix was already given... The broad strokes for a monolithic 
> kernel is kinda given. He just happend to whip up something at 
> the right time, that many people had been looking for (free 
> unix).

In the emails I linked to, he notes that he didn't have a clear 
vision or goals and that it is _likely impossible to do so for 
software_.  So he agrees with you that he isn't some great 
leader, and notes that what's important is the decentralized 
process, where there is _no clear vision_.

Now, you're right that copying UNIX is easier than coming up with 
an entirely new technical design, but he claims that the UNIX 
guys themselves didn't "design" it, that that was an 
evolutionary, decentralized process also.

>> A lot of solo devs using D to go in the same general direction 
>> will work too, probably a lot better than consensus.
>
> Well, not sure what we are talking about here. Clearly, you 
> need consensus among said devs if you are going to change the 
> language so that it can either support better manual memory 
> managment or faster garbage collection?

Not necessarily, Sociomantic didn't wait for permission to go do 
their own concurrent GC for D1.  One can experiment with various 
approaches to memory management and come back with actual data.  
It doesn't take much time to prototype something and test out 
ideas, before you make a push for it to be included in the 
language.

My point is that we're not going to come to a consensus on the 
best approach to memory management.  Somebody, likely several, 
will have to try out different approaches locally and then 
compare results.  Perhaps that will lead to several different GCs 
shipping with D, tuned for different loads.

>> According to Linus, linux never had such a consensus, why did 
>> it succeed?
>
> Because there was no free Unix on x86 and the CPUs at that 
> point in time had MMUs. Many people who used Unix at work or on 
> campus wanted Unix at home too. Many students used Minix in 
> their OS course, and disliked the non-free license. So you 
> basically had a fairly large group of people willing to throw 
> in weeks and months, if not years in the early stages of the 
> project.

That's all well and good, but it doesn't answer the question: how 
did they succeed without prior consensus, which Linus claims was 
never there?

> Refactoring and documentation isn't a restart.
>
> It is common hygiene!

Right, it's a question of whether we stop everything and take a 
thorough bath, or clean a little here and there on the go.  There 
is refactoring constantly going on, and documentation is always 
tough for OSS projects.

>> But python has not emerged from that scripting language niche 
>> either, and I think you greatly overestimate how well C++11 is 
>> doing.
>
> Python was inspired by a language used for teaching 
> programming, but was geared to more advanced programmers. Not 
> sure what you mean by Python not having emerged?

I mean it's still a scripting language used for teaching, 
scripting, and webapps.  Almost nobody is using it for 
application programming, ie anything outside that scripting 
niche, say for mobile apps.

>> Those who want D to specialize more should heed Linus's words.
>
> Can you paraphase those words in a condensed manner that is 
> relevant to programming languages? I don't get the argument.

He noted that the UNIX vendors failed because they were highly 
specialized for certain corporate niches, unlike linux or 
Windows, and couldn't survive a collapse of that niche, because 
they weren't general enough to survive in new niches.  Similarly, 
I'm saying D shouldn't specialize for the same reasons.