On Wednesday, 23 September 2015 at 16:22:35 UTC, Joakim wrote:
Most developers are either not interested in choosing their own
tools, or know they're not smart enough to do so. Instead,
they rely on the same mechanism as most consumers, social
proof, ie do what everybody else in your field is doing:
https://en.wikipedia.org/wiki/Social_proof
D is still in the innovators and early adopters stage of the
tech adoption lifecycle:
https://en.wikipedia.org/wiki/Technology_adoption_lifecycle
To break out to an early majority, D will have to prove itself,
ie the innovators and early adopters have to show empirically
that it is working better for them and allowing them to do more.
I think you are spot on.
I have noticed that people (not just in technology) often have a
heuristic about how ideas spread that isn't consistent with how
this actually tends to work in human society. Not so surprising,
because for most people there is no consequence to having a
mistaken view.
Ideas don't spread in a democratic fashion. The drivers of their
diffusion seem to be profoundly inegalitarian, as that highly
talented but utterly 'incorrect' (politically) thinker Vilfredo
Pareto observed.
Modern research finds the same thing:
http://phys.org/news/2011-07-minority-scientists-ideas.html
And of course the Geoffrey Moore stuff you allude to and I have
mentioned here before. Christensen's Innovator's Dilemma is
extremely important here. (Sociomantic guy - I think Don -
posted here a while back to agree with me, fwiw). If you're a
disruptive technology you don't win by taking on the dominant
force head on - that's a silly fight to pick, and you won't win.
You win it by having a high appeal to a small group of people,
and then you use the energy from that to break into adjacent
niches. That's how the Japanese car markers (originally
motorbikes/mopeds) went from making cheap, embarrassing cars to
posing an existential threat to the American auto industry (for
some years).
D isn't cheap or embarrassing, but polish (particularly
superficial polish) isn't today its strongest point. (It's a
much higher quality product than it appears). That will need to
be improved in time, but it doesn't need to be perfect today for
it to keep growing. It would be better to focus on developing
its appeal to people who already use it but want to use it more,
and people who are on the brink but held back by little things.
Please your best customers or those that like you already, or
those that are desperate to like you because you can be a
solution to their pain.
The naysayers are irrelevant, because you will always have people
that will tell you you are going to fail, and most likely doing
what they say you should do won't actually change their minds. I
can understand how tiring it is to deal with error messages (I
was talking about this to someone the other day), but mostly it's
easier with time, and someone that doesn't persist very long
unlikely would be a core customer at this particular stage of
development. One's priorities can't be set by who complains
loudest.
One way to do this would be to talk to those that use D and see
what the obstacles are to wider use for them. (The forum is a
tiny proportion of the user base and isn't representative). No
doubt that's already on Andrei's agenda. Probably one won't be
surprised, but one might be. Also collecting and polishing a set
of user stories, so the benefit can be made more compelling to
others currently on the fence about adopting.
This is why I keep saying D needs a killer app to break out and
garner attention so it spreads wider. An example would be how
the success of Whatsapp brought more attention to Erlang.
Barring that, a bunch of nice libraries on dub that get
attention might work too. One is a home run, the other is a
bunch of singles, to use a baseball analogy.
Andrei is right though. Success/responsibility is thrust on
those who have earned it, whether they like it or not - D will
succeed in a broader domain when it is ready for it, whenever
that may be. I don't know if focusing on trying to produce a
killer app (not that I suggest you suggest that) will produce the
desired result, since it's trying to short-cut a process that is
essentially organic. Too large an influx of new arrivals before
you are ready for them (docs, libraries, etc) isn't necessarily
only positive. If you are going to host the Olympics, it's a
good idea to make sure the street signs are up first.
Of course often much better to visit a place before a massive
influx of tourists or permanent overseas residents.
I plan to be using some of the work I have built in D over the
past while in production soon enough. Who knows what that might
lead to down the line? Perhaps my perception of what D can offer
me is something idiosyncratic, but often enough I have had the
experience of just seeing things a bit earlier. Datasets grow
much faster than memory speed/computing power, and if python
isn't enough for me today, maybe others will experience the same
in coming years. Is Facebook and their assessment of the
productivity/efficiency tradeoff a monstrous edge case, or
William Gibson's future here now but unevenly distributed?
Probably a bit of both, but I am willing to bet more the latter
than people think.
When it takes a very smart friend of mine at a big wall street
house known for being not bad in technology an hour to run an
analysis that takes me a few minutes using dmd debug and without
bothering to optimize and it took me a few hours to write and
having to wait for results is holding back his strategy (20% of
it is based on this, which he copied from me after Deutsche Bank
sneakily wrote up a white paper on it) - I think I can say that D
has been a smart choice for me so far. Probably others will find
that in time, but humans take time to respond to changed
conditions. There's an extensive literature on organisational
architecture - see Brynjolfsson's work.
Compare the documentation and web site to a couple of years back
- so much better. These things take time, but we are so much in
a hurry when sometimes that doesn't make it go faster.
I'm hoping that once D is on mobile, it will prove fertile
terrain and flourish there. I think more could be done to
publicize it as a good language on the server, that scales well
and is much easier to develop with.
Your work on that is surely very important. Once it's stable on
Android ARM, I suppose it will take a little time for toolkits to
be ported. What could be done to make its benefits on the server
clearer? One obvious thing is better documentation and more blog
posts.
There will need to be a paid toolchain at some point, to spur
more development and more manpower on sanding down the rough
edges of the tools. That's a chicken-and-egg situation right
now, as there might not be enough devs and businesses making
money off D to pay for such tools yet.
Hobby/open-source project today, business tomorrow? Who would
wish to bet against that happening with some of the free tool
sets that are already here? (And that would be something to be
welcomed).
Laeeth.
