It's not supposed to be good procedural code, it's supposed to be illustrative of the fact that a lot of code which people are used to seeing in procedural lang

It's not supposed to be good procedural code, it's supposed to be illustrative of the fact that a lot of code which people are used to seeing in procedural languages, which only involves assigning to a variable once, can be translated into a pure haskell function very straightforwardly, and it doesn't look intimidatingly esoteric like many people seem to expect. I can just as easily do it with strings if you're concerned about it being mathematical. I agree that there are many problems more naturally represented by procedural code, and as such it's important for every language, even functional languages, to have good constructs for representing a series of steps. Luckily, Haskell has such a construct in do notation. It looks like this: main = do putStrLn "What's your name" name <- getLine putStrLn ("Hello, " ++ name) I'm not familiar with MongoDB, but I found a haskell library for that and the example looks relatively straightforward to me, modulo possibly some unfamiliar syntax. It's a bit long, but it's doing more than just an insert. [1] I've heard the cake argument many times, and I agree that it's more naturally modelled as a series of steps. But I find it frustrating, because I've never heard a convincing argument for why the fact that one particular problem is more intuitively modelled as a sequence of steps, means all problems are. For example, imagine if you were never allowed to declaratively specify a DOM again using HTML, but instead you had to construct it as a series of calls to element.appendChild(). Would that really make your life easier? There are many problems for which a declarative description, not a procedure, is much more straightforward to understand. Another point is that you can also think of applying functions in succession ("function composition") as a series of steps! I find this pretty intuitive. For example, here's a function which takes a list of words and shouts them. The steps are: First concatenate the words together, then capitalize the resulting string, then append an exclamation mark: λ » shoutWords = unwords .> capitalize .> exclaim λ » shoutWords ["i'm", "shouting"] "I'M SHOUTING!" I think you're right about needing to have a certain level of smarts to get Haskell, but I think this is a consequence of some more advanced Haskell features (Typeclasses + higher kinded polymorphism), rather than the functional paradigm itself. For example, I think Elm is probably very approachable for people with a wide variety of different levels of mathematical ability. I think it's very easy to assume that functional programming is inherently more difficult, when it might well be that all that's going on is that people are more used to procedural programming because that's what they were taught first. I really would encourage anyone who thinks FP is inherently difficult to have a crack at learning Elm. [1] https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Database-MongoDB.html https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Dat...