On Saturday, 26 September 2015 at 22:19:41 UTC, Laeeth Isharc
wrote:
In practice, life is risk, and sometimes you have to take
calculated risks to advance - this is true whether or not we
acknowledge it to ourselves. Some people shouldn't even think
about using D at work, but that tradeoff depends on their
particular situation, what they want to achieve, and what their
alternatives are. You speak in a blanket way, as if you're in
a position to know what's right for others.
I am not doing consulting on a forum, I am arguing against the
viewpoint that the lack of adoption of fringe tools is a result
of unjustified fear. I wouldn't make any blanket statement for a
business in any shape or form without talking with them to
understand their situation. I don't know why you think I am doing
consulting here.
But risk management is at the core of software engineering. That
is because there are many unknown factors during development, but
you have to set the trajectory at an early stage, which includes
picking the development environment. Software process/methods
maturity is often quantified in "repeat success". That is, not
that you have one success, but keep repeating the success over
many projects.
attempt to use irrelevant factors to undermine your prestige.
There is no prestige involved. But you seem to assume that
whatever holds for your field translates well to other fields.
That is most likely not true. If I started arguing about hedge
fund managment like you do about programming and engineering you
would most likely find it tiresome.
I've majored in human factors/software engineering, taught it to
students and been with a research group where many focused on
using Latour's actor network theory for understanding
organizations and systems development processes. Software
engineering is not a fun or easy topic to teach and also not
suitable for forum debates unless people have the same background.
This is my key point: People are not avoiding fringe tools
because they are afraid of progress. Geeks are quite happy to use
fringe tools in their spare time or for smaller parts of bigger
projects.
Managers should avoid using unsupported fringe tools for larger
long running projects, for many reasons. The big players have
many more options, it means you are more likely able to move and
make changes later on in the project. Like adopting new platforms
such as ARM, asm.js etc. With a tool like D you have to be
prepared to take custody of the compiler/runtime to get the same
flexibility.
You pick a solution for a project, not a language.
