Unison programs are viewed and edited in the browser. The frontend (which does things like code layout) is being written in Elm which talks to a backend (which does things like typechecking) written in Haskell.
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.
In this old but relatively unknown paper by Tim Sheard, he describes a pure language which is strict by default but optionally lazy. Sounds boring, but there’s a twist: strictness is not tracked in the types, and there are a few annotations which make it possible to write code which is polymorphic in its strictness. This post is an exploration to see to what extent this addresses the problems with strict by default evaluation (nicely covered by Lennart Augustsson). Summary: it helps a bit in some cases, but laziness still wins.
I was watching this video about No Man’s Sky, a game that’s being advertised as “a science fiction game set in an infinite, procedurally generated universe”. One of the creators mentions here that each planet in the universe of the game is fully determined by a single 64 bit seed. From this one seed, every “every blade of grass, tree, flower, creature” is generated, and it’s all done lazily, as the world is observed by the player.