On Thursday, 28 January 2016 at 10:00:59 UTC, Ola Fosheim Grøstad wrote:
This is what a good system programming standard library should provide:

1. Types needed to specify library APIs.

2. Functionality for accessing hardware in a non-emulated fashion.

3. Functionality that most _libraries_ need to build on (like arrays/iterators/ranges).

4. Functionality that is tied to the individual compiler (like intrinsics).

5. Memory management.


The primary goal of the standard library should not be to support building applications, but to enable building frameworks and libraries and the interaction between them.


So if one user says "My app needs to read WAV which is RIFF, therefore RIFF should be in the standard library" then the sensible response is: "Do most _libraries_ need RIFF? Why don't you use the recommended audio library which has optimized WAV support.".

Surely everyone uses string processing on a daily basis?

No. I personally almost never do string processing in system level programming languages, what I need is binary serializing support. Or Collada support. Or audio file format support.

I'd be happy to use a recommended string procesessing library when or if I need it.

But a standard library MUST have great support for SIMD intrinsics, i.e. interfacing the hardware, that is much more critical for system level programming and is tied to the specific compiler.

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. (I have found the Coase theorem and work on industrial organisation to be quite stimulating in thinking about this question).

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.

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. If something is in Phobos you know that you can depend on it, that bugs will get fixed, and that changes to the language won't stop the code from compiling (since it will be fixed). Being in Phobos is a focal point, whereas there simply isn't for now any kind of focal point for external libraries. The bus factor is high for external libraries - people get sick, divorced, change interest, and so on.

There are also benefits from coherence, since the code will tend to converge on a similar style.

I appreciate that your own interests are quite different, but perhaps you can see that they are only part of what's important for the community as a whole.

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. People would also be much more inclined to listen to what you say because then it comes from someone with serious skin in the game. (Walter himself has spoken about the importance of listening to people who like your stuff and use it already over those who say if only you did X we could use it on a large scale - and that's also plain good business sense). The gadfly can play a useful role in a community, but not if he continually diminishes the worth of what people are working hard trying to do (in inevitably imperfect human ways).

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 work (and have some reinforcement along the way because people are using your work to do serious things) then recognition will come.

The work that dlangscience is doing (and one could see ndslice as a part of that) opens up new possibilities that I am quite 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.

It strikes me as a bit silly to get hung up over language specifications as some kind of mystical talisman. C was used for years in a serious way before the ANSI spec. Same for Ruby. I couldn't immediately see what the situation was for Python. There isn't the manpower to go that route yet, and nor would it be constructive when certain aspects are not yet as polished as they will eventually be.

Ultimately the test of a language is in whether people can use it to do good work. Compound growth can be very powerful, and more complex things take time to mature to the point where they are useful in certain domains. I couldn't have used D for work five years ago, but I can now. There are these threshold effects, just as Christensen described in the Innovator's Dilemma. D continues to grow and isn't going to disappear any time soon. It would be much better to put one's energy into actually writing code that can improve things (even as a proof of concept) than debating what might or might not happen if things don't change (when they always do). Kingsley hadn't been using D long, liked his IDE, so wrote a D module for it. It's not perfect yet, but it's a beginning and will mature in time. That kind of thing will get us much further than 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.

Walter clearly doesn't decide everything, any more than a prince does in a monarchy of old. But we are lucky that he does have such an important influence because he has good taste and a rare skill set. One gets a higher quality design that way than if you have something that is the pure creation of a committee.

At some point maybe there'll be a need for a committee and a language spec. That's a higher quality problem to have, but it surely isn't the main concern today.

Reply via email to