Bits and Behavior
Published in

Bits and Behavior

A group photo of the Dagstuhl castle of every attendee in the workshop on a staircase.
The official Dagstuhl group photo.

Dagstuhl trip report: theories of programming

  • Tuesday: welcome, what is theory, describing theories, critiquing theories
  • Wednesday: brainstorming unexplained programming phenomena, sketching theories, getting feedback on theories, and refining theories
  • Thursday: presenting theory sketches, discussing ways of sharing theories, and skeptically examining whether developing theories of programming is really worth the time
  • Friday: reflecting on takeaways and departure
Thomas prepares to kick off the workshop with a slide titled “What is theory?”
Thomas sets the figurative stage on the literal stage.

Tuesday: Understanding Theories

A lecture hall of 28 people listening to a speaker.
Attendees ask questions about the theory template.
  • A short name to help people refer to the theoretical explanation in conversation
  • A summary of the theory
  • Contributors to the theory
  • A description of the phenomena being explained
  • A collection of prior work (including existing theories) that help explain the phenomena
  • Concepts in the theory, such as variables, processes, people, agents, structures, contexts, or other details necessary for accounting for some phenomena
  • Relationships and mechanisms that offer a causal explanation of how the concepts interact to explain the phenomena, with a prompt for concrete examples.
  • Example hypotheses that theory might predict
  • Example studies that might test example hypotheses
  • Corollaries that follow from the theory
Michael Coblenz, Slim Lim, me, and Justin Lubin playing root at a table with a green tablecloth.
Michael Coblenz, Slim Lim, me, and Justin Lubin playing root.

Wednesday: Creating Theories

  • People make mistakes when programming (inserting bugs).
  • Data-driven programming vs “logic-driven” programming
  • theory of what “bit-rot” is and why it exists
  • theory of edge cases (what “unexpected” means)
  • separating programming and capitalism (what would a socialist/ communist/ anarchist programming language look like?)
  • non-English PL and compatibility with English PL
  • Ephemerality in programming (SW that runs a few times vs runs for 50+ yrs)
  • Effect of climate change, infrastructure collapse on programming (assumptions, constraints)
  • human infrastructure (e.g. unwritten knowledge, hidden labor) for maintaining SW infrastracture
  • Debugging into existence is sometimes effective
  • How rubber ducking affects debugging outcomes
  • The effect of being trained to write code with pencil and paper on learning outcomes
  • Programming with concrete examples (example use/test cases, example data vs reading documentation/code)
  • Novices become experts / Programmers gain skills in different ways and at different speeds / The effects of expertise on handling problems (psychic debugging, schemas for error messages, etc.)
  • Using static (and dynamic?) analysis to guide problem solving
  • How types influence programming
  • Human infrastructure of software infrastructure (turnover, tacit knowledge, data labor)
  • Programming styles (opportunistic / systematic) and upfront vs. deferred understanding / Neurodiversity and programming
  • Data-intensive programming vs. logic-driven programming
A panoramic view of the seminar room with 28 people having paired conversations about theories.
Feedback speed dating in the seminar room.


Jon Bell talks about their theory of debugging with a slide titled “Our scope”
Jon Bell talks about their theory of debugging.
  • The types group presented a fascinating theory about the role of types in programming, postulating that writing types is about creating an ontology of constraints that, when sufficiently expressive, help programmers ensure consistency with an ontology, and evolve that ontology when it is insufficiently expressive. With this theory, they hypothesized that whether types are helpful has much to do with how expressive the type system is, how well it can model the domain they are trying to expression, and how well type information is used to find inconsistencies. This theory strongly resonated with my own experiences with type systems, but also made me wonder about the barriers that requiring an ontology to be expressed at all might pose to someone not used to thinking about a domain in such rigid terms.
Benji Xie talks about a theory of data programming, with a slide titled Concepts: Computational Notebooks”
Benji Xie talks about a theory of data programming.
Jun presents their “Theory of Code Examples” Google Doc
Jun Kato talks about a theory of example code.
The tools and expertise group presents a set of hypothesis during a discussion on a stage, listening patiently.
The tools and expertise group presents a set of hypothesis during a discussion.
Emma writes “Learning Effects from Code Analysis” on the chalkboard.
Emma Söderberg uses the chalkboard to draw.
A complex diagram describing a flow chart of when to use theory.
When to use theory? It depends.
Six illustrations depicting abstract contexts in which theory might be problematic.
Good luck decoding these visual puns.
Warring factions of animals in the woods on a cardboard board game.
We finally figure out Root. (At least part of it).
Thomas LaToza standing on a stage.
Thomas closes out the workshop, soliciting reflections.


  • As a community, we don’t yet have the infrastructure or skills for creating and evolving theories. We need a lot more opportunities like this Dagstuhl to learn and grow capacity and “muscles” for doing theory work. We don’t even have graduate courses that talk about research methods, let alone theory.
  • To our surprise, everyone found deep relevance and utility in thinking theoretically about programming. There is promise here, even if it’s unrealized.
  • Our publication venues are generally hostile to theory. There is great opportunity to bring together the many communities concerned with programming—such as the VL/HCC, CHASE, Programming, and PLATEAU conferences and workshops—and begin to create a context for doing this theory work together across different areas of CS.
  • Everyone appreciated the time to talk about theory explicitly; for many , it was always in the background of their careers, but never a subject of conversation.
  • There are many debates to be had (or rehashed, from other fields) about where theories should come from: data, subjective insights, other fields?
  • Everyone in all of these communities is so nice and wonderful! Stereotypes be damned: we are a social bunch, especially after two years of being apart.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Amy J. Ko

Professor of programming + learning + design + justice at the University of Washington Information School. Trans; she/her. #BlackLivesMatter.