Indicators and traction…

[Joakim via Digitalmars-d]

On Wednesday, 23 September 2015 at 23:00:29 UTC, Laeeth Isharc 
wrote:
> 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 agree that D may not be ready for a large influx of new users, 
but that is a cyclic process that is necessary for growth, ie 10k 
new users come in, 5k go away because they run into issues, 5k 
stick around and a few pitch in to make things better.  A killer 
app is a way to get a lot of attention and potential new users 
quickly, but nobody's saying that alone is enough.  But it is one 
way to add to the userbase that might lead to more growth and 
more killer apps and libraries later.

Rails led to a lot of new ruby users, some of whom found flaws 
with the language and left.  Others worked on alternate 
implementations and improvements.

> What could be done to make its benefits on the server clearer?  
> One obvious thing is better documentation and more blog posts.

Same as always, publicizing the server successes it has had and 
blog posts comparing D and benchmarking vibe.d against other 
popular web languages and frameworks.  Some on the forums have 
suggested getting vibe.d in this apparently popular web benchmark:

https://www.techempower.com/benchmarks/

More D libraries aimed at use on the server, that make getting up 
and running there easier, along with posts publicizing them.  I 
thought this was an interesting snippet from a recent blog post, 
highlighting the importance of such marketing:

"What we never know is how quickly diffusion happens. I’ve 
observed 'no-brainer' technologies or ideas lie unadopted for 
decades, languishing in perpetual indifference and suddenly, with 
no apparent cause, flip into ubiquity and inevitability at a 
vicious rate of adoption.

Watching this phenomenon for most of my life, I developed a 
theory of causation. This theory is that for adoption to 
accelerate there has to be a combination of conformability to the 
adopter’s manifest needs (the pull) combined with a concerted 
collaboration of producers to promote the solution (the push). 
Absent either pull or push, adoption of even the brightest and 
most self-evident ideas drags on."
http://www.asymco.com/2015/09/21/how-quickly-will-ads-disappear/

>> 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).

Since the D frontend and druntime/phobos are boost-licensed and 
at least ldc is mostly BSD-licensed, it is certainly allowed to 
integrate proprietary fixes and additions with some of the D 
compilers and the standard library.  This could be the basis for 
a paid toolchain, as I've pointed out before.  llvm/clang 
certainly started out as such a project and is part of a big 
business today, with proprietary additions.

On a related note, I feel like Microsoft is really missing the 
boat here, especially when reading Manu and Walter on why llvm 
doesn't support MS debuginfo:

"I've actually had quite a few conversations with LLVM dev's about
this, and one of the key excuses for not supporting MS debuginfo 
was
the classic 'it's not documented.' I promptly pointed them at your
work every single time it came up, but they ignored or dismissed 
it
every time. Dev's are funny like that."
http://forum.dlang.org/post/mailman.80.1439216033.13986.digitalmars-d@puremagic.com

The problem for Microsoft is that all new languages are using 
llvm to generate code.  If that code cannot be debugged on 
Windows not only because they don't provide any open source way 
to integrate such languages with their platform but _do not even 
bother to document_ their debuginfo format, so the only way it 
gets supported is if Walter reverse-engineers it, there go all 
those potential Windows developers.  By contrast, the two major 
OS platforms of the last decade, iOS and Android, have toolchains 
that are almost completely or completely open-source.  This means 
random people on the internet, like Dan and me, have been able to 
get D mostly working on those platforms, with much less work.

Microsoft wouldn't even have to open source everything in their 
toolchain, just the parts that would make it easy for other 
languages to integrate.  Or at least document your damn debug 
format!  Maybe Microsoft thinks their in-house languages are much 
better, but even if that's true, you're missing out on all the 
devs using those outside languages.

Of course, part of this, which goes unmentioned by Manu, is that 
the llvm devs likely work for Apple and aren't incented to 
support Microsoft.  But there's nothing stopping Microsoft from 
contributing to llvm or just documenting the format.  They've 
been doing some stuff with llvm lately, so maybe things are 
changing, but this is a clear win that is likely much more 
important:

http://blog.llvm.org/2015/04/llilc-llvm-based-compiler-for-dotnet.html
http://blogs.msdn.com/b/vcblog/archive/2015/05/01/bringing-clang-to-windows.aspx

In that second link, they actually note "debugging-friendly 
code-generation" as a benefit of using the VC++ backend.  I'm 
sorry, if you have to refrain from documenting your format in 
order to help your backend, you've already lost.