Vision for the first semester of 2016

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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 
> which people.

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 
matter.

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 
freedom with.

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 
> question).

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.