Indicators and traction…

Laeeth Isharc via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 23 16:00:28 PDT 2015


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.



More information about the Digitalmars-d mailing list