Crerar 291 It's a pandemic—email me.
6th year Ph.D. student in the PL group at UChicago (graduation target: June 2021). 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!
Let's make programming great again. The main thing I've learned so far in my graduate studies is that the languages aren't the problem, and the programming environments aren't either (at least not directly): it's the operating systems that are the problem. Unix and friends are decent abstractions and resource managers over the hardware, but are inadequate for facilitating communication between programs and inadquate for user-defined composition of programs. Unix brainwashed us into thinking that a pile of bytes is the correct medium for IPC. For my Ph.D, I'm still going to see if I can get output-directed programming working for functional data structures, but I no longer believe IDE work is the most important frontier for improving the experience of programming—at least not until we get the OS-level issues worked out.
If you have any insight or reaction to any of these, feel free to shoot me an email so we can both be enriched!
The number of core, orthogonal computational concepts (types) that programmers use is fairly small, probably on the order of about 100. Despite this, because UNIX mandated that everything is a list of bytes, none of these concepts have OS-level support. Instead, each application re-invents its version of those concepts, wasting programmer time and preventing users from composing their own workflows. Elevating these core concepts to have OS-level support for visualization and interactive operation could drastically improve the power of computers and the simplicity of software.
manpages was an okay idea for the 1970's. It's 2021. The UI could provide a lot more help. Though wires-based VPLs are not appropriate for general programming, such a VPL might make a good shell replacement.
I currently (January 2021) am working on my thesis project, Maniposynth.
Previously I worked on Sketch-n-Sketch, a direct manipulation programming system for creating programs that output vector graphics. There's some videos, a demo, and code online.
Presentation at UIST 2019. Unfortunately you have to pause and squint to read the code, but it is legible.
ManipML: Towards Bimodal Tangible Functional Programming. Brian Hempel, Ravi Chugh. LIVE 2020. (20min presentation)
Tiny Structure Editors for Low, Low Prices! (Generating GUIs from toString Functions). Brian Hempel, Ravi Chugh. VL/HCC 2020. (IEEE link) (technical supplement) (5min presentation ⬇) (slides)
Sketch-n-Sketch: Output-Directed Programming for SVG. Brian Hempel, Justin Lubin, Ravi Chugh. UIST 2019. (30sec preview ⬇) (3min video figure ⬇) (19min presentation) (slides) (poster) (artifact)
Output-Directed SVG Programming. Brian Hempel. MS Paper 2019.
Deuce: A Lightweight User Interface for Structured Editing. Brian Hempel, Justin Lubin, Grace Lu, Ravi Chugh. ICSE 2018. (17min presentation) (slides)
Semi-Automated SVG Programming via Direct Manipulation. Brian Hempel, Ravi Chugh. UIST 2016. (30sec preview) (5min video figure ⬇) (21min presentation) (slides) (artifact)
Programmatic and Direct Manipulation, Together at Last. Ravi Chugh, Brian Hempel, Mitchell Spradlin, Jacob Albers. PLDI 2016. (22min presentation) (slides) (artifact)
LIVE 2020 Organizing Committee
Convivial Computing Salon 2020 Program Committee
PLDI 2019 Artifact Evaluation Committee
LIVE 2018 Program Committee
PLDI 2018 Artifact Evaluation Committee
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.
elm-make executable with one of the following binaries:
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 built on this work—this report was placed online so there was 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 the 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.
Computers can't pray.
Technical progress is not moral progress.
As your loved one dies, would you rather than a robot hold their hand?