On Thursday, 28 January 2016 at 10:00:59 UTC, Ola Fosheim Grøstad
This is what a good system programming standard library should
1. Types needed to specify library APIs.
2. Functionality for accessing hardware in a non-emulated
3. Functionality that most _libraries_ need to build on (like
4. Functionality that is tied to the individual compiler (like
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
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
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
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
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.