Remember the Vasa! by Bjarne Stroustrup

[Laeeth Isharc]

On Friday, 1 June 2018 at 18:18:17 UTC, Tony wrote:

> But with regard to various compile-time stuff and function 
> annotations and other things that didn't exist years ago, has 
> that resulted in noticeably faster programming and/or 
> noticeably higher code quality by those utilizing it?

Yes, though you also can't compare a typical programmer from the 
D world with a typical guy from an enterprisey language world.  
The D guy I am begging please to consider copying memory just 
this once, and guy from a certain different community I am trying 
to encourage to consider using a profiler.  Anyway in one little 
comparison for a market data service some D code I pulled 
together was quite a bit faster than the code written in a 
certain other enterprise language.  D was just storing binary 
blobs and the other one was talking to MongoDB so it's a totally 
unfair comparison.  But what I wrote quickly in a few weeks not 
caring about performance at all and feeling guilty about it was 
2,000x faster than the solution written in a more traditional 
language that took months to write.  And there was almost no 
code, so with the exception of three hairy lines it was much more 
readable and clear.

Of course it's unfair to compare two different back ends, but 
that's also the point - there's a difference in values between 
different communities.  Somebody told me that XYZ company that 
developed his language are the experts and what do I know so I 
will not even think about how it works beneath.  The D programmer 
has a virtue of a different kind (and one must never forget that 
any virtue, taken to the extreme, and out of balance with other 
virtues becomes a vice) - she knows that it's just code and 
whilst uncomfortable in the beginning with persistence one can 
figure it out.  Who the hell do you think you are to write a C 
compiler?  That's still echoing today from the founding moment.

Values are perhaps much more important than features in 
determining whether one should use a modern basically sound 
language.  Is it a problem that if you install the latest DMD on 
windows or Ubuntu it might not work the first time, and it 
definitely won't if you are trying to show someone.

That very much depends.

Are you someone and do you work with people who are put off by 
the first five minutes and indeed repeated encounters with the 
rough around the edges aspects of D?

I was a bit daunted by the bleeding edge reputation of Arch Linux 
so I tried everything else, but when I found it I knew I had come 
home.  For my own workstation, not something to use on critical 
infrastructure of course - though on the whole I would ideally be 
able to adapt to failure rather than try to make sure the 
impossible to prevent never happens.

Nassim Taleb says that something is resilient if it survives 
stress and antifragile if it benefits from stress and disorder.  
Well, sometimes it has been a pain in the neck, but I would by 
far rather deal with regular small infelicities than less 
frequent big ones.

We are in an age of specialisation and resulting fragmentation - 
not just in programming but in many other fields too.  The edge 
in life is always shifting.  In 1998 I was nervous about moving 
to DE Shaw as a trader and an older chap with white hair (we were 
all younger then so Angus was an anomaly) said don't worry - you 
have some technical skills that most people won't have for a 
decade, so if it doesn't work out you will be fine.  And today 
it's the other way around - because I followed my interests I 
ended up knowing enough about quite a few different things where 
the package is not that common.  And yet there's a value in 
knowing the whole picture in one mind that can't be substituted 
for by a committee.

And what's true there is true with other skills too.  So the 
infelicities of D actually serve as a moat to filter for the 
worthy and a training regime to keep you fit.  Taleb talks about 
checking into an expensive hotel where there is a guy in a suit 
paying the bellboy to carry his bags upstairs.  Then an hour 
later he sees the same guy in the gym lifting weights using a 
machine.  And he has a point that to a certain extent it's 
possible to use found challenges to stay fit more than people are 
in the habit of doing today.

There's also a breadth found in the community that used to be the 
norm when I started programming in 1983 but disappeared in the 
years.  In which other community will I have dinner with a naval 
architect and come away with good ideas that I can steal and put 
to good use for what I am doing?

Anyway beyond performance and the specific virtues of programmers 
from the D community (which may well be vices in an environment 
that ought to be based on different values), yes I do think CTFE, 
introspection, sane templates and code generation make a great 
deal of difference to code readability.  There's much less of it 
for a start, and it's easy to understand what it's doing.  Vs a 
real example of a 4k file of copy paste C# wrapping a C native 
code interface.  Microsoft advise using HTML templates for code 
generation - I thought at first surely an April Fool.

And annotations are great, and take a look at how Atila Neves 
uses them for example. People weren't thrilled by them in the 
beginning but it's proven very useful in practice.  The Remedy 
Games talk by Ethan describing their use was very cool.

I think sometimes stress and unhappiness is caused by wanting 
something or someone to be something one is familiar with rather 
than what it intrinsically is.  If you have problems using D at 
work try and figure out a way to solve them.  Or work with others 
to improve things.   But it could well be that it's not the right 
place for it.  Maybe it's not technically a fit, but it could 
well be a question of values - the existing values of the group 
or the values appropriate to the domain the company is working 
within.  Possibly it could be just that we are all very impatient 
these days whereas processes of social change take the time they 
take.

The economist Brynjolfsson has written about this from the 
perspective of organisational architecture.  The PC was quite 
available in 1982 and yet in 1987 Solow, a renowned expert on 
growth said that "computers are everywhere but in the 
productivity statistics".  A decade later people were talking 
about the productivity miracle, and that was because of 
computers.   But why did it take so long?  Well it took computers 
time to mature and what Andy gaveth, Bill kept on taking away.  
However more than anything it was because organisational 
architecture needed to change to truly benefit from new 
technologies.  And we know how much most people like change - it 
takes a while as a result.

D is a very ambitious language.  Therefore it's not surprising it 
develops more slowly, but that does not say much about it's 
eventual destiny.  Lots of things are insignificant nothings in 
the beginning, but some of them become very important indeed.  I 
was writing to someone earlier about the revival in US 
manufacturing that was obvious enough in 2011 based on outlook - 
perception about compound growth is very strange.  Hence the 
phenomenon of the overnight success that took decades.  It wasn't 
an overnight success - just that people weren't paying attention 
and only woke up to it when it passed a threshold of perception.

So things are as they are, and wishing or pretending otherwise 
won't make it different.  But in the meantime the fact that many 
places have values that get in the way of trying something a 
committee hasn't approved is a tragic waste of potential for the 
individual and company involved.  But it's also an opportunity 
because we are hiring in London and Hong Kong and I've never seen 
anything like it.  I do my whole spiel and then it turns out I 
needn't have bothered.  Excellent programmer.  "So I can work 
with intelligent and virtuous people and write D at work?"  Okay. 
  There's an aspect of hyperbole in my telling of it, but not that 
much.

The main market test of D should be not popularity but are people 
using it to get real work done and do they find commercial 
benefits from their choices.  Given a little patience the rest 
will follow.  You only need one leader in each sector to talk 
about it, and over time a few more will try.  There's a process 
of contagion that's slow in thd beginning to human perception and 
then not - the overnight success actually decades in the making.

One can control what one does, but one can't control what others 
think of it.  It's by far better then to focus on making D the 
best language and ecosystem it can be (an intrinsic quality) 
rather than fretting about popularity.  The broader world is just 
slow to catch on, but they do catch on eventually, particularly 
when conditions shift.

Growth in data set sizes meeting CPU manufacturers having some 
different constraints and things to worry about plus stagnation 
in relative memory performance and storage moving to the 
motherboard.  I think recognition of conditions shifting is just 
a matter of time.  I don't think it's a coincidence that Weka,the 
disruptive storage startup, used D successfully or that 
performance-wise they utterly dominated their competition.  
William Gibson said the future is here already, just unevenly 
distributed.  So exotic situations today become quotidian ones 
tomorrow.  Maybe performance mattering just a bit more than it 
used to is part of that.  I don't yet work with big data but even 
on middling data a 2,000x performance improvement attained with 
zero effort or concern about performance - that's okay and does 
make a real difference.