Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of luqui (5770)

Thursday September 29, 2005
08:53 PM

Silly Academia

[ #26943 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Totally right there. I just don't have the attention span to read that crap, so I tend to miss out.

    I think part of the problem is that academic papers are not yet optimized for the networked way of doing things.

    Aside from way too many being in PDF (*SIGH*), most assume you're coming to them from a background in the field, rather than that you just came from a Google search or a link posted on IRC.

    "No, thank you, I don't want to have to spend 15 hours trying to read enough Wikipedia articles to understand t
  • An acedemic paper is a curious mix of (in programming terms) code and documentation. It has to be a precise description that can be duplicated by others (i.e. code), but it also has to be understood intellectually by the reader (i.e. documentation). The set theoretic notation is compact and precise, working better as the code formulation; your "translation" works better as the documentation formulation. Best would be to have both, perhaps in a two column layout with the prose "documentation" in one colum
  • 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." ;^) Many o