Historical note
This editorial was written in 2009, when I had just taken over as editor of the Functional Pearls column in JFP. Since then, the editorship of the column has passed on to Ralf Hinze. However, my advice to authors and reviewers is still valid.
Functional Pearls
In Summer 2009, I took over from Richard Bird as editor of the Functional Pearls column in Journal of Functional Programming. (I'm also a general editor of the journal, so may deal with ordinary papers too.) I'm keen for submissions; do get in touch if you'd like to discuss a potential paper.
What is a Functional Pearl?
Richard Bird gave an invited talk at ICFP 2006 in Portland on How to Write a Functional Pearl, and I heartily recommend that pearl authors and reviewers look at his slides.
Bird recalls Jon Bentley's Programming Pearls column in CACM, about which Bentley wrote: "Just as natural pearls grow from grains of sand that have irritated oysters, these programming pearls have grown from real problems that have irritated programmers. The programs are fun, and they teach important programming techniques and fundamental design principles." Those guidelines apply too to functional pearls.
Typical functional pearls consist of:
- an instructive example of program calculation or proof, or
- a nifty presentation of an old or new data structure, or
- an interesting application or programming technique.
Bird characterizes them as "polished, elegant, instructive, entertaining". They are not just shorter versions of standard research papers; they are not judged by the same criteria, and should not have the same structure. In particular, they need not have the typical academic paraphernalia of abstract, introduction, conclusion, related work, and thorough referencing. Think more along the lines of short stories—6 to 10 pages, brisk, engaging, accessible, surprising.
Nevertheless, pearls are still subject to peer review. I will continue to give Bird's advice to reviewers, instructing them to stop reading when:
- they get bored, or
- the material gets too complicated, or
- too much specialist knowledge is needed, or
- the writing is bad.
Many people have found that writing in this format is fun, and I look forward to receiving burnished, lustrous submissions!