> You can even see it in code examples where it is pretty common to see arbitrary one-letter variable names. This is usually because Haskell functions are real

> You can even see it in code examples where it is pretty common to see arbitrary one-letter variable names. This is usually because Haskell functions are really short. For example: compose f g x = f (g x) We could write this with more descriptive variable names, but there are only 3 variables and they're only in scope for one very tiny line: compose outerFunction innerFunction argumentForInnerFunction = outerFunction (innerFunction argumentForInnerFunction) There are certain conventions as well; if a variable must be present, but isn't used, it gets called `_`: first (x, _) = x Lists tend to get a plural "s" on their name: elem x xs = any (map (x ==) xs) > So when the Haskell people try to explain monads, they start with the abstract definition, the monadic laws and so on, and they focus on explaining the concept of a monad, rather than what they are practially useful for. For the typical developer this might seem like a lot of mathematical wanking for little benefit. This is because functional programmers tends to spend the most time on writing generic, abstract, re-usable libraries. Particular applications are just thin veneers on top of these libraries. For example, I might spend most of my time writing generic, abstract code to deal with tuples. To make an application, I can just pick and choose the library code I want to use: type Name = String type Address = String type Quantity = Int type OrderID = Int type SKU = Int type Customer = Tuple Name Address type Order = [Tuple SKU Quantity] type Invoice = Tuple Customer Order Given that I'm using Tuples for Orders, Invoices and Customers, the time I spent writing abstract code to deal with tuples wasn't "a lot of mathematical wanking for little benefit". The time spent writing generic, abstract monad libraries isn't wasted either; by picking and choosing which monads to use, our application can automatically get error-handing, non-determinism, backtracking, exceptions, state, software transactional memory, etc.