Does functional programming mandate new naming conventions?

Question

I recently started studying functional programming using Haskell and came upon this article on the official Haskell wiki: How to read Haskell.

The article claims that sh

Answer 1

In a functional programming paradigm, people usually construct abstractions not only top-down, but also bottom-up. That means you basically enhance the host language. In this kind of situations I see terse naming as appropriate. The Haskell language is already terse and expressive, so you should be kind of used to it.

However, when trying to model a certain domain, I don't believe succinct names are good, even when the function bodies are small. Domain knowledge should reflect in naming.

Just my opinion.

In response to your comment

I'll take two code snippets from Real World Haskell, both from chapter 3.

In the section named "A more controlled approach", the authors present a function that returns the second element of a list. Their final version is this:

tidySecond :: [a] -> Maybe a
tidySecond (_:x:_) = Just x
tidySecond _       = Nothing

The function is generic enough, due to the type parameter a and the fact we're acting on a built in type, so that we don't really care what the second element actually is. I believe x is enough in this case. Just like in a little mathematical equation.

On the other hand, in the section named "Introducing local variables", they're writing an example function that tries to model a small piece of the banking domain:

lend amount balance = let reserve    = 100
                          newBalance = balance - amount
                      in if balance < reserve
                         then Nothing
                         else Just newBalance

Using short variable name here is certainly not recommended. We actually do care what those amounts represent.