Hi folks, Paul here. One quick thing: Arya, Rúnar, and I will all be at Strange Loop this week and we’ll be presenting on Unison at the Unsessions Thursday night. If you are reading this and are attending Strange Loop or ICFP, I hope you stop by.
As for updates, we’ve been cranking away, and here’s what’s new:
Now that we have a batch mode compiler for Unison we’re thinking about how to make exploring and editing Unison programs a more interactive experience.
First, REPLs. Let’s face it, a REPL isn’t how you’d design an interactive editing experience today, even if you’re sticking to plain text:
Foo.hs, and decide you want to explore it a bit in the REPL. You now find yourself repeating some import boilerplate at the start of the REPL session just to get to the point where you can do anything useful.
All these issues have a single cause: REPLs place an artificial barrier between using or exploring a library and developing a library. When you’re developing the library, you edit your source file. When you (or your library’s users) want to quickly test it out, you use the REPL. In practice, there isn’t such a clear separation between these activities and forcing users to decide in advance is bad DX because the transition between REPL and a file is an annoying speedbump.
A better way to do things is to include interactivity in the basic model of program editing. Rather than your program being a static blob of text that must be given life via a separate tool, make the program a live creature that actually does things whenever the file is changed.
This isn’t a new idea at all… this is what a spreadsheet is, though spreadsheets don’t support abstraction well at all. However, we can take the basic idea of spreadsheets and apply it to a “real” programming language. Here’s an early result, which will be a component of the Unison codebase editor:
Using this interface is quite nice, even though it’s still rough around the edges. I was not even fully aware of all the sources of friction I listed above until I used a tool that stripped them away. It’s amazing how much low-hanging fruit there is if you take a step back and have a bit of a rethink about how you’d like things to work.
How does this relate to notebook-style interfaces? I’m not totally sure. Notebooks de-emphasize the dataflow aspect of spreadsheets and focus more on making the editing experience richer. I quite like their ability to embed both textual and graphical elements in the editor and think that’s an important thing to have in a program editor. Notebooks also get us away from the REPL problem of having to edit your program one line at a time. But I’d say that notebooks as they now exist maintain that separation between using a library and developing it. People end up sharing code by copy, pasting, and modifying existing notebooks, a lot like they do with spreadsheets. Why is that?
With a notebook, the definitions live within the notebook, rather than the notebook merely referencing definitions that exist elsewhere. That is, while a notebook makes it easier to develop code (since you aren’t confined to creating programs one line at a time), you can’t easily share that code with others in the same first-class way as library authors. This encourages an artificial separation between library authors and library users even though no such separation really exists. Library “users” get a nice interface to the library, but if they want to share their code in a first-class way, they need to switch to a different set of tools.
I’m interested to see how we can make this experience better in a language like Unison where many of the assumptions are different.
Comments are welcome, I’m interested to hear what folks think. What do you like or dislike about REPLs, notebook style interfaces, spreadsheets, or other alternatives to program editing and exploration?comments powered by Disqus