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.
