On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim
Grøstad wrote:
This logic is very difficult to follow. Software project
management is often done by people who are programmers. From a
project health point of view D2 suffers from the same issues as
C++, the language feature set makes it easy to create a mess,
and therefore the demands of investments in the development
process gets higher.
You can create a mess in any language. Having written significant
amounts of D code, I can tell you that D is very good at avoiding
a mess.
This aspect is one significant reason for why languages like Go
and Java are getting traction.
Which confirms what I've observed. People prefer set menus, rules
and strict guidelines - and D seems not to appeal to them due to
the lack of an ideology.
Geeks have no trouble picking up new languages, C++ programmers
most certainly will have no trouble picking up D. The semantics
are too close, but D2 does not solve C++'s issues, and brings
another set of issues that C++ does not have. This is not a
fear issue. It relates directly to qualitative issues.
This is not my impression. Even "geeks" don't touch D (I know
this from personal experience), even when there's no risk
involved, e.g. when writing a small internal tool. As soon as
they hear they have to learn about ranges and map!(a =>
to!string(a)) and the like, they lose interest. Fear or plain
laziness ("couldn't be ar*sed"), one of the two. "I certainly
won't learn D" is a comment I've heard myself.
Projecting "fear" onto professional decision making is just a
way to make excuses for D's shortcomings.
The shortcomings D has wouldn't even interest the majority of
those who reject D. They wouldn't get deep enough in their daily
tasks to find out.
Sun was a big player in IBM's core market and the Java design
was very orthodox. Risk is certainly the single most important
factor for avoiding change. If you change your core toolset you
also will have to change the process and infrastructure.
You've said it again. Java's design is orthodox, so IBM embraced
it. Again, people prefer simple set menus, rules and strict
guidelines. It's more of a psychological thing than objective
risk aversion.
You are assuming that technologists have timid attitudes
towards playing with new technologies. That is not true. Most
technologists I know of find that fun. Adopting tech for your
personal use or for small tools is one thing, adopting it for
deployment is a completely different issue.
See my answer above about "geeks".
What tools can D successfully replace? Give a focused answer to
that and you can improve on D to a level where it becomes
attractive.
One example that come immediately to mind is data processing in
Python. A lot of it is parsing and counting which is much faster
and often easier to do in D/Phobos.
But keep it real. Fear among programmers is not D's main issue.
I think it is. It took me a while to realize this. Why is there
this passionate hostility towards D? I don't go to a Go or Rust
forum to tell them that I don't like this or that feature and
that it's all crap. I've decided they're not the right tools for
what I need and that's it.
That's just an excuse.
