oopsla-writing-style

OOPSLA Writing Style

An OOPSLA paper is read twice by design: once by a committee choosing among

four outcomes, and again — possibly by the same people — if a revision comes

back. Style at this venue therefore optimizes for checkability: a paper

whose claims can be verified paragraph by paragraph collects bounded revision

demands (or none), while a paper that argues by adjective collects unbounded

ones. The published form is a journal article (PACMPL), and the prose should

carry that register: measured, self-contained, built to be cited.

Voice calibration

| Draft habit | OOPSLA replacement |

| --- | --- |

| "We present NovelTool, a novel system for..." | Name the design question and your answer; the tool arrives as evidence (see resources/worked-examples/01-introduction.md) |

| "Our approach significantly outperforms..." | The number, the baseline, the workload, the dispersion — or nothing |

| "To the best of our knowledge, first..." | A positioning sentence naming the nearest prior work and the delta (oopsla-related-work) |

| "Due to space limitations, details are in the appendix" | A body-level statement of what the appendix establishes (oopsla-supplementary) |

| A wall of formalism before any example | A running example that motivates each definition as it appears |

The running example as load-bearing structure

OOPSLA's classic papers — from type-system counterexamples to

language-experience reports (resources/exemplars/library.md) — are built

around concrete programs. Choose one small example early and make it do

three jobs: expose the problem, exercise the mechanism, and mark the

boundary (show the case the mechanism does not handle). If your example

cannot demonstrate the limitation honestly, the limitation section will read

as boilerplate — reviewers notice.

Claims that survive two readings

Write each contribution as a sentence with a built-in test:

Weak:   "We propose an efficient analysis for X."
Strong: "The analysis decides X for programs in fragment F in O(n log n);
         outside F it degrades to a sound approximation, evaluated in §6.3."

Weak:   "Our semantics is more expressive."
Strong: "Every program typable under [prior] remains typable (Thm 4.1);
         the converse fails on the example of §2.2."

The strong forms give a Minor-Revision reviewer something bounded to check —

which is exactly the outcome ladder you want to be standing on.

Journal pacing inside 23 pages

• Spend the first two pages entirely on problem, insight, and claims; a

reader stopping there should be able to state your thesis.

• Sections should alternate mechanism and evidence; ten pages of design

followed by two of evaluation reads as unvalidated, the inverse as

unmotivated.

• Threats-to-validity and limitations get their own subsection with specific

content: which claims depend on which assumptions, and what was not

measured. Generic threats paragraphs are revision bait.

• Prose must not lean on the appendix for coherence; the 23 pages are the

paper (oopsla-supplementary for the layering rule).

Revision-aware editing

When revising for a second round, mark the diff in prose quality too: the

change log tells reviewers where you changed; the writing must make each

change locally self-justifying, because continuity means your examiners

remember the old text. Never quietly weaken a claim a reviewer challenged —

weaken it visibly, with the reason.

Output format

[Register] design-insight-led: yes/no + first page diagnosis
[Adjective sweep] unquantified evaluatives found: <count + worst three>
[Claim audit] contributions rewritten in falsifiable form
[Example] running example present / missing / does not mark boundaries
[Pacing] mechanism-evidence alternation + limitations specificity