Lindsey Kuper

I’m going to be on stage a couple of times at the SPLASH conference this October in Pittsburgh. If you’ll be there, please say hello!

Prospect at SPLASH-I

First, I’m excited to announce that I’m giving a talk in the (free!) SPLASH-I track, which consists of invited talks by industry researchers. My talk, “Prospect: Finding and Exploiting Parallelism in a Productivity Language for Scientific Computing”, will be the first public talk I’ve given about work we’re doing at Intel Labs since I joined the Programming Systems Lab a year ago, and I’m very happy to have the opportunity to share it! Here’s the abstract for my talk, which is tentatively scheduled for afternoon on Thursday, October 29:

Computational scientists often prototype their software using a “productivity” language such as MATLAB, Python, R, or Julia. However, to run this code effectively on a high-performance computing system, the code is typically rewritten in “efficiency” languages like C/C++ or Fortran. This rewriting process takes considerable time and expense and often results in brittle code, with which it is harder to experiment. Domain-specific languages (DSLs) are one well-regarded solution to the efficiency/productivity trade-off, but it is difficult to design a DSL that can anticipate any use case that the programmer will eventually encounter. We have developed Prospect, a compiler for the Julia programming language that attempts to bridge this productivity-efficiency gap in scientific computing. Prospect discovers and exploits the implicit parallelism in source programs that use parallel programming patterns. For the most part, these patterns are already present in standard Julia, so programmers can use Prospect to compile Julia programs with only minor changes to source code. Our results show that Prospect enables 5-100x speedup over MATLAB and 10-250x speedup over plain Julia on a variety of scientific computing workloads, without requiring the programmer to extensively rewrite code or limit themselves to what a DSL offers.

(The “we” in this abstract, by the way, refers to a large number of people at Intel – this is a big project, and I’m merely one contributor to it.)

Again, the SPLASH-I track is free, and there are lots of really interesting-looking talks – I’m hoping many Pittsburgh locals, as well as the out-of-town SPLASH crowd, will be able to attend!

The future of programming languages and programmers

Second, on Wednesday the 28th I’ll be participating in a panel discussion on “The Future of Programming Languages and Programmers”, organized by Steve Fraser and with a distinguished lineup of panelists, including Lars Bak, Rob DeLine, Nick Feamster, Crista Lopes, and Peng Wu. I’m by far the most junior of the panelists – Peng and Crista alone have more years of research experience between them than I have years of being alive – so I expect to be spending most of my time on this panel just trying to soak up wisdom from everyone else!

As preparation for the panel, Steve invited us all to reflect on an excerpt of a talk given by Fred Brooks in 2004 to commemorate the 40th anniversary of the IBM System/360. In the excerpt, which starts at about 1 hour and 19 minutes into that video, Brooks relates how the OS/360 job control language, or JCL, ended up being “the worst programming language ever designed”. We were each asked to write a “position statement” for the panel, and so the first paragraph of mine is inspired by that tale, while the second paragraph is a response to the panel abstract’s claim that “Over the years – somewhat surprisingly – programmers evolved from engineers at the pinnacle of their profession with many years of experience to individuals not yet 10 years old giving evidence that programming does not necessarily require a formal education”:

The moral of Fred Brooks’ story about “the worst programming language ever designed” is that it behooves us as programmers to approach certain problems as language problems from the start, since those problems will end up being language problems anyway. To that end, I would like to see a future in which all programmers are empowered to think of ourselves as language designers and implementors. By that, I do not mean that we all necessarily ought to go out and start our own large-scale language projects from scratch. Rather, I mean that we should teach programmers to appreciate how the implementation of every language is ultimately just another program, written by other humans; that we should gravitate toward languages that are easily extensible, and toward languages that allow and reward messing with their inner workings; and that we should be thoughtfully critical of the tools we have, and of new tools that come along, rather than merely accepting them as they are handed to us.

Is programming more accessible today than in the past? First of all, it depends on how one defines “the past”; in the 1940s, programming was seen as clerical work, and it wasn’t until about fifteen years later that it began to be taken seriously as an engineering discipline. Starting around 1980, programmable microcomputers became a mass-market product, which did good things for the accessibility of programming. But today, although mass-market computers are cheaper and more ubiquitous than ever, most of the interesting computation is done in the cloud, on large-scale, institutionally-owned hardware. The challenges I see for programming effectively in such a world include dealing with quantities of data too large to fit on any single machine, and reconsidering old assumptions about the consistency of network connections or durability of storage media. On this panel, I look forward to discussing how the future of programming could address those challenges, and which other challenges we might be neglecting to take seriously today that will be important in another fifteen years.

I’m not very big on making predictions about the future of programming languages and programmers, but these are things I feel comfortable saying. (Thanks to Graydon for helping me collect my thoughts.)

Onward!

Finally, while I’m at SPLASH I’ll be attending as much of Onward! as I’m able to; I had a lot of fun serving on the program committee for it this year. One paper I’m particularly interested in is “Isolates, Channels, and Event Streams for Composable Distributed Programming” by Aleksandar Prokopec and Martin Odersky, but there are several others that look great, too.

Comments