I'm glad you enjoyed the discussion.
I'm reading over all of your comments, and I see many great points being made.
One that I'd like to deposit for your consideration. Haskell is an ideal language _in certain contexts_. For some people, those contexts are important enough to learn an entirely new language. Highly parallel programs may be one such context, where the
safety moving wholesale to Haskell brings is worth the cost of switching. Even if that were true, _most_ .NET developers are not currently salivating for parallelism. In 5 years? Maybe. But not today. So as a broad blanket statement, it is safe to say
that the perceived cost of switching to Haskell is far higher than the perceived benefit for the bulk of the development community. This is why an incemental, move-select-parts-of-your-program-over-to-the-safe-world-piecemeal, strategy is so attractive.
In addition to that, I mentioned in the video that Haskell is not a panacea. It has many interesting ideas, but some that I consider to be debatable for the .NET community at large. Algebraic data types mixed with structural pattern matching -- with type
classes for polymorphism -- are useful for a certain class of programming, but telling a whole community of object-oriented developers to switch overnight will not only result in religious clashes, but is probably just plain wrong anyway. There is a plethora
of shared knowledge (e.g., in patterns -- see GoF), collateral (books, articles, training), and frameworks that Windows developers rely on each day, which are strongly tied to the C++-family of languages. Moreover, I don't believe vanilla Haskell (98) has
solved _all_ of the problems associated with composition of separate agents that are performing I/O. The "one top-level I/O loop" style of programming doesn't scale beyond one coarse-grained agent. For that, something more like Occam or Erlang is neeeded,
and this is crucial to address in order to enable composition of fine-grain with coarse-grain concurrency.
Food for thought, I hope.