| name | oopsla-writing-style |
| description | Use when revising a draft into OOPSLA's register — design insight stated before the artifact, claims written to be falsifiable, motivating examples that carry semantics, journal-article pacing inside the 23-page cap, and honest threats-to-validity prose that preempts the revision lever rather than triggering it. |
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
