Blocking points for further D adoption

[Laeeth Isharc via Digitalmars-d]

On Saturday, 4 June 2016 at 13:18:02 UTC, Artem Tarasov wrote:
> The largest blocking point to me is the community attitude. D 
> constantly wants to 'rule them all' instead of integrating with 
> other language ecosystems. This only recently started to 
> change, but only towards C/C++ and not in the other direction, 
> which is dynamic languages.

PyD is not a recent project.  Nor is LuaD.  Or bachmeier's work 
on R integration.

> PyD is only barely alive
Really?  You have submitted pull requests and nobody has looked 
at them ?  Seemed alive enough to me when I looked a few months 
back.  It's normal activity diminishes as a project reaches 
maturity.  What is it you think PyD should do that it doesn't 
today, and what was the response when you raised it with the 
maintainer ?  Was it just about distribution of packages?
>
> I'm speaking here from a researcher's perspective. One must 
> realize that in our universe, there is often no time to learn 
> yet another language, so people consolidate around Python so 
> that everyone stays productive, and this situation will not 
> change until someone rolls out a complete replacement for 
> numpy, scipy, pandas, and scikit-learn at the very least.


Adoption doesn't work like that.  If nobody ever switched until 
the next thing was perfect, nobody would ever switch.  What 
happens is something new gets adopted in certain niches by people 
who really like what it has to offer and don't mind the rest and 
who have the power to do so.  Then as it starts to be adopted in 
some niches, it spreads to adjacent niches.

If you would like to help with dlangscience I am sure John Colvin 
and colleagues would appreciate the manpower or support in other 
ways.  If you're not in a position to help, then I understand 
that, but grumbling won't change much because open source 
projects are constrained by the supply of able people willing to 
roll up their sleeves and help.

  (and
> that won't happen any time soon) A fancy custom Jupyter kernel 
> is nice but often half-baked and not really necessary. But 
> solving distribution of shared libraries is a must if you 
> (still) want to become a C++ replacement.

What a great opportunity to give something back!  Why not sketch 
out a vision for what this should look like, as John has done 
with dlangscience.


To me it seems that D currently has a unique advantage of being
> able to easily generate in compile time all the boilerplate 
> binding code that everybody hates to write in C++ (or if one 
> uses boost::python, hates to wait to compile). Combine that 
> with the fact that many are terrified of C/C++ insomuch that 
> Cython was invented, and D offers a much nicer language with GC 
> for those who don't want to even know about memory management. 
> Research people would love this, but only if it's a 
> production-ready solution that needs no extra time investment.

Yes it has a unique advantage.  But it isn't realistic to expect 
others to do the work for you at this stage in the development of 
the ecosystem...