next-generation programming language, currently in development

Twitter . GitHub . RSS

Semantic editing makes programming faster and easier than text editing

I decided to do a head-to-head speed test comparing the current Unison editor to raw text editing in Vim. Below, here’s me writing the same code in the Unison editor and in Vim, typing at similar speeds, strictly using the keyboard with both:

Overall, they are pretty close. The Unison editor wins out by a bit in this run, but I did other runs where the text editing was a bit faster. Here’s my analysis:

None of these factors are all that significant though. If you look at what programmers spend their time doing when programming (other than thinking of course), it’s actually stuff like:

These are the areas where Unison starts winning. In Unison, there are no imports, type-directed search is tightly integrated into the editor, documentation can be displayed inline (imagine a slide-out panel in the explorer, for instance), there’s no compilation phase the programmer ever waits for, no compile errors to decipher and errors are caught earlier, refactorings can be nicely integrated, and so on.

Although none of the individual features here are particularly new, Unison can put it all together into a tightly-integrated, cohesive experience. Besides just the direct time saved of each individual feature, there’s also the (highly nonlinear) improvements in programmer flow due to not needing as many context switches.

But it’s not just about time savings. The semantic editing experience just feels overall easier. It feels like snapping a puzzle together. There’s less to think about. Fewer arcane details of the tooling. Though it’s not currently a primary goal of Unison, I could imagine teaching some version of this environment to a kid in middle school, or a spreadsheets user, and not feeling like I needed to apologize constantly. The current programming experience is needlessly complicated, and it doesn’t have to be.

comments powered by Disqus