Michael: 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... Erlang? 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 solving problems? Will type signatures appear as pain or a valuable thing to them? -- Leonel Fonseca.