While reading "Ordered Attribute Grammars, Uwe Kastens, 1980", I came across this description of one of the functions he was using in his example:
include(a,d): "a" is a set of descriptions, "d" is a description; the result is "a U {d}" if a does not contain a description "d'" for the same identifier described by "d", "{a\{d'}} U {d}" otherwise.
(I used U for union and \ for difference)
Stare at that for a little while. You can probably figure out what it's saying within a few minutes. But how about:
include(set,desc): "set" is a set of descriptions, "desc" is a description; if "set" already contains a description with "desc"'s identifier, it returns "set" with that description replaced by "desc". Otherwise it returns "set" with "desc" added.
If the author weren't so attached to keeping everything set-theoretic, you could say that a is a dictionary from names to descriptions, and make it even easier to read.
More recent papers have the same kind of purely mathematical language, formulating everything in terms of sets, using single uppercase letters for set names and single lowercase letters for variables. Anybody who programs that way is scolded by the community for producing unreadable and unmaintainable code. Yet academic papers, which have much more respect than programmers, continue to use this cryptic notation. These papers don't deserve respect.
It's because of this mathematical-notative culture that Haskell uses all the cutting-edge research and the dynamic languages are stuck re-inventing Smalltalk. It's not that the new research is so hard to implement, it's that it's documented incomprehensibly. PhDs in Haskell read papers and write the algorithms they describe just like everybody else, but they're trained in reading this dense academic language.
And of course, when I eventually do my dissertation, if I don't write this way my dissertation will be rejected and I won't get my degree. I won't think of the problem I solve purely in terms of sets and single-letter variables, I'll think of it in terms of computer science concepts, which have English names. I'll have to convolve my ideas into mathematical academic language, only to have other academics untangle them back into everyday computer science concepts as they read.
Computer science academics need to retake Freshman writing.
More recent papers have the same kind of purely mathematical language, formulating everything in terms of sets, using single uppercase letters for set names and single lowercase letters for variables. Anybody who programs that way is scolded by the community for producing unreadable and unmaintainable code. Yet academic papers, which have much more respect than programmers, continue to use this cryptic notation.
Ironically, this reminds me of all those critics who dismiss Perl as "line noise."
Here are some of my thoughts.
Possibly due to my humble BS in Mathematics, I've never been scared by Perl's sigils and heavy use of symbolic operators, and often prefer such syntax. I often ask, would you really rather have this
two plus two equals four
than this
2 + 2 = 4 ?
Sometimes I suspect the "line noise" critics secretly want to make all languages look like COBOL. We often complain about not wanting to type such verbose code, but I often don't want to read it, either. In the above case I actually find the symbolic notation easier to read and understand.
I first started thinking about this when comparing modern re-statements of Euclid's proof of the inifitude of primes, like this one
Assume there are a finite number, n, of primes, the largest being pn. Consider the number that is the product of these, plus one: N = p1...pn+1. By construction, N is not divisible by any of the pi. Hence it is either prime itself, or divisible by another prime greater than pn, contradicting the assumption. [1]
to Euclid's original, much more verbose version. What this example also shows is that sometimes symbolic notation may help us to understand and/or express ideas that would be extremely difficult to handle otherwise:
Euclid sometimes wrote his "proofs" in a style which would be unacceptable today--giving an example rather than handling the general case. It was clear he understood the general case, he just did not have the notation to express it. His proof of this theorem is one of those cases. [2]
OTOH, these statements provoke opposing thoughts:
It's because of this mathematical-notative culture that Haskell uses all the cutting-edge research and the dynamic languages are stuck re-inventing Smalltalk. It's not that the new research is so hard to implement, it's that it's documented incomprehensibly. PhDs in Haskell read papers and write the algorithms they describe just like everybody else, but they're trained in reading this dense academic language.
And of course, when I eventually do my dissertation, if I don't write this way my dissertation will be rejected and I won't get my degree.
Despite what the "experts" may say, I often doubt that all the abstractions, symbolic and otherwise, in certain fields serve any useful purpose. I suspect some of them serve only as a high barrier to entry, keeping the wealthy and powerful free to pursue leisurely lives of intellectual musings, safe from competition from the rabble outside their gated, master-planned communities.
1. http://www-users.cs.york.ac.uk/user/susan/cyc/p/primeprf.htm
