On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
I do like the building-block idea you suggest, but one must
think about the deeper reasons for why things are owned by
It is much easier to get motivated if you have a certain level
autonomy. Clearly, the "D foundation" should have criterions for
making a recommendation, like API guidelines, Boost license and
commitment to maintaining it for a period of time.
For instance, Ponce has made some efforts on audio. You and
others have made some effort on economic modelling (?). I am
interested in audio. Then we have an opportunity to form a team
that builds a shared numerics library, with some input from some
Phobos coordinator so that ranges are supported in a consistent
But here is the key point: we don't have to get input from all D
programmers. We can form consensus and take ownership and make
faster decisions. And we can scrap it in two years, learn from
our mistakes and create a much better API.
I think that Sonke received too much "negative motivation" for
his contributions recently, if I had been in his shoes I'd
probably found working on vibe.d more fun. IRRC Ruppe also have
voiced that he want to work on libraries which he has more
An frankly, as APIs have to be vetted on large applications in
maintenance mode a lot of the effort put into arguing the design
"perfect Phobos libraries" most likely will be in vain.
(I have found the Coase theorem and work on industrial
organisation to be quite stimulating in thinking about this
I noticed you and the other economic theory guys in the thread
mentioning some interesting models. I'd like to look at those
later when I have more time :-). Always nice to find some shared
language for expressing system dynamics.
In theory it's completely irrelevant as to whether is something
is in the standard library or can just be imported via dub or a
git clone, but in practice that's not the case.
Well, but if something is in the standard library, other
libraries will build upon it and add dependencies to it even if
they don't really have to. Meaning, they will pull in
dependencies and bloat and make Phobos costly to maintain as you
will end up with std.json, std.json2, std.json3 etc.
As you yourself have mentioned, the size of the D community as
it stands today presents some impediment to the possible
maintenance and stability of alternative libraries.
No, I don't think so. I think that D has nurtured the idea that
Phobos should provide everything and therefore the modus operandi
is to complain that Phobos does not provide it.
The bus factor is high for external libraries - people get
sick, divorced, change interest, and so on.
Recommended libraries should have at least 3-6 people behind them
It would be nice to have SIMD intrinsics, and in the time you
have spent arguing over the years perhaps it would have been
possible to help the process of having a high quality and
consistent implementation along.
SIMD isn't critical to me at this point in time. I am currently
using C++ for what I would have liked to use D for. D needs more
compiler developers, a strategy to get there and someone to take
D there with focused leadership.
The main challenge is not code, it is process.
It really doesn't do any good to worry about what the crowd
says and the applause you receive. If you focus on doing good
I don't worry about applause. Describe the key issues and explain
it from various angels whenever it comes up and people start to
develop a shared understanding of what needs to be done.
Without a timeline, why invest? The vision for 2016 looks pretty
good, but there it lacks the details of what and when. What are
the estimates. What are the explicit goals? How many man hours
(min/max) are needed. Goals and estimates.
excited about. I should say that John Colvin is a contractor
for me, but I am not talking up dlangscience because he is
helping me, but rather I asked him to help me because I was
impressed by what he is doing.
That's great! :-)
It strikes me as a bit silly to get hung up over language
specifications as some kind of mystical talisman.
It brings unfortunate inconsistencies and implementation effects
to the foreground so that they can be addressed. It is near
impossible to discuss the design without one.
debating about what people should do, when there is no army of
troops that can be commanded to implement things they are not
interested in doing anyway.
Attract more developers.
1. Find out why they don't come.
2. Find out why they leave.
3. Address the issues they have with D.
In my case and for many others the reason go along the lines of:
memory management, language inconsistencies, a refusal to add
builtin tuples and platform support.