On Thursday, 11 September 2014 at 17:10:13 UTC, Joakim wrote:
Let me begin by noting that I'm glad you're tinkering with D,
:) as I noted earlier that experimentation is good.
Yeah, but there are many different models to design. Informally:
1. organic/evolutionary design: let development go in many
directions and let the most fit solutions survive. "The proof of
the pudding is in the eating". Comes with overhead.
2. expert design: let people with theoretical knowledge do the
overarching design and let regular people do the implementation.
"sistine chapel". Risks of missing the target.
3. democratic/iterative/evolutionary design: involve end users in
the process and let them design features. The big advantage is
end user acceptance, the downside is that they might vote for the
wrong features.
I prefer a mix of 1/2, but you can make good arguments for all of
these and several other models. Basically, there are trade-offs.
Some good, some bad.
These "totalitarian" or "cult" arguments don't go anywhere
because it is easy to shrug them off, since the reality is far
from that extreme. The core D group can sometimes be insular,
but I don't think that's really the problem here.
No, but I have previously argued against having a single branch
and rather have one stable branch maintained by the "D team", and
then have an experimental branch which is more lax and open to
experimental contributions and "fun".
People working on the main branch need to align their goals to be
productive, but you can only do that with a limited amount of
people. Team-management is a challenging task, so you have to
limit the size of the team if you want to do it well.
What is really wrong is brushing latent conflicts and
irreconcilable expectations under the carpet. That can grow over
time into fracturing. It is better to have them in the open at an
early stage.
What you are saying is basically that you disagree with the
license, so maybe Walter should have spent more time making
sure that he had backing for it in the community, but that is
an issue you have to take up with him. Not me or ketmar.
This argument has nothing to do with the Boost license, as
practically every open source license allows the same forking.
Looking back at how this blew up, it was actually Daniel who
asked you not to "fork D's syntax" and then Dicebot merely
reinforced that, before you both went overboard.
Actually, I usually agree with most of what Dicebot says in other
threads. He is intelligent, analytical and focused. So I was a
bit surprised here, but anyone can be tired and have a bad day,
and the reasons are not important anyway.
Besides, he is not alone in thinking that a fork would be WRONG,
so that tells me that the team-building process behind the
selection might have been too much top-down and that some
community building efforts are lacking.
In software process improvement you need to spend time on changes
in policies so that you bring everyone with you (or in the worst
case break up all teams and rebuild them from scratch, very
costly ;-)
I also think that the GPL would be a more fitting license for D,
given the democratic process and the community aspect.
But I would not modify the source then. So the license sure
matters. MIT/BSD has traditionally been used for reference
implementations for commercial closed source refinement. It is
basically "take this and do whatever you want, no strings
attached, but don't blame me for failures" licenses.
But you need to choose, because in open source:
product == source-code + license
support == forums/community
end users == people who download the source-code
We are only end users, not D devs. Maybe later devs, but
currently just end users that evaluate the "product", which
includes the license.
The real issue is that historically any programming language
didn't want a bunch of incompatible syntax dialects floating
around, as that makes it difficult for many devs to understand
what the language proper actually consists of. That concern
about "fragmentation" is all Daniel and Dicebot were speaking
to.
I know a fair share of the history of programming languages. Lots
of dialects did not make them less popular as a "group". On the
contrary. It probably increased their proliferation.
Inconvenient? Sure.
Pascal would have died without Turbo Pascal, TP and C was better
than regular Pascal…
C++ and objective-C did not make C irrelevant. IMO C++ made it
necessary to come up with much needed improvements to C that
probably would never have come about if C++ did not exist.
SQL and C leaves a lot of stuff implementation defined. The
uptake of these 2 is huge.
And what is a dialect and what is a new language? Aren't most
C-like languages more or less dialects with the same root?
However, I've noted that is not a reason to frown on syntax
experimentation like you and ketmar want to do, as your syntax
tweaking is far from a full-blown or popular dialect yet. I've
also noted that there may be a modern solution to such a
problem, automated syntax translation for different dialects.
Yeah, that is my goal for my experiments for now. To have a
distinct pre-amble in the head of each source code file and
provide 2 parsers and keep it compatible with a restricted set of
D (no GC).
However a fork is no real threat to D for the following reasons:
1. Walter Bright is a good C++ programmer with intimate knowledge
of the D compiler internals. If a D dialect is good he can
implement the good features in the main branch with less effort.
Copyright does not constrain this. (only patents)
2. To fund a fork you probably have to close the source code and
target small specialised commercial markets. That means high
licensing costs. Which in turn means that for every sale of a
closed source dialect there will be 100s of users looking for a
free version. It could looked upon as free marketing.
This is my take on this: I don't think a fork is a bad thing, and
I think BSD/MIT style licensing increase the probability of a
fork down the road compared to GPL. The payoff for forking is
simply higher with a liberal license.
