On Monday, 26 August 2013 at 18:33:55 UTC, Zach the Mystic wrote:
On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
I don't agree. I first used D exactly because it is an
"all-rounder". For me built-in UTF support was as important a
factor as native machine code (performance). The reasons why
people would perfer C++ to D are probably habit and
convenience. If you've used C++ for years why should you
bother to learn D? After all, C++ is well established,
well-documented, has loads of libraries, will get you a job
more eaily etc. Language features and performance are
sometimes over-estimated when it comes to analyzing why a
language succeeded. There's convenience, marketing
(propaganda) etc etc.
Also I don't think that performance alone decides whether a
language becomes popular or not. If it were soley down to
performance we wouldn't have Java or Python or even
Objective-C (which used to be criticized for being too slow).
Ease of use, a clear and consistent structure and "write once
run everywhere" are very important too. Especially now that
developers have to face so many different platforms (Linux,
Mac, Windows, Android, iOS) everythnig goes into the direction
of "write once ..." That's one of the reasons why Android took
off, I think, because developers said "Great, maybe this will
put an end to the mobile platform jungle. We'll support
Android, less headaches for us!".
I'm trying to analyze the problem from a strategic point of
view. For this, I like to invoke the Serenity Prayer (please
forgive any distasteful theology):
"God, grant me the serenity to accept the things I cannot
change,
The courage to change the things I can,
And wisdom to know the difference."
So yeah, you can't control people's choices. The question is,
of the things which *can* be done, is it better to focus on
well-roundedness, or to press an advantage where one is already
ahead of the pack? Which will lead to greater adoption of the
language?
One thing about performance in particular is that it's easy to
measure and easy for the naive person to understand what it is.
So there is perhaps a risk of being seduced into sacrificing
other things which are more subtle, but equally important, in
favor of winning at performance. Yet I think the key point is
that that's not going to happen here. I personally have too
much respect for the engineers working on this thing to think
they would be that short-sighted.
But if it's *possible* to grab a performance trophy while still
keeping the other flocks well-fed, it seems like a clear
strategic win.
Yes and no. I've actually given up pointing out language features
or even performance to people. Believe it or not, but usually the
first questions are things like "Does it have libraries? If it
doesn't have a sound library I will not use it ..." And if
someone is a die-hard D-hater s/he will always find something
like "D doesn't support multi-sync-runtime-polymorphy on reversed
backtracking array slicing, so it's useless! C# will have it
soon!"
I think being an all-rounder is a good approach, you can use it
for small script-like projects and big projects with unit tests,
component programming etc. So as people ask about features, you
just keep ticking the boxes. But if you start to point out one
feature in particular, you're going down the slippery road of
bit-by-bit language comparison, which will lead you nowhere.
I think it would help a lot if we had a "Made with D" list,
especially if there are some killer apps or games and the like.
