Functional programming languages use single-letter parameter names as a tool to help condense functions and allow easy parsing. This is largely due to their desire to emulate mathematical formulae.

Interestingly, functional programming leads to a different naming custom that this presentation didn't really cover. To write "functionally" you want to have pure single-purpose functions and the name is supposed to describe exactly what the function does. If you can't write a short enough function name then your function is probably too long and should be broken up into functions that can be given concise names.

Another interesting functional programming naming custom is that a function that transforms data (fully FP) should describe the final result rather than the action of changing it. So if you transform a string to json, the function should be simply called `json` rather than `string-to-json` or `json-parser`. This is because when reading the code you can clearly see that the string is now json (it can almost look like a type). Of course, if that function does anything else, then naming it `json` is wrong but the function is also breaking away from being pure and single-purpose.

In typed functional programming the more general the type of a variable, the shorter it's name.

Eg in the following snippet

    map :: (a -> b) -> [a] -> [b]
    map f (x:xs) = f x : map f xs
    map _ [] = []

there's nothing known about x (apart from that you can apply f to it). So there's no way to give it a more descriptive name. We just don't have more information.

Actual mathematical functions have some of the most useless, non-descriptive or vaguely metaphorical names going, so I'm not sure promoting an isomorophism with FP is a good thing. Examples: "bessel", "spherical_harmonic", "delta", "zeta"... Math is hard, and the terseness of mathematical notational conventions is one of the things that makes it so. Names that carry meaning with them are an aid to the naive user, and that is a good thing.

Secondly, naming a function "json" requires the user read the code or the comments to figure out what it does, and blocks the user of the name for anything else that returns json. Suppose rather than a string you have a list that you need translated to json... what do you name the function?

There are three levels of documenting code: naming, comments, and the code itself. Function names should be chosen such that other developers can reasonably guess at a glance what the function does, because the two most comon use-cases for names are:

1) reading someone else's code, where digging in to find out what "json" does is orders of magnitude more work than reading "json_from_string"

and

2) figuring out how to do something in a given codebase, where skimming over a list of function names and picking out one or two that look likely for deeper investigation is orders of magnitude faster than reading the docs or the code for every function to find out which obscurely-named function does the job you want.

Longer, more fully descriptive names aid the user in the excecution of these use cases.

> Secondly, naming a function "json" requires the user read the code or the comments to figure out what it does, and blocks the user of the name for anything else that returns json. Suppose rather than a string you have a list that you need translated to json... what do you name the function?

`json` --polymorphic languages make naming easy!

> Secondly, naming a function "json" requires the user read the code or the comments to figure out what it does, and blocks the user of the name for anything else that returns json. Suppose rather than a string you have a list that you need translated to json... what do you name the function?

This is exactly what functional programming seeks to solve. This should be the same function. Every language that has the power to do FP has the ability to do multi-functions or pattern matching just for this kind of situation.