Mathematics also comes with comments, many papers essentially consists of one giant comment for the proof in the appendix. Granted, many variable names could be a bit less terse, but it's just easier to write "let f be an arbitrary function A -> B" once instead of using arbitraryFunctionMappingTheSetOf{DefinitionOfElementsOfA}toTheSetOf{DefinitionOfElementsOfB} every time.
Function and Map are different concepts that should not be described together.
In CS I'd just say
B = map(some_function, A)
Not in this context. Assuming you are using `map` in the CS sense, B is what is called the "image" of some_function (over the domain A).
In math, a function is a mapping.
Consider the type of `some_function`. In C like notation, it would be `foo some_function(goo x)`. Which indicates that some_function takes an arguement of type `goo` and returns a value of type `foo`. In other words, some_function maps Goo to Foo (where Goo and Foo represent the set of all values of type goo and foo).
What I'd expect to follow here would be a statement about how your abstractions should be terse and verbose in the right ways. Terse in the implementation specific handling and verbose in the explanation of your abstract solution.
"Software is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of systems programming without having understood the basic implementation of the underlying software. No amount of syntax rewriting is going to change that; those definitions are not going anywhere."
I don't see how that statement would make any sense. I expect to be able to give anyone with the most basic of understandings of computers a piece of any code (from Assembly to high level Lisp code) from widely used software like the Linux kernel all the way to stock trading applications and I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions.
If the average person cannot do that, then it's bad code. Understand-ability is the only point of programming. To be understood by the computer and by a maintainer.
I'd never say that obtuse notations for an abstraction should stay around. I'd replace the obtuse notation with a better abstraction.