Hi. I take the risk to mention some facts you might already be working on.
I speculate on three perceptions in the mind of decision makers
related to the adoption of a new language in a shop.
This perceptions can be modified in stages.
First Stage: Awareness. Why programming in that language matters?
Once you can justified this, advance to the following stage.
Haskell is nice, quick to develop, brings tools to make abstractions
at any level and has tools and libraries.
And community support is really awesome!
If you invest more in learning, you can strive to use it as formal
programming method and earn safety guarantees.
Please, see elsewere for success stories that help you to motivate and
encourage management to test the new alternative.
Second Stage: Small term engagment.
Why your shop should do little investment in trying a new language in
a small but representative project?
Here you can make two arguments to gain support in this stage:
2.A) The shortcommings of the current tools/languages.
2.B) Small concept programs of how your current language/tool would
fail where the new one would success.
You can gain credibility by showing how your new tool could
be short on some aspect that it's well mastered in the old one.
(i.e. be impartial).
Someone has already pointed how fragile interpreted programs are.
In this stage you must gain both decision makers and peers recognition
of the problem the shop is facing with the current language versus the
improvements of using the new language.
A project must be acomplished and reviewed, so a decision can be made
over the facts of costs and benefits.
Third Stage: Adoption.
Is it really better to adopt a new language?
At this point you have evidence of possible benefits and costs. And a
decision is made.
Among other costs, please take in account that embracing any new
language in a shop will require formalised (funded, time alloted to,
machines, any other resource) learning and coaching activities.
Haskell has long learning curve. And you must consider this cost of
being less productive than in your current language.
There's too the risk of hitting walls in a tight-schedule situation.
You can lower this risk of failure if you arrange to have a mentor
(master) who can lead, provide hints to co-workers, discuss approaches
and solve hard issues whenever they appear.
Counter-arguments that you must deal with:
c1) Why not...
F#? See Jon Harrop's claims.
Scala or Clojure?
c2) Performance predictability.
c3) On the fly script generation and execution.
c4) Will your co-workers be happy of embracing a new paradigm of
Will type signatures appear as pain or a valuable thing to them?