| name | oopsla-experiments |
| description | Use when designing or auditing the evaluation of an OOPSLA paper — matching evidence type to claim type across the venue's spread (benchmarks, corpus studies, case studies, user studies, mechanized proofs), building baselines and workloads that survive the SIGPLAN checklist, and sizing experiments to the round calendar. |
OOPSLA Experiments
OOPSLA's evaluation question is not "is there a big table?" but "does the
evidence type match the claim type?" The venue's published scope runs
from mathematical formalisms to empirical studies, and its exemplars span
benchmark suites, measurement methodology, corpus mining, and language
experience reports (resources/exemplars/library.md) — so the first design
act is choosing the right instrument, and the second is executing it to the
SIGPLAN Empirical Evaluation Guidelines standard that reviewers apply
checklist-in-hand (oopsla-reproducibility operationalizes the pillars).
Claim-type → evidence-type routing
| Claim type | Primary evidence | Common OOPSLA failure |
|---|
| "Faster / cheaper" | Benchmarks vs strongest baseline, variance reported | Weak baseline; startup vs steady-state conflated |
| "More expressive / safer" | Formal result + programs witnessing the boundary | Expressiveness asserted by example only |
| "Programmers benefit" | User study or field data with a design | Anecdote from the authors' own use |
| "Occurs in practice" | Corpus study with stated selection rule | Convenience sample of famous repos |
| "The design generalizes" | Second instantiation (language/runtime/domain) | Single-host generalization claims |
| "Semantics is right" | Mechanization or proofs + conformance tests | Calculus untethered from the implementation |
A paper may need two rows; it rarely supports five. Cutting a claim is
cheaper than defending its missing evidence through a Major Revision.
Baselines and workloads that survive scrutiny
- The baseline is what a skeptical expert would actually use today, tuned the
way its own paper tunes it — document versions and flags in the paper.
- Workload selection needs a rule (suite version, corpus filter, sampling
frame) stated before results; exclusions listed with reasons. Curated-only
workload sets are the most quietly fatal reviewer finding.
- For LLM-era tooling claims, hold out for contamination: date-split corpora,
and report sensitivity to prompt/configuration where relevant.
- Negative controls: include a configuration where your mechanism should
not help and show that it doesn't. Nothing signals honesty faster.
Sizing experiments to the round calendar
The two-round system changes experimental economics. Between an R1 verdict
and the R2 resubmission there are only months, so:
Design now, before Round N:
- matrix of runs a reviewer could plausibly demand (extra baseline,
larger corpus, second platform) with wall-clock + hardware cost each
- keep the harness parameterized so a demanded cell is a config change
- archive raw results per run (the ledger of oopsla-reproducibility)
Payoff: a Minor Revision executes in days; a Major Revision's
expectation list maps to known cells instead of new engineering.
Analysis floor
- Repetition counts, warmup handling, and dispersion (CI or IQR) for every
performance number; significance or effect size where comparisons are the
claim.
- Summaries chosen deliberately (geomean for ratios) and stated.
- Human-subject work: sample size rationale, task design, and ethics/IRB
status — the venue takes the human-aspects lane seriously enough to review
it by social-science norms.
- Case studies report failures encountered, not only successes; an
experience report with zero friction reads as marketing
(
oopsla-writing-style).
Output format
[Routing] claim → evidence rows used + mismatches found
[Baseline audit] strongest-sensible test: pass / gaps
[Workload rule] stated / absent; exclusions justified: yes/no
[Demand matrix] anticipated reviewer demands with cost estimates
[Analysis floor] repetitions/dispersion/summary-statistic compliance
