In the old days, when mathematics journals were all published on paper, there were hard budgetary constraints on the number of pages available in any issue, so long papers were naturally a much harder sell than short ones. But now that the primary means of dissemination of papers is electronic, this should no longer be the case. So journals that still impose draconian page constraints (I’m looking at you, CS conference proceedings), or reject papers because they are too long, are just a holdover from the past, an annoyance to be put up with until they die out.

At least, that’s what I used to believe.

Recently I’ve become quite enamored with the idea of writing short papers. The reason is quite simple: I prefer to read short papers! Every day seems to have fewer productive hours in it than the last, and an 80-page paper just doesn’t make me want to spend the time.

Many of my papers are quite long. Recently I made a list of all my papers and their page counts, and 13 of them are 70 pages or more. Some of those papers really do have to be that long: getting to the punchline just requires that much setup. Others are long because of the “encyclopedic impulse”, trying to include all potentially-important facts about the concept being studied. I still think there is a place for papers of this length; one might argue that they occupy a sort of novella ground in between short papers and research monographs. And so I’m still glad that the Internet is making it easier for some journals, at least, to publish long papers.

However, I’ve noticed that some of the papers that I’m proudest of are among the shortest I’ve ever written. A short paper, like a short story, doesn’t waste any time: it sets up exactly what’s needed and gets right to the point. A short paper generally has just one idea to get across, and does it as efficiently as possible. And a short paper doesn’t require an immense time committment of the reader, hence is more likely to get read — and more likely to get refereed quickly.

With all that in mind — in addition to the draconian page constraints imposed by some journals and conference proceedings — I’ve been thinking more recently about how to write short papers. I think probably anyone who’s tried can testify that it’s not as easy as it may sound! Here are a few tricks that I’ve come up with so far:

As memorably enjoined by Strunk and White, omit needless words . Actually, my own experience suggests that they should instead have said “remove needless words”. I find it much easier to recognize the needlessness of words after I’ve written them. Usually when I come back to a paragraph I’ve written a day or two later, I can shorten it by a line or two without reducing the content, and make it read better in the bargain.

Suppress the encyclopedic impulse . A paper doesn’t need to explore every possible ramification of its definitions. In fact, it may be better if it doesn’t: open problems help get other people excited about a subject. There’s a balance here, of course. Fortunately, the encyclopedic impulse now has other outlets, like writing on the nLab. (Writing on Wikipedia would probably fall afoul of the No Original Research policy, but the nLab encourages original research.)

Write, then delete . Blaise Pascal is often quoted as saying “I made this letter longer than usual because I have had not time to make it shorter.” Often I find that the way to write a short paper is to first write a long paper and then remove things from it. It doesn’t have to happen in two discrete stages: I can be removing things as I’m writing other things. But I often find that it’s not until I’ve written something out reasonably carefully that I can be sure that it can be omitted, or that I can see how best to condense it into a two-sentence remark. This strategy also helps deal with the encyclopedic impulse: just writing something down helps stop it clamoring in my head, even if that something never makes it into the actual paper.

Omit or shorten proofs. This is the most controversial. Of course a math paper needs proofs, but omitting or only sketching some proofs that can be reconstructed by the reader can help streamline it and make it easier to read. On the other hand, it’s quite frustrating when the author of a paper thinks a proof is straightforward, but it doesn’t seem so straightforward to the reader. It would be great if proofs could be “hidden” in the default version of a paper, making it shorter, but with a button for the reader to click that says “expand this proof”. Maybe there could be even multiple levels of expansion: first a telegraphic version that gives the basic ideas, then a more detailed version with all the nitty-gritty. Unfortunately, while something like this is possible when writing math on a wiki, all “real” journals that I’m aware of publish papers as PDFs which don’t have any feature like this. But there are workarounds; for instance, in computer science (at least, among the computer scientists I hang out with) it seems to be not uncommon to publish short versions of papers, with most proofs omitted, in conference proceedings that have very stringent page limits, but to also make a longer version containing the proofs available on a personal web site. Also, if the proofs are formalized in a computer proof assistant, then the burden of absolute rigor is lifted from the written paper.

What other tricks are there for writing short papers?