I dunno. Exceptional though they may be, I can imagine situations in which it would be a net gain to write mp rather than map. I don't think "readability" should only mean "readable by someone who is unfamiliar with the program's conventions and is encountering it for the very first time". It does mean that, but it should also encompass "readable by someone who is working with the code repeatedly, as if it were clay". Devices (like long names) that help you read the code de novo can get in the way after a while. Map itself doesn't mean what it says; it's a convention, one I bet was introduced for brevity. I think it's reasonable for languages and programs to adhere to conventions and ask the reader for patience while first working with them, especially if the notation has been crafted to maximize the intelligibility of the code over the long haul.
One doesn't just sit and speed-read math in a single pass. Nor poetry. Good programs have that kind of density and deserve the same consideration; they are not newspaper columns. The trouble with the shallow notion of readability that says "I should be able to random-access any line of code and understand it right away" is that it results in less intelligible whole programs, which is a net loss of readability and of other things as well.
I wish more good programmers understood this. The bad ones we can write off, but too many good ones have been schooled to focus overly on the line-of-code. If you have a million lines of code, it doesn't much matter how readable an individual line is; nobody's going to be able to read the whole thing. What we should be striving for is to produce an equally functional program with orders of magnitude less code (which would automatically be a more functional program). This requires a quite different notion of readability.
Reducing the size of a program by an order of magnitude requires better abstractions, not shorter selector names. I'm not saying names have to be long, I'm saying they should be whole words, not abbreviations of words. The English language is full of whole words that are still very short.
Math notation is horrendous by the way, too many implicit assumptions about the readers background knowledge. See what Gerry Sussman has to say about it. The great thing about code is it forces one to be explicit, which forces one to actually understand and learn.
One doesn't just sit and speed-read math in a single pass. Nor poetry. Good programs have that kind of density and deserve the same consideration; they are not newspaper columns. The trouble with the shallow notion of readability that says "I should be able to random-access any line of code and understand it right away" is that it results in less intelligible whole programs, which is a net loss of readability and of other things as well.
I wish more good programmers understood this. The bad ones we can write off, but too many good ones have been schooled to focus overly on the line-of-code. If you have a million lines of code, it doesn't much matter how readable an individual line is; nobody's going to be able to read the whole thing. What we should be striving for is to produce an equally functional program with orders of magnitude less code (which would automatically be a more functional program). This requires a quite different notion of readability.