On Wednesday, 23 September 2015 at 19:40:33 UTC, Nick Sabalausky wrote:
>> That's true, although D1 had a more active library producing community?
>
> Hmm, that's not the impression I get (aside from Tango which was a pretty large effort).

Yeah, I don't remember that large of a community back in those days either. Maybe it was more centralized but I never got the impression that it was bigger. And there was the whole phobos vs tango thing too.

On Wednesday, 23 September 2015 at 18:57:21 UTC, Ola Fosheim Grostad wrote:
>
>> Except D2's already surpassed D1 :)
>
> That's true, although D1 had a more active library producing community?

I think it was way worse than today, because of the Tango/Phobos split, few people using DSSS, or "bud", or other build tools.

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.

On Wednesday, 23 September 2015 at 16:13:37 UTC, Nick Sabalausky wrote:
> On 09/23/2015 11:45 AM, John Colvin wrote:
>>
>> I think you're misinterpreting some of these people. Some will be
>> following fashions, but many will be simply not wanting to put time and
>> effort in to something that they're not convinced is going to work out
>> in the long run.
>
> That amounts to the same thing, just indirectly: It's a myopic approach that involves a failure to understand the basic dynamics of plain old self-fulfilling prophecies:
>
> "Things succeed/fail BECAUSE people LIKE ME use it or pass on it. Therefore, we should make that choice based on whether it's WORTHY. Because if instead, we base it on whether we think OTHER people will/won't use it (ESPECIALLY if THOSE people are ALSO going to be choosing based on the same 'what is everyone else going to pick?' crystal ball), then we're all chasing each other's tails and the result boils down to randomness (at best) or more likely, becomes predominantly influenced by superficial factors and biased parties."
>
> It's a very, very basic line of logic, especially for people in a profession that's so fundamentally rooted in exactly such logical reasoning.


Not everyone has your abilities, Nick.  You probably underestimate what it's like not to have them.  (Knowing about Dunning Kruger doesn't make it go away).  Many people oughtn't to try and pick the best framework because they don't have the discernment to do so.  And for others they simply don't have the time given the situation they're in.  Making decisions based on social factors isn't my cup of tea, but you can't really blame people for it.  Life is from an ideal in many ways.

But not everyone is like that or has such constraints, and it is those that one must appeal to.

On Wednesday, 23 September 2015 at 16:22:02 UTC, Nick Sabalausky wrote:
[snip[
>
> FWIW, Python hit pretty big success with a different approach: Appeal to people's innate desire for instant gratification. By the time they discover the downsides, they're already knee-deep. (Obviously I'm not suggesting this was intentional, just seems to be the way it played out.)

Instant gratification in Python == 10x more productive in Python. This is why Python succeeds.

D can compete in this market using dub and rdmd. D can also compete in the Java/C#/C/C++ markets, a place where Python often falls short.

bye,
lobo

On 23-Sep-2015 19:22, Nick Sabalausky wrote:
> On 09/23/2015 11:47 AM, Chris wrote:
>>
>> a) billions of dollars:
>>     big corporations (cf. Go) and the Java/C++/C# industry that makes
>> millions selling training courses and books etc.
>> b) the general inertia and herd behavior of people, and to make the herd
>> move you need a)
>>
>
> FWIW, Python hit pretty big success with a different approach: Appeal to
> people's innate desire for instant gratification. By the time they
> discover the downsides, they're already knee-deep. (Obviously I'm not
> suggesting this was intentional, just seems to be the way it played out.)

Working with Python codebase ATM I can't agree more :)
Of course, that is just my biased opinion.

> I'm not making any suggestions or drawing conclusions from that, I just
> think it's relevant and worth being aware of.
>


-- 
Dmitry Olshansky

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.

On Wednesday, 23 September 2015 at 23:00:29 UTC, Laeeth Isharc wrote:
> On Wednesday, 23 September 2015 at 16:22:35 UTC, Joakim wrote:
>>
>> 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 agree. Conventional marketing won't get us far at this stage.

[snip - to which I agree]

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

Thank you. Nicely put. Mind you, a lot of complaints are not related to the language itself (as others have said), but are secondary issues like IDEs (one-click-debug-compile-run-deploy-go-for-coffee-magic) and libraries, which are logically a step you take _after_ a language has been created. And it is true, doing what people tell you to do won't necessarily change their minds. They will find something else to complain about - like those nasty neighbors that tell you to cut the grass, then to trim the hedges, then to sweep the footpath etc. Let the grass grow!

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

These things do make a difference. At least for the Python crowd. But be prepared that people might attack you saying that with C++ it would be 10-20% faster than D, because D has GC blah blah blah.

The amount of random criticism that is thrown at D, confirms, imo, that it is really good, else people wouldn't bother to attack it so passionately. Only really good creations are attacked with a passion - be it in art or technology.

On Thursday, 24 September 2015 at 09:38:16 UTC, Joakim wrote:
> 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:

btw, Walter wrote up a nice article in 2012 laying out all he had to go through to get dmd working on Win64:

http://www.drdobbs.com/cpp/porting-the-d-compiler-to-win64/240144208

No wonder Windows is a dying platform, given what he laid out there.

On 24-Sep-2015 13:51, Joakim wrote:
> On Thursday, 24 September 2015 at 09:38:16 UTC, Joakim wrote:
>> 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:
>
> btw, Walter wrote up a nice article in 2012 laying out all he had to go
> through to get dmd working on Win64:
>
> http://www.drdobbs.com/cpp/porting-the-d-compiler-to-win64/240144208
>


> No wonder Windows is a dying platform, given what he laid out there.

Much as I'd like that to be true, the opposite might be the current situation. See all the new shiny and dead-simple APIs or Windows 10 Universal Apps ...

And you know where most developers flow - like watter - where it's easiest to pass.

-- 
Dmitry Olshansky