Many of those short names are keywords (or pre-defined identifiers) in many programming languages, e.g. string, close, print, copy in Go. Having to use another name instead can also be difficult.
FWIW, I never have really found the ambiguity caused by using the same symbol as both a variable and a function to be a readability problem: I think people are generally pretty good at things like noun/verb ambiguity and so this kind of ambiguity sort of "clicks" with us.
What has bitten me many times is accidentally overwriting a builtin function like max or len in python and then scratching my head about the strange errors that result from this.
Overwriting is not so much a problem of naming than one of dynamic updates: some environments do actually display a warning when you change a global binding, which helps.
That helps, but I find that a Lisp-2 like Common Lisp (I.e. A language with different namespace for variables and functions) is a more intuitive programming environment than languages with a single namespace.
I'm extremelly well informed about Lisp-1 versus Lisp-2. I chose Lisp-2 for my own Lisp dialect, with special support for working in the Lisp-1 style: there is a way to code with higher-order functions without ever using the dialect's equivalents of the funcall function or function operator. I thereby consider the Lisp-1 vs. -2 question to be a solved problem.
The requirements which drive the preference for either are all valid. I, the designer, have simply taken both requirements and integrated them. Of course, requirements like, "I want to use list as a variable name without shadowing the lisp function" directly conflicts with "I want to reference functions and variables the same way without function or funcall". However the conflict can be confined down to the argument list of an individual form. I.e. "Sure, you can have both, just not in the argument list of the same form."
Incidentally, I've been using TXR a bit for text-processing recently, it's generally been pretty nice once I've figured out what exactly needs to be done to get the matching to work, but the various failure modes for the pattern language aren't very intuitive.
I don't disagree. If debugging that sort of thing were intuitive, we'd all be coding in Prolog. It's like an invisible "if" hidden in every statement which branches elsewhere if there is no match. @(assert) can help; if you know that something that follows must match, you get an exception if it doesn't. I used asserts in the man page checker:
