Paul Chiusano

Functional programming, UX, tech, econ


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 the worldwide elastic computer (coming soon)
Type systems and UX: an example
CSS is unnecessary

Unison update 6: refactoring, technical debt, and motivation

No new screencasts to show this week. I’m in the middle of doing some much-needed refactoring. What happened? As of the last update, I had a decent expression editor. The missing final piece was adding a declaration layer to the editor, allowing a Unison panel to be edited much like a module in a regular programming language.


I hate type errors!

I hate type errors!


Unison update 5: a better spreadsheet

Here’s a video of the latest progress. In this video, I create the term view reactive (1 + 1), which displays in the editor as 2. This might not seem like much, but the ability to define reactive views like this is the first step in allowing Unison panels to be used much like a spreadsheet, where the user fills in values and other parts of the panel are updated in response. There’s also a few other things shown which I’ll talk through below:


Unison update 4: more editor interactions

Here’s a video of the latest progress. Watch me write the expression 1 + 1, then evaluate it!! Further explanation below.


Keep your data types dumb, layer on properties after the fact

When programming in a language with a nice type system, you often have the option of defining ‘smart’ data types which bake some invariant in as an index of the data type. But sometimes, it can be better to keep your data types dumb, and layer on invariants after the fact. The lesson generalizes, but I’ll show an example—well-formed lambda calculus terms: