Brooks, Wirth and Go.

It’s 1975.

The programmers have come back with the FORTRAN code, now in punch card form. The cards are taken back, with great consideration as to not to drop them, over to the mainframe. By the time they’ve been fed in, read, compiled, linked and executed by the computer, it has taken more than a week for the result to come back "[File name specification error]". At this stage, the code has touched the hands of a lot of people, consuming weeks of work hours.

Meanwhile, another engineer programming in Smalltalk and Interlisp is writing and running their implementation directly against a system console. After a few seconds, they have their result. “Ah” they go, fixing their mistake right then and there. Done.

The differences in turnaround time between these two approaches is on an order of three magnitudes.

Forget about a “10X programmer”, how about a “1000X programmer”?

As the hardware of modern computers has evolved to being hundreds of billions times faster than the ones that put humans on the moon, these type of discrepancies have shrunk drastically. Gone are the days of timesharing, of waiting hours for even simple computations to return a result. Even cellphones are powerful enough to calculate every computation humanity had computed by the 20th century put together.

Software, hasn’t perhaps moved forward as much. One could argue that not much have happened to solve the software crisis since ALGOL 68. Perhaps even worse is how little we have (collectively) learnt from the giants of that era. I want to exemplify two of these giants, and the lessons they can teach us.

Brooks.

Frederick Brooks
In 1964, IBM announced its most ambitious project to date: the IBM 360. The project was architected by none other than Gene Amdahl, and managed by Frederick Brooks.

It was the worlds first real programmable mainframe computer, opening up the notion that computers could be reprogrammed to suit new problems instead of being replaced by newer models. The architecture of the system introduced a lot of standards that we still use today, such as 8-bit bytes, 32-bit words and more.
Frederick Brooks

What is perhaps even more interesting, was the project itself.

The project was … more expensive that what was first thought. It blew the budget by a factor of 200; from $25 million to $5 billion. For reference, the Manhattan Project was budgeted for $2 billion.

The project ran into every development- and management problem that you can think of.

Years after, Brooks decided that the best way to answer the question "why do software projects so often go awry?" would be to write a book about his experiences and lesson from IBM. That book was the now fabled The Mythical Man Month.


It's perhaps one of the best reads on software management there is.

One essay from it is ‘No Silver Bullet’, which states that:

'There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.'

Given how quickly a modern programmer could correct their mistakes compared to their punch-card predecessors, Brooks contended that the majority of remaining complexity was the problem itself, and that accidental complexity had mostly been solved.

That is not so say that productivity hasn’t increased since the 60s. On the contrary.

Take these examples:

Together, they have pushed our overall productivity to great heights. They’ve also re-introduced a lot of the accidental complexity that our predecessors fought so hard to remove in the first place.

(more on this later)

"Programmers aren't quite as productive these days as they used to be".

This notion of reducing accidental complexity to the bare minimum is the key to a lot of our problems, and there is no greater champion of this principle than Niklaus Wirth.

Wirth.

Niklaus Wirth
Having created PASCAL, MODULA and MODULA-2, Wirth set out to develop the OBERON family of languages in order to build his operating system on his workstation.

To say that Wirth accomplished a lot of great things in his career would be an understatement, and the examples given above are a fraction of his achievements.

He managed to execute on all these ideas by following a set of principles that can be summarized as follows:
Niklaus Wirth


You have to completely comprehend your idea in order to fully realize it.
'The language Oberon emerged from the urge to reduce the complexity of programming languages, of Modula in particular. This effort resulted in a remarkably concise language. The extent of Oberon, the number of its features and constructs, is smaller even than that of Pascal. Yet it is considerably more powerful.'

The man concluded that Pascal was too complicated. Pascal.

With his newfound power, he built his operating system on top of his own hardware from scratch in 12K SLOC, with a footprint of 200 kilobytes. For comparison, OSX runs in on ~86M SLOC with a footprint of 3 gigabytes, built by one of the wealthiest companies in the world. Now, perhaps OSX is more feature complete than Oberon, but certainly not by a factor of ~40 000X. Something was lost along the way.

Where Brooks notion of ‘No Silver Bullet’ and the philosophy of Wirth intersects is here:

'You cannot reduce the complexity of your problem by increasing the complexity of your language.'

The greater the surface area of your language, the more gusts of sand there will be to hide its essence. At some point, the needle has moved forward to where the cycle starts over as a subset of the old becomes the new and the cycle starts over once again.

This notion of ‘less is more’ reminds me of a quote of the same nature, from another giant:

'There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.'
~ Tony Hoare

Rejecting Wirth’s premise in theory inevitably leads to Hoare’s second option [0].

'Somewhere between Objective-C and Swift1-5 you ended up with one framework from the past, one framework from the future, and one tangled mess in the present.'

What are the costs of taking this route?

The stones that bind us.

With the exception of the Gray Beards and perhaps kernel developers, the industry at large tends to be unaware, ignoring or rejecting this premise. Instead, each revolution of the wheel is spun until it arrives exactly where it started, with the promise of new beginnings.

Luckily, there are exceptions. Here’s one of them.

Go.

This wonderfully tiny, famously “stuck in the 70s” language, ticks all the necessary boxes to avoid most (if not all) of these issues, and draws inspiration from older languages but with a modern touch.

It was designed by Ken Thompson, Rob Pike and Robert Griesemer (a student of Wirth). The introductory book to the language was written by none other than Brian Kernighan. If it’s not already apparent, this language is the spiritual successor of C.

It’s been two years since I first picked up Go, and I can’t think of anything better for general[1] software development, especially when it comes to respecting the time of myself and others. It’s one of the few languages that allows me to program freely, without having to consult the internet or prod others who have more experience in it for things that should be self evident. There is less magic, less hiding, which yields much, much greater clarity. No surprises, ‘it just works’.

This isn’t to say that everyone feels this way, on the contrary. Critique is abundant. The discussions about Go’s missing features (say, lack of generics) have going on for years (more than a decade by now), which I can only assume will keep on going for the unforseeable future.

In the meantime, I urge you to give it a Go. Perhaps you’ll like it.

Fredrik Holmqvist



[0] "For none of the evidence we have so far can inspire confidence that ADA has avoided any of the problems that have afflicted other complex language projects of the past ... I believe that by careful pruning of ADA, it is still possible to select a very powerful subset that would be reliable and efficient in implementation and safe and economic in use ... that is the great strength of PASCAL, that there are so few unnecessary features and almost no need for subsets."
Tony Hoare's 1980 ACM Turing Award Lecture

[1] There are of course better languages for specific types of software.