What’s a “thunk”?

I remember when everyone started talking about using “thunks” in Redux to execute code without blocking the UI. And I remember getting tripped up on the word “thunk”. What’s a “thunk”? Why are we calling it that? The term “thunk” goes all the way back to ALGOL 60! It’s a play on “think”, because the ALGOL compiler needed to “think” about what sort of subroutines to generate. ALGOL allows passing expressions as arguments to subroutines, not just constants.
Read more →

Don’t use mocks

Writing good unit tests is made much easier by dependency injection. This lets you separate your code’s behavior from that of your dependencies.

Many people use mocks to add dependencies to unit tests. I think this is usually a mistake.

Read more →

Looking in Go’s Mirror: How and When to use reflect

This article was originally published on gopheradvent.com

reflect can be intimidating to new Go programmers because it’s very generic and you lose access to many niceties in the language. But it doesn’t have to be. Let’s build some programs that use reflect as a way to demystify the package and illustrate the power and pitfalls that come with using it.

Read more →

What is software for?

In the last blog, I wrote a few things that software is for:

  • putting people on the moon
  • safely deploying airbags
  • making my bank account add up

Read more →

Code is not Prose

Once a month or so, this idea comes rambling out of the programming community1: Software is prose. It is written to communicate ideas to others, it has the interesting side effect that it can be transformed into something a computer can execute. - Chet Hendrickson This sounds nice on paper. It makes for a good conference talk about how to structure software, how to design programming languages, and how to collaborate.
Read more →

Nasty refactorings with go.mod replace

At work I’ve been building a new program on top of an SDK that’s under very active development. After about 6 weeks without updating the version, the SDK had deleted some code I was using and had a ton of breaking changes. If I’d simply updated the library, my entire program would fail to build, and it also wouldn’t be clear how to get it back to a good state. Following in the spirit of Branch by Abstraction, I’d rather introduce the new code side-by-side with the old and incrementally migrate without breaking the program.
Read more →