The Virtus issue is simply an example of bad design. When you add magic that can't be guaranteed by the language, you're eventually going to run into problems. Just look at Hibernate.

As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry.

And advanced type systems are not unique to functional languages.

I'm also not clear on why the example testing code is better. It doesn't look much different from what I'd write in any language (excepting boilerplate).

So yeah, correctness and testability. It's available in most languages.

Also, what's up with all the single-letter variable names?

> Also, what's up with all the single-letter variable names?

Words are not useful if your variables don't really have semantically meaningful names. Also, if your code is a simple one-liner, it does not really add too much benefit to name everything, if it is obvious from the (very local) context.

For example, when I look at something like:

    ordered (x:y:xs) = x <= y && ordered (y:xs)

    ordered (first:second:remainingList) = first <= second && ordered (second:remainingList)

Then why did you call your variables x and y, and not y and x? Surprise: because there IS a semantic meaning to the order.

The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope.

I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)

As a counterargument: Haxl at Facebook. https://github.com/facebook/Haxl

The convention isn't terrible, it's just a convention and takes a bit to get used to. The (x:y:xs) pattern is useful for when you could at best describe x and y as thing1 and thing2 and xs as theRestOfTheThings. Since the extra letters add no real clarity it's not a bad way to keep things concise. Once you get used to the pattern it's better because if you see (x:y:xs) you know that the things themselves are less important than their order out of an array.