Evidence-Oriented Programming
summary
Introduces a concrete evidence regime: a new language Quorum built with NSF funding, audited by randomized designs and surveys, plus prototyped tools like talking debuggers and auditory navigation. Finds specific, surprising numbers: novices hit certain tokens only 25% correct, a double-equals causes an eight-fold increase in errors, and novices often fare no better in Java or Perl than in a randomized language. Shows token accuracy mapping, RCT-style comparisons of static vs dynamic typing, and large-scale compiler error mining.
AI-written summary · about
chapters (20)
- 0:00Intro
- 2:45So I started talking to blind children and teachers of the visually impaired
- 3:44Programming blind was hard for many reasons
- 8:41In the first phase, experiments exposed quackery and fraud
- 10:08What about homeopathy?
- 11:11Sensation, psychics, and talking to the dead
- 12:24By phase 4, pharmacology pushed us forward
- 13:56Phase 5: The beginning of randomized controlled trials
- 16:58There was (nearly) no evidence - language designers were using anecdotes
- 17:42So we* created Evidence-Oriented Programming
- 19:38Let's discuss how we choose our syntax/semantics
- 20:56Evidence-oriented programming is a paradigm, not a language
- 21:49Exceptions: an example where the data is unclear
- 22:27Knowing the history, we then used Sham Treatments
- 25:48What about type systems?
- 27:44If we do software repository mining, is this theory supported?
- 29:03Let's look at an "action" in Quorum
- 33:43What about other systems?
- 35:14Why should we care?
- 38:00Consider a "thought experiment" on cost
related talks
31mSynthesizing Evidence of Emergent Computation
16mA Rhetorical Framework for Programming Language Evaluation
19mPanel: Compilation Frameworks
57mWhy Programming Languages Matter
01h 02mLanguage Design meets Verifying Compilers
39mAsk Me Anything with Alex Aiken
01h 31m"Thoughts on language evolution"
15mEffect Handlers, Evidently