Why "x"? It's idiomatic, like using T for a type in C++ templates, argc and argv for the inputs to main in C, making the second returned value in a Go function

Why "x"? It's idiomatic, like using T for a type in C++ templates, argc and argv for the inputs to main in C, making the second returned value in a Go function the error and calling it err and not error or e or er or failed, using the type "t" in OCaml to specify "the" type a particular module is defining (I think...), or anything else. X, y and z in maths are idiomatic; there's no good reason they're used instead of a, b, c, or LR, UD, FB (left-right, up-down, front-back) for coordinates except that that's what people are used to, and sticking to the convention makes code/equations easier to follow because your brain is used to seeing x used a certain way, so you don't need to keep checking to see what it is when you see it in longer code/equations. Many haskell functions operating on lists are described in terms of the first element "x" and the rest of the elements xs (exes or "the rest of the x's"). It's a common convention used because we have no idea what x might be, all we know is that, in this case, elements of the type that x is can be ordered. This means that one function works on lists of numbers, letters, string, lists of numbers, booleans, etc. Basically terse names like that are used because many haskell functions are very general. We could have decided on (hd:tl) or something, but there's something nice about stating that there is one value x and some values which are also x's. You have to remember these are not features of the language, they are the idiomatic styles that are built up by the users of the language. Haskell's community encourages writing short code which is clear once you understand whatever abstractions are being used (Applicatives, Monads, lists, curried functions, type classes and so on). This is in some ways the essence of programming, building abstraction upon abstraction to make beautiful, "obviously correct" code. Haskell allows very (cognitively and syntactically) cheap abstraction, so they're used everywhere. You complained about having to "decrypt code" in order to understand it, but this is true of any language; you may understand the keywords and how to put things together, but you won't get far if you can't get used to the idioms and conventions used by others using the language.