The SPLASH conference is a programming languages and software engineering conference sponsored by ACM SIGPLAN and SIGSOFT. Prior to 2010, this conference was known as OOPSLA (Object Oriented Programming, Systems, Languages, and Applications).
SPLASH 2020 was held from Nov. 15 to Nov. 20, 2020 as a completely virtual conference.
I viewed most of the keynote talk and many of the industry-focused presentations (now called the SPLASH REBASE track). I also helped organize a panel session for the SPLASH-E program (educator forum), which was held on the last day of the conference. As a virtual conference, the sessions were able to accommodate a wide range of interesting research. There were several good presentations that discussed “testing” - including tools to support test generation, code analysis, and management for large systems. One ongoing theme throughout the conference was a discussion of effective testing approaches for compilers and other language tools.
Four of the most interesting technical talks:
Vitek’s talk was on a topic of interest to practical academicians: “How to Hack Academia to Build Stuff.” He thinks that the current focus on publication metrics creates a disincentive for university researchers to “build things.” The metrics that drive university tenure and funding agency decisions are too focused on publications and not enough on building code artifacts that are useful and influential. In programming languages research, we want to build good artifacts (such as compilers, garbage collectors, and analysis tools). But we are diverted into the game of writing many small papers for theory conferences in order to improve our “h-index.” Vitek’s talk had several constructive suggestions for how professors and conference organizers can work within the system to improve the ability of researchers to showcase really good implementation work. Vitek’s talk is available on YouTube: How to Hack Academia to Build Stuff video.
A lot of commercial internet software is built up from many Web services, where each service has a published API which can be used to make service calls from “apps” written by developers within the same company, from other partner companies, or from outside commercial app developers. Not surprisingly, many apps can break when an API is modified or extended. Many applications use hundreds of APIs, so a manual modeling process is futile - we need tools. The Akita approach to the API problem is to collect data about the patterns of API calls while the system runs, then run a special analysis tool to go through the data to infer the “specifications” of each API. It looks like a very clever approach, and it uses the fact that most Web APIs are very constrained and they usually don’t have any dependencies on state. There is more inforamtion about their approach at the Akita Software website: https://www.akitasoftware.com.
Bell’s talk explained the history of his research in effective automated testing in Java, with a specific focus on creating a good runtime test environment that provides good isolation for each software test without creating a lot of runtime overhead. He worked on the development of VMVM - a replacement for the standard Java Virtual Machine. Bell also explained some of the Java security analysis tools he has worked on. There is a link to the video of Bell’s talk on the SPLASH conference program website: Catching More Bugs video.
Berger’s talk described two profilers: Coz and Scalene. Coz is a profiler for C, C++, and Rust that is aimed at multi-threaded applications - especially applications that are executing small blocks of code that are processing requests. It is designed to find opportunities to improve throughput and reduce latency by focusing on critical sections of the code. Scalene is a Python-specific profiler that helps search for possible performance improvements in Python applications - by analyzing which blocks of code might be rewritten in C to speed up an application. Berger’s talk (and 40 minutes of Q&A) can be found on YouTube: Performance Really Matters video.
There were several interesting talks in specialized computing areas. Mary Lou Soffa (Univ. of Virginia) gave a survey of techniques for testing Deep Neural Networks. Sriram Rajamani (Microsoft Research) explained several techniques for combining Machine Learning with conventional software development. Vikram Adve (Univ. of Illinois) presented a fascinating overview of the importance of software in agriculture, with an emphasis on the areas of software research that may help improve the software used in agricultural applications. Brandon Lucia (Carnegie-Mellon Univ.) presented his work on low-energy computing for small space satellites, including software tools for managing intermittent computations. And Kristen Yvonne Rozier (Iowa State Univ.) explored the future of flight software: the combination of methods, tools, training, and automation that will be needed to support the increasing amount of highly-reliable software needed for commercial aircraft systems.
Jonny Miller (Adzerk) delivered the best talk of the conference, and it wasn’t directly about languages or tools. Miller’s question was about a phrase we have been using for 40 years: Programming Paradigm. His question is: “Is a Programming Paradigm a Kuhnian Paradigm?” A video of Miller’s talk is available on YouTube: Paradigms Without Progress video.
This refers to the work of the mid-twentieth century philosopher Thomas Kuhn, who wrote the book The Structure of Scientific Revolutions in 1962. A “paradigm” is a shared worldview of a community of scientists - an accepted structure of what exists in the world, the methods that scientists use to discover new things, the rules of scientific evidence, the interesting problems that scientists want to explore, and the “shared values” of the scientific community.
A scientific paradigm can be relatively stable for a long time, and most scientists will succeed in doing what Kuhn calls “normal science.” The paradigm might at some point be disrupted when there are new problems and new data that don’t fit neatly into the current model. The classic example in the history of science is the change from the Earth-centered Ptolemaic model to the Sun-centered Copernican system in the 16th century. For a long time, the Ptolemaic view of the world was viewed as the simplest explanation for the motions of the Sun, moon, and planets, but the system needed to become more complex as more accurate observations of the positions of the planets became available. We can think of the elaboration of the Ptoemaic model as “spaghetti code” that became more and more untenable - people were more willing to jump to a new system, and the change was really a revolution in thinking.
The idea of a Programming Paradigm was introduced in 1978 by Robert Floyd (in his Turing Award acceptance speech), as a way to explain differences in language categories. Miller ask the question if these differences in “programming mindset” are really a paradigm shift in the same way as Thomas Kuhn describes. Miller’s conclusion is no - because the new paradigm doesn’t replace the old paradigm, and in fact, we are able to use multiple programming paradigms in combination in writing new applications.
Also, we don’t think of Programming Paradigms as “progress” - one paradigm doesn’t “win’ and clear out all work in the old paradigm. Miller thinks that our computer programming might be in a pre-paradigm phase.
After disposing of the main question, Miller finds another way to talk about paradigms in the context of programming. Instead of “programming languages in a programming paradigm,” Miller thinks about an idea from Peter Naur from the 1980s: programming as theory building, and Miller focuses on what happens as programs are rewritten.
If we understand the “theory” of a program, many things are easier. We can respond quickly to questions like “Does this program support a specific feature?” or “How much effort will be needed to change the user interface?” If we are working with an evolving program, the code may get more difficult to change over time - the “theory” of the code may be starting to get cracks and instability as the code adapts to new uses. We “lose faith” in the code. Eventually, we may choose to have a “revolution” - a complete or partial rewrite of the code, leaving the old theory behind.
In the remainder of the talk, Miller outlined some other ideas from philosophy that have been important influences on computing, from David Hilbert and Bertrand Russell to Rudolph Carnap’s work on the logical analysis of languages and Michael Baxandall’s philosophy of “patterns of intentions” in painting and the visual arts.
I enjoyed the presentations in the SPLASH-E session this year. The main two events in the SPLASH-E session were a discussion with a Black female faculty member (Nicki Washington from Duke Univ.) and a panel session on how well we are all dealing with the COVID crisis (“Engineering for Chaos - Lessons Learned from COVID-19”).
The keynote presentation was a discussion between Prof. Washington and two members of the SPLASH-E organizing committee - focusing on diversity, equity, and inclusion. The main message was that university leaders (administrators and department heads) need to send a clear message about what is unacceptable racism or sexism in the university environment. The good news is that the young generation is pushing for improvements, but there is still a problem... no real penalties for faculty members who aren’t buying into the actions to foster a more inclusive environment. There was also some useful discussion about how to teach about “algorithm bias” early in the computer science curriculum.
The panel was moderated by Steven Fraser (Innoxec), who has been the organizer of many OOPSLA/SPLASH panels in the past. The panel session began with some observations by Moshe Vardi (Rice Univ.) - Vardi has given several presentations about the critical idea of the “resilience” of a system - and the problems caused when we abandon resilience for efficiency. This point was included in the panel session overview:
The global COVID-19 pandemic has transformed the way we live, learn, and teach - impacting both “how we learn” and “what we learn.” The initial pandemic reaction was to transition to a “work/learn from home” model to reduce pandemic exposure and the risk of infection for our colleagues and families. However, the changes have gone deeper with shifts in the software marketplace and in education. Companies and educational institutions once had a single-minded focus on correctness, cost control, and system performance to deliver “cheaper and faster.” But now in a pandemic constrained economy, security increasingly needs to accompany algorithmic correctness. Similarly, the value of robust and resilient systems that scale and reliably meet demand has increased over those that simply optimize for performance.
Resilience is a critical concept to learn and adopt as a strategy - and it is almost the opposite to dimensions of “high-performance.” In addition, the challenges of virtual collaboration are endless - and team members must be increasingly aware of unstated assumptions about culture, norms, communication styles, and beliefs in order to make collaborations and the user experience safer.
The other panelists were Rebecca Mercuri (Notable Software, also an expert on election systems), Landon Noll (a professional astronomer who has worked for several computing companies), and Aleš Plšek (Netflix). Each of the panelists had some reflections on how the search for reliability has impacted their areas of expertise.
There was one more interesting short paper in the SPLASH-E session: Elisa Baniassad (Univ. of British Columbia) presented a paper titled “Group Harmony Visualization at Scale.” This paper explained an approach for monitoring the potential interaction problems in small group projects within the context of a large university software course. Most professors and teaching assistants don’t have enough time to monitor all of the potential group interaction problems in a class of 200 students, so this team created a short online web app for students to enter weekly reports on their group's progress. The paper describes some interesting results from analyzing the student-provided data - which as worked quite well to detect early problems in the teams. Because of the size of their dataset, they decided to create some useful “visualizations” to scan the data for key patterns. The most important thing in the analysis is to look at divergence between the data across members of the same team, which can be an indication of poor team dynamics.
The tentative plans for SPLASH 2021 -- it will be back in Chicago, Oct. 17-21, 2021. Check out https://2021.splashcon.org/ for more details.