Vision for the first semester of 2016

Laeeth Isharc via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Thu Jan 28 03:25:08 PST 2016


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.



More information about the Digitalmars-d-announce mailing list