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.