Over the last 10 days, I had the pleasure of attending rstudio::conf and the Dagstuhl seminar on Evidence about Programmers for Programming Language Design. At rstudio::conf, I taught a two-day workshop on Intro to R & RStudio, and at the Dagstuhl I mostly thought about exposing novices to programming in scientific contexts. So, there was a lot of overlap.
Schloss Dagstuhl is a historic castle that hosts workshops on topics related to computer science. The idea is to bring a small group of people (ours was about 35) together for a week to discuss a specific topic, with the goal of advancing the discipline.
In this case, what we wanted to advance was evidence about programmers for programming language design. Most programming languages are designed by intuition. But, given that the people who write programming languages are not always the people who use them, and we may be quite different from most users, this is likely not the best strategy. To improve, we’d like to put the “science” in “computer science.”
We began the week with presentations from a subset of the attendees (I wrote a separate post about my talk, Scientists Programming). The talks were aimed to ground us in the disparate disciplines we came from, including programming language design, eye tracking, science, and education. Then, we spent the remainder of the time in discussion, both small-group and full-group.
I was invited to the workshop by Andreas Stefik, the absolute master of Skype networking with other academics. Stefik is known for developing an evidence-based programming language, called Quorum. He was the only person I had interacted with at all before the conference, and our interactions had been limited to Skype and email.
However, I discovered many connections with other folks once I was there.
Brad Meyers - better language goals
One of the first presentations of the workshop was by Brad Myers, who spoke about types of studies. However, what stuck out the most to me was his modified version of programming language goals.
Brad Myers started his #dagstuhl talk by comparing programming language design goals:— Amelia McNamara (@AmeliaMN) February 5, 2018
2. Performance (of code)
4. Speed of compiling
6. Ease of reading
These goals reminded me of my key attributes for a modern statistical programming tool paper.
Neil Brown - data on student errors
Neil Brown, who worked on Greenfoot and BlueJ (IDEs for novices learning Java) was there. He and I talked about a principle I have absorbed from Greenfoot, that novices should never be presented with a blank screen, but instead some scaffolding.
Brown has data on many students’ Java code from Blackbox, a way to capture data from students using BlueJ.
Next up, Neil Brown of @KingsCollegeLon on analyzing programming data. BlueJay is an IDE for Java beginners, Blackbox can capture data about it. They have data on 300 million compilations, which is— Amelia McNamara (@AmeliaMN) February 8, 2018
~3TB (compressed) of source code.
Teachers think they are good at predicting errors, but they actually are not.
Teachers are pretty certain they can predict what errors students will make. But, is that actually true?— Amelia McNamara (@AmeliaMN) February 8, 2018
This and many other great insights are in Brown’s slides.
Brett Becker - better errors
Speaking of errors, Brett Becker talked about improving compiler errors.
Becker: Error messages are accusatory and negative. Do we need to say “terminated” and “illegal”? “I’m going to get killed, and I’m going to jail.”— Amelia McNamara (@AmeliaMN) February 8, 2018
Felienne - what is programming?
I was delighted to meet Felienne in person after hearing Jenny Bryan talk about her, and following her on twitter for years. Felienne gave my favorite talk of the workshop, which ranged from her work on spreadsheets as programming to her more recent work teaching students about “code smells” in Scratch.
Felienne asked “What is programming anyway?”
She pointed out that while “every programmer ever” says that “Everyone should learn programming,” the community can be quite restrictive about what it considers to be “real programming.” Funnily enough, while everyone seemed to understand what she was saying, I also got pushback about my talk.
Often, we put users in one category and programmers in the other. But, there are many people who are “swimming in the water” of programming, and don’t even know they’re doing it. People who work deeply with spreadsheets are programmers, but they wouldn’t describe themselves that way. Again, this had reverberations with the scientists programming stuff I talked about.
Felienne asked us two questions:
One answer to “what is programming like?” is writing.
I’ve used it a lot, so I think programming as writing is a pretty robust metaphor.
Baker Franke - teachability and learnability
Another person I was delighted to meet was Baker Franke of code.org, who it turns out worked on the Exploring Computer Science (ECS) project before I joined it as a graduate student. At some point, I used the phrase “data the students can see themselves in” and he mentioned he’d written something about that in the early ECS curriculum. I’m now certain that’s where this idea (which I have fully integrated into my worldview) came from. It’s always fun to pin down those influences.
Franke’s talk was also great, and teased out the subtle differences between learnability and teachability of a language.
We’ve been expanding our definition of language properties at #dagstuhl. @bakerfranke adding “teachability,” although he says this might not be a problem for language designers but a problem of pedagogy. pic.twitter.com/b1HlrgUJyH— Amelia McNamara (@AmeliaMN) February 7, 2018
He echoed my feeling that consistency in teaching is so important (the reason why I teach only one R syntax in my intro classes)
He also has an idea about scaffolding in language design,
This was just a selection of the talks that related most directly to my interests. If you want to see the rest of them, they are posted on the seminar materials page, and for more context on the people who attended (not all of whom presented), you can read everyone’s introductory slide, and check out the twitter list I made of all the participants who are on twitter.
More than talks
But, of course the point of the Dagstuhl was not just talks. It was making connections with other researchers. At every meal, we were assigned random seats to help us meet more people. We had structured time to think about programming language design studies we would like to see (thanks, Baker!) and time to discuss in groups. At the end of the last day, we developed a massive spreadsheet of current projects, future projects, and resources. I can see at least five potential projects I might lead or become involved with. The types of things I think about in terms of teaching statistics and R seemed to fit right in with the questions others at the workshop were asking– a novel feeling!
I know I’m not the only one who feels this way. Several other folks have already written up their thoughts on the seminar, including Andy Ko, Brett Becker, and of course Felienne’s liveblogging. Johannes Hofmeister captured his ideas on video,
Me, trying to capture all my ideas from the Dagstuhl seminar. Not a time lapse, actual speed of thoughts :D pic.twitter.com/kDolr7e8gb— Johannes Hofmeister (@pro_cessor) February 11, 2018
I can’t wait to see where things go from here.