Richard Barrell argues that static typing's fall and rise across two decades had little to do with fashion and everything to do with tooling quality. His shovel analogy reframes a tired language war as a story about whether the machine was ever actually helping you.
Programming culture loves to narrate itself as a sequence of fashions. Object orientation gave way to functional purity, monoliths gave way to microservices and then crept back, and somewhere in there static typing fell out of favor only to return with a vengeance. Richard Barrell, in a short essay titled Static types and shovels, proposes a more materialist explanation for one of those swings. The popularity of static typing tracked not the mood of the industry but the actual quality of the type systems people had access to. When the tools got good, programmers picked them up. When they were bad, people reasonably preferred to work without them.
The central image is a digging task. If you need to move earth, you would obviously rather have a shovel than your bare hands, assuming the shovel works. But hand someone a shovel made of paper and the calculation inverts. The paper shovel collapses against the dirt, slows you down, and accomplishes nothing your hands could not do better. Barrell maps this directly onto the choice between dynamic and static typing. A dynamic type system is the bare hands case. The computer neither helps you reason about the states and contents of your variables nor actively gets in your way. You hold the entire model of the program in your own head, and you dig. A bad static type system is the paper shovel. It demands ceremony and effort while delivering almost nothing in return.
What made the early shovels paper
The essay names names. Early Java and C++98 are the paper shovels of the story, and the specific failures are worth taking seriously because they explain the era's skepticism. These systems could not distinguish a nullable pointer from a non-nullable one, which meant the single most common category of runtime crash sat entirely outside what the compiler would check. They offered product types, structures with multiple fields all present at once, but no sum types, the tagged unions that let a value be exactly one of several shapes. And they extracted a steep tax in keystrokes. Barrell's chosen specimen is the line BufferedReader bufferedReader = new BufferedReader(new FileReader(filename));, where the type name appears three times and the programmer learns nothing from writing any of them. You pay the full cost of annotation and receive almost none of the safety that annotation is supposed to buy.
Under those conditions the rejection of static typing was not laziness or trend chasing. It was a rational response to a poor trade. The Ruby, Python, and JavaScript ascendancy of the 2000s makes sense precisely because the static alternatives on offer were heavy and unhelpful. Dynamic languages let you stop arguing with a compiler that could not catch your real bugs anyway, and they let you write the code that actually did something without the boilerplate scaffolding around it.
What changed by the late 2010s
The return of static typing, on this account, is the arrival of shovels made of metal. Barrell lists the features that a modern type system reliably provides, and the list reads as a direct inventory of the old failures, now repaired. Every credible modern system gives you a way to separate nullable from non-nullable values. Haskell has Maybe t, TypeScript has T | null, Swift has T?, and Rust has Option<T>. The consequence is concrete rather than theoretical. The compiler can point to every place a null check is required and flag the one you forgot, and in day to day work the null pointer exception nearly vanishes as a runtime event. A whole genus of bug migrates from production incident to red squiggle in the editor.
The second repair is the arrival of sum or union types, which unlock the discipline Barrell summarizes as making invalid states unrepresentable. Instead of a structure carrying every field it might ever need, with informal rules about which combinations are legal in which mode, you model a state machine where each field exists when and only when the system occupies the relevant state. The illegal configurations cannot be constructed because the type system has no way to spell them. This is a different relationship to correctness than runtime validation. You are not checking that bad states do not occur, you are arranging the types so that bad states have no name.
The third repair is inference. The verbosity that made the old systems feel like punishment was never essential to static typing, only to its early implementations. There is no reason to write let x: number = 5 when the compiler can see that 5 is a number, and modern systems propagate that reasoning across large stretches of code so that annotations cluster at the meaningful boundaries, the function signatures and the public interfaces, rather than littering every local binding. The programmer writes the types that document intent and lets the machine reconstruct the rest.
The quiet second argument
There is a supporting thread in the essay that deserves more attention than its length suggests. Barrell observes that the value of putting information into a type system grew because of something happening outside the type system entirely. In the 1990s, IntelliSense was a marquee feature that distinguished Visual Studio. By the 2020s, method completion and inline documentation are simply present in every editor and IDE worth using. This matters because it changes the return on every type annotation you write. The same fact you encode to satisfy the checker now also powers autocompletion, refactoring tools, jump to definition, and inline error reporting. The type declaration pays out twice, once as a correctness guarantee and once as a productivity multiplier through tooling that reads those types and serves them back to you as you write.
This is the part that complicates any purely linguistic account of the shift. The type systems improved, yes, but so did the ecosystem that consumes type information. A type annotation in 2010 was a promise to a compiler. A type annotation today is also fuel for a dozen editor features that did not exist or were not universal before. The shovel got better and the soil also got softer, and both moved in the direction that rewards static information.
Where the analogy lands and where it strains
Barrell's conclusion is admirably restrained. A good dynamic type system is better than a bad static one, he writes, and the reason static typing returned is simply that we now have much better static systems than we used to. The framing dissolves the language war into an engineering question. It was never types versus no types as a matter of principle. It was a continuous judgment about whether the available tooling repaid the effort it demanded, and the answer flipped when the tooling crossed a threshold of usefulness.
The analogy has limits that the essay does not pursue, and they are worth holding alongside it. Digging a hole is a task with a fixed, legible goal, while the question of whether a type captures the right invariant is itself a design problem that no shovel metaphor reaches. Gradual typing systems like TypeScript and MyPy, both of which Barrell cites approvingly, complicate the binary further, since they let a codebase hold metal shovels and bare hands in the same hand at the same time, applying static guarantees exactly where they earn their cost and leaving the rest dynamic. That middle ground is arguably the real innovation of the recent era, and it fits the materialist thesis well. The tools did not just get sharper, they got divisible, so you no longer have to choose one posture for an entire program.
What makes the essay land is its refusal to moralize. It does not claim that the dynamic typing generation was wrong, or unserious, or following a fad. It claims they were holding paper shovels and made the correct decision about paper shovels. The people writing Haskell, Rust, TypeScript, and Swift today are not wiser, they simply have better equipment. If that is true, the lesson generalizes past types. Many of the practices we attribute to taste or culture are downstream of tooling quality, and they will swing again the moment something genuinely better arrives. The fashion narrative flatters us by making our choices look like expressions of judgment. Barrell's quieter claim is that we mostly just use whatever actually works, and that the history of a practice is often the history of its tools.
Comments
Please log in or register to join the discussion