On Monday, 16 March 2015 at 09:31:17 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote:
We invariably end up talking about language features and
syntax, as if D lost out against Go, because of feature X
being (or not being) there. We lose, because we fail to give
people that warm glow in their chests. The feeling of "now I
have something", which is basically what makes people go for
something. I felt like this about D when I first got to know
it, after a long period of being frustrated with every other
language. Although irrational, my intuition was that D would
offer me a lot, and it hasn't failed to do so. But this is,
because I was willing to make an effort. Many potential users
are either not willing to make an effort or they don't have
enough time. So we should make it as easy as possible for them.
Makes a lot of sense. But…
As was said in a post earlier, the decision to go for language
X is often not 100% rational, but also based on subjective
positive feelings. To ignore this basic human fact, doesn't
help us. Having a great language with advanced features and
doing some "feel good" marketing are not mutually exclusive.
This is true, but D's main problem isn't that people haven't
come to D with high expectations of getting a better
alternative to C++. The problem is that they came for emotional
reasons and left for rational reasons.
This is an interesting assertion, and you have been around here
much longer than me. Of course the above must be generally true
of any language (since one develops a better sense for what it is
like by using it for a while), and I suppose it is also true that
people who stick with D stick for more informed reasons. Are
there reasons to be concerned that the right kind of people don't
stick with D, given that it is still maturing as a language, that
not everyone can use it at work, and that there are many options
available now, so a degree of churn is normal. A language will
be successful by starting with a very high appeal to a certain
group, rather than a modest appeal to everyone.
They key is in understanding why people leave. Retention of the
_target audience_ is more important than adoption rate.
Okay, but target audience is an emergent more than a centrally
planned property, although one can remove the obvious roadblocks
for certain important groups.
It seems that many of those that stays with D either picked it
for a hobby, or are not primarily programmers (I am not really
sure why they pick D? Does not seem like a rational choice.),
then a very small (and vocal) group use it for business.
I don't know if true without the data (is it worth trying a
questionnaire on the download page) but supposing it is true is
this surprising given it is not yet standard in the enterprise,
and most firms are conservative? Surely most languages get their
start in this way. It is a rational choice for people in this
camp because native code, and who wants to deal with C++. (And
I love C, but...)
In my opinion you need to pick a target audience, and with the
CTFE focus targeting professional system level programmers is
the only thing that makes sense. D needs to deliver on all
aspects that C++ is good at before it is marketable, or else it
will stay a hobby language for professionals and others. That
means matching C++ on stability too.
See Innovator's Dilemma and Peter Thiel's work. It needs to have
a monopoly of appeal to certain groups, and as it develops spread
out from there. I don't see the link between CTFE and systems
level programming.
If it is more work to implement smart pointers in D than in
C++, then there are some fundamentally unacceptable limits in
the core language. So it is not only marketing... D is not
complete.
D needs a redesign to get away from lock-the-world GC without
scars... A language redesign that cannot be done with "last
minute patches of special casing hell".
I don't claim to understand the topic well enough, but it looks
to me like a relative resource question combined with a desire to
do things elegantly (which takes longer even though it is the
right way) not a fundamental design question.
Over focusing on growing the user base by making tutorials,
will only make changes harder, and it will attract the wrong
kind of people that will ask for the non-system-level features
making it even harder to improve the core language.
Why grow the user base before the language is done? You end up
with no target audience, a very fragmented user base and
equally fragmented eco system. Fragmentation makes it harder to
produce professional level things.
That's one reason saying "D hasn't gone anywhere, so it won't"
seems a misdiagnosis. It wouldn't have been possible/ the cost
would have been higher to move to D2 with a much larger installed
base (look at Python), and the language previously perhaps wasn't
ready for prime time. There is a lot of FUD from this talk of D
not being finished - it seems like it's more than finished enough
to do good work in many domains. I appreciate for realtime the
GC is a problem, but that surely isn't a majority of use cases
and can be worked around (viz Sociomantic). I almost was put off
by the complaining (which goes back a decade and is to be
expected where people really do care), but am glad I pressed
ahead.
I am not sure what more non-system level users would ask for as
_language_ features, nor what would lead to fragmentation rather
than diversity in the user base. The forums will suffer in
signal:noise at some point, which is a natural cost of growth,
and this would need to be dealt with thoughtfully, but that is a
good kind of problem to have. I really don't see how tutorials
will hurt the language, because it will bring in more users with
resources, and that will also help in the longer run.
D cannot be centrally planned, so one must be careful in speaking
of target audience - especially when one cannot know in advance
about who will stumble across it and find it useful.
It is also completely misguided to push D as a web dev
platform. D is up against: Ruby, Python, Dart, node.js+angular,
Java, Go etc in an environment where performance is mostly
about networking, database/ORM integration and infrastructure
AWS/Azure/Google... D is nowhere near being a plausible
solution in this space, CTFE is essentially pointless in this
domain.
That covers a multitude of use cases, and I am not sure that
every one of these requires more of those things you mention than
are currently available. Ruppe uses it for web development, I
think. It seems rather defeatist to suggest that because one
lacks features in certain domains one should just not even try to
develop them, although I can understand the frustration.
