In the defense of old tools

Often, having new tools — programming languages, editors, templating systems, etc. — is beneficial. The world of computing has advanced in great leaps over the last 50 years, and what was useful in 1970, or even in 2000, might be looking a bit long in the tooth today… With Go and Rust around, I would think twice about starting a greenfield project in C++…

That said, sometimes an old tool is just good enough, and widespread enough. Carpenters’ hammers have looked the same for hundreds of years, and are still perfect for the job they have been “evolved” to do. There is no shame in using a simple $5 hammer instead of something battery-powered with “Makita” written on it.

I work on blockchain technology as a day job — it’s both fascinating and frustrating to be at the forefront of such a relatively new technology. Much of the tooling is still immature — even the “mature” parts. A few years back I wrote an article about how inadequate Solidity, the Ethereum ecosystem’s flagship language is for any mission-critical work… It’s successor, Vyper, while far superior, still suffers from a lack of features necessary for many real-world projects. Or, in the Tezos ecosystem where I spend most of my time these days, we have LIGO — a nice functional smart contract language with a compiler that, at the moment, just isn’t as feature rich as I would prefer.

When working in a relatively immature ecosystem, you often have to bring or build your own tools. There’s no mature end-to-end toolchain ready to compile, deploy and unit test everything at the push of a button. And this is where venerable tools come into the game. In my article on large-scale dApps in LIGO, I mentioned we decided to use m4 templating instead of the LIGO compiler’s vestigial preprocessor. It’s a clunky old tool, but so far, it’s been really good at what we wanted it to do. If it can handle Sendmail configuration, it can handle our few parametric macros…

Soon after, we realized we want to do maths in the preprocessor, to define constants in a way that describes their meaning and purpose. When reading code, it does matter whether you see 2⁶⁴ or 18446744073709551616. And blockchain applications tend to have really big integers — in Ethereum an int is 256 bits, in Tezos it’s arbitrary size. That tends to be too large for most tools, even modern ones… But bc, an ancient command line calculator from the POSIX standard can do arbitrary size ints with no sweat… and it’s really easy to call bc from an m4 macro.

We have POSIX tools, so why wouldn’t we use them? They are literally just sitting there. They are venerable, simple, and ubiquitous, like a carpenter’s hammer. Sometimes it totally makes sense to find a modern, complex solution for the tasks you want to solve — but sometimes, the solution is literally at your feet, you just need to reach out and grab it.

There’s two kinds of programming: functional and dysfunctional.