[Haskell-cafe] A backhanded compliment and a dilemma

[Joachim Durchholz]

Am 20.10.2016 um 09:32 schrieb Imants Cekusins:
>>  the "choose" group has to take the rest of the chain into account
>
> Choosers rarely consult and listen to the other groups even when those
> other groups are present and voice their preferences.

They consult with their architects if they have no personal expertise.
If they have personal expertise, they usually *are* the architects.

Architects tend to stick with established technology because switching 
is costly (loss of productivity because programmers have to relearn, 
loss of codebase that's incompatible with the new ecosystem, loss of 
tool integration that needs to be prepared for the new ecosystem, loss 
of programmer time who need to rewrite stuff), *plus* it is risky 
because nobody can guarantee that you will ever recoup the losses, let 
alone gain an edge.

Just do the math: assuming a developer-year costs USD 100,000 (not too 
absurd in Western countries though there are obviously differences), a 
team of ten developers working for a year to embark on a new language is 
a full million dollars that needs to amortize.
And you need to guarantee that the transition is done after a year, and 
that programmers will be more productive by 50%, and then it is still 
three years until that expense is amortized.
You simply don't do that. You cannot (or at least should not) bet your 
company's existence on that kind of stuff, particularly if those 
guarantees are not available.
In practice, drastic coding infrastructure changes tend to take decades. 
Large businesses (i.e. those who have the money to actually experiment 
with disruptive stuff) are currently in the process of migrating their 
applications from mainframes to webservices, and the typical timescale 
for that is in years, sometimes decades, even for them.

Things change if you get a guarantee. If a competitor is able to make 
their business processes substantially more flexible, then there you 
have your guarantee, and then you'll find the employers who are willing 
to use^Wtry that disruptive technology.
Webservices and enterprise buses were such changes, for example - and 
they are still migrating.

 > Job ads where
> employer is open to suggestions about the language are not common.

Well, changing the language in a running business process is a 
high-risk, dubious-reward proposition.
You will have a hard time convincing anybody of trying that out.

> If the same group and people within that group did all the stages:
> choose, begin, complete, maintain, they'd make a more balanced decision.

Talking as somebody who has seen both sides of the fence, I can say that 
these decisions cannot be made "more balanced".
You have to balance risk against reward, all while taking constraints 
like developer availability, in-house ability to actually make use of 
the advantages, retraining costs and overall profitability into account.

Going just by qualities of the language would be the unbalanced 
decision, I'd say.