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.

Reply via email to