Brian Hempel

brianhempel@uchicago.edu
Ryerson 178

3rd year Ph.D. student. I like building things, so I'm researching programming languages at the University of Chicago. More specifically: can we augment programming with direct manipulation interactions?

My advisor is Ravi Chugh.

I enjoy discussing programming UIs, programming pain points, and the future of programming. If you have any questions or comments or just want to bounce your crazy ideas around, shoot me an email!

Goals

Let's make programming great again.

Projects

I currently (June 2018) work on Sketch-n-Sketch, a direct manipulation programming system. There's some videos, a demo, and code online.

Presentation at UIST 2016

Publications

Deuce: A Lightweight User Interface for Structured Editing. Brian Hempel, Justin Lubin, Grace Lu, and Ravi Chugh. ICSE 2018. (slides) (video)

Semi-Automated SVG Programming via Direct Manipulation. Brian Hempel, Ravi Chugh. UIST 2016. (slides) (video)

Programmatic and Direct Manipulation, Together at Last. Ravi Chugh, Brian Hempel, Mitchell Spradlin, Jacob Albers. PLDI 2016. (slides) (video)

Service

LIVE 2018 Program Committee

PLDI 2018 Artifact Evaluation Committee

Faster Elm 0.18 Compiler

The Elm 0.18 exhaustiveness checker has exponential complexity for certain case statements. The following patched versions of elm-make tame this explosion somewhat and reduce Sketch-n-Sketch build times by 5x (or more). More nominal cases might see some slowdown instead of a speedup.

Replace your elm-make executable with one of the following binaries:

Class Projects

Context-Sensitive Prediction Of Haskell Type Signatures From Names. Brian Hempel. TTIC 31210 Advanced Natural Language Processing, Spring 2017.
A mostly failed experiment attempting to use RNNs to predict a Haskell type signature given the function name and the three prior type signatures in the file. A BS/MS student is building on this work—this report is placed online so there's something to cite. Though my experiment failed, I'm still optimistic about the motivation. Writing specs is hard—can we use semantic information in names to suggest specifications which could then be fed to a program synthesizer? Compared to regular code, specifications have that advantage that they are an unordered set of properties. You (the human or computer) can generate them in any order and may add and remove individual items freely (unlike additions and removal of code, which generally necessitates lots of reworking and cleanup). If I were to revisit this project, I'd reformulate the problem to predicting a set of properties rather than whole type signatures. To start, the return type would be a property in the set and the input argument types would each be a a property in the set (effectively, arguments would be treated as a set rather an ordered list). But by treating properties as elements of a set, you're not limited to just predicting types: you might predict properties such as "Is this function is recursive?" or "How long is this function?" or "Does this function preserve the input size?" and all of these other properties, along with the type properties, could form the specification of the function for static checkers or a synthesizer.

Personal

Humanity and the Limits of Computers

Computers can't pray.

Technical progress is not moral progress.

As your loved one dies, would you rather than a robot hold their hand?

Quantitative Work Ethic

Based on my personal time logs, I am currently 12.9% below the rate required to hit a target of 1879 hours this year.