Paul Chiusano

Functional programming, UX, tech, econ

TwitterGitHubLinkedInRSS


Consulting services

I offer Scala and FP consulting services. If you're interested in working together, please contact me.


About my book

My book, Functional Programming in Scala, uses Scala as a vehicle for teaching FP. Read what people are saying about it.


Popular links

Unison: a next-gen programming platform
unison.cloud: the worldwide elastic computer (coming soon)
Type systems and UX: an example
CSS is unnecessary

Why are we still programming like it's the punchcard era?

[   fp   unison   ]            

Here’s a scenario that’s familiar to most programmers: after making a seemingly minor program change in your text editor / IDE of choice, the compiler spews back at you tens or even hundreds of baffling compile errors. Even if you’ve gotten used to this sort of thing, there’s something a little demoralizing about it. I don’t particularly enjoy sleuthing around to figure out the root cause when the compiler is giving me a trail of seemingly unrelated clues. Compilers are often pretty bad at reporting the root cause of the actual errors.

This basic workflow - make changes, submit them to the compiler, and interpret any errors that occur - has remained largely unchanged since the punchcard era. Here’s another way of putting it: we start with completely unconstrained input in the form of raw text. We then submit a blob of this raw text to the compiler, which “parses” the text, and then typechecks it. Of course, most raw text strings are not valid programs – they don’t even parse, let alone typecheck! Thus, over the years, compilers and editors have become increasingly sophisticated at reporting back to the user where and how the user went wrong in this raw text, unconstrained input. Modern IDEs have tightened the loop, but the basic model is the same!

I am sure that error reporting will continue to improve along these lines, but here, I want to talk about a different model. Rather than starting with completely unconstrained input and having to decipher the inevitable parse and compile errors, let’s instead constrain the editing UI to only allow creation of programs that typecheck. I’ll call this the semantic editor model.

For example, if I would like to call the function squareRoot (which accepts numbers), and I am filling in the argument, a semantic editor would somehow prevent me from providing the string "hello!". This constraint raises some UX challenges:

With a little thought and imagination, all these fun problems are solvable. Moreover, these are the sort of fun problems I want to solve, because a semantic editor is a much nicer user experience, and potentially a vastly more powerful environment than plain text editing. Here are just a few other advantages:

I’ll say more about how the challenges of a semantic editor are being addressed in Unison in a later post.

Update: See here for a very early demo of semantic program layout, and some further discussion.

comments powered by Disqus