Revolution, Restoration and Revival

I had a splendid week away in Yorkshire catching up with some friends recently but all the fresh air gave me a stinking cold, so I spent time trying to revive instead of writing an editorial. Sorry, again. Prior to my week away, I attended the Software Craftsmanship Conference in London [SC18a]. Most of the talks are on their YouTube channel [SC18b] so you can watch at your leisure. The closing talk from Michael Feathers encouraged us to be creative and not be unhappy at work. He talked through a few company models he’d seen, focusing on new-ish start-ups, aiming to get stuff done that was interesting and covering costs, rather than aiming to be the next big thing and make a fortune. Michael was emphasising that programmers have an amazing skill set and can do all kinds of creative and useful things, if they allow themselves time to imagine.

Recently, we’ve seen a rise of hipster bars, artisan coffee shops and start-ups or cottage industries, so the possibility of trying new small-scale enterprises extends beyond programming. In many cases, these new companies are reviving dying old towns and cities. With larger companies closing, and high streets tending to ‘shut’, the so-called gig economy has driven many people to find new ways of working. People are still willing to pay for food and drink, creating an obvious marketplace for home-made food or small batches of niche beer. Though jokes abound about food and drink served in various strange ways, such as chips in mini frying baskets, beer in a boot, or scrambled egg with a comb from a shoe [BlackBooks00], while countless quips are made about avocados, this direction seems here to stay for a while. While in Yorkshire, we dropped off for afternoon tea in Hebden Bridge, a small market town that was invaded by hippies trying to escape the rat-run in the 1960s. In many ways, the range of shops was similar to hipster areas of London. The similarity between the old hippy scene and the new hipster scene was striking. However, don’t forget the hiring pro-tip: “Hippies are not the same as hipsters. I made this mistake once and now have a frontend framework written in Fortran” [@PHP_CEO14].

Trends often go in cycles; any current fashion is frequently a reworking of something that has gone before. Sometimes the economy drives changes, as alluded to by the move to the cottage industry and small start-ups in many places. We see trends and fashions in programming too. Kevlin Henney talked about Algol 86 at SCL. He’s given variants of this talk before, including once at last year’s ACCU conference. By coincidence, this issue has an Algol68 retrospective. Furthermore, Russel Winder recently commented on accu-general on old trends and techniques coming to the fore recently. For example, “Message passing over channels (or queues) between threads has to be The One True Way. Lots of people have been banging on about this for 40+ years, but it has taken 40 years for all the shared memory multi-threading people to admit defeat and come to their senses!” He also noted that despite different idioms between programming languages, “most programming languages are rapidly converging on a quasi-object, quasi-functional, with generics, coroutines, threadpools and fibres model. Which, of course, indicates we are due a new programming language revolution.” Many revolutions, particularly in programming, are re-discoveries or re-vamps of older ideas.

Despite the apparent convergence, different languages do have different approaches. We all spot C-style code in places it doesn’t belong. I still catch myself writing a for loop instead of a list comprehension in Python once in a while. Old habits die hard. Shoe-horning techniques into the wrong place is a recurring theme, with deep parallels to the craftsmanship movement. If you have a hammer, as the saying goes, everything looks like a nail. A true craftsperson will pick the right tools for the job. If they are restoring an old finely made cabinet, they need to know the proprieties of the wood, varnish, nails, and so on, as well as the right tools to use. I’ve noticed a few television programmes recently about antiques and furniture restoration, perhaps as a result of some afternoon telly while recuperating. An inappropriate restoration can devalue or even destroy an antique. It takes skill to be able to fix something. Just slapping some sticky-backed plastic or gaffer tape might hold parts in place, but spoils the look and feel, and possibly functionality of the piece.

Restoring an existing code base has similar problems. If someone tries to ‘fix’ code in an unfamiliar codebase, they might make things worse. A true craftsperson might be able to spot where something like an enterprise code base doesn’t follow natural language idioms, and work with the ‘grain’ of that particular code base more easily than someone with less experience. I could wax lyrical about the parallels between blacksmiths, saddle makers, cabinet makers and metal workers, and writing and maintaining code, but I’ll rein myself in. The analogies do work and in both cases we are talking about a skill, which takes time to learn, and is best learnt from a master. Books and online courses might get you started. A YouTube video may show you how to fix an oven element or replace a roof tile, but that’s many miles away from being a qualified electrician or being able to re-thatch a cottage. There is also an expectation that masters will be able to train apprentices. Can you mentor or teach someone? Another point that emerged at SCL was you know you understand something properly when you can explain it to someone else. That’s why some many of us give talks, or write articles. If you haven’t tried this yet, please do. The ACCU local groups can help and support you and the editorial teams for both Overload and CVu can nurture and encourage you if you want a helping hand.

A craftsperson uses their hands. Always. Programmers use their hands too. We type, sometimes we use a mouse. We draw diagrams, point (and sometimes laugh) at the code, we press buttons. Many other skills involve senses beyond just tactility. Metal and wood workers can hear the difference between something working well or being about to break. Attempts have been made to interpret and project code musically. We do talk about code smells as well. Sometimes code feels right, other times it seems more like the sticky-backed plastic hack. Can you explain what kicks off either feeling? Have a think for a moment. This kind of craft or skill is challenging to vocalise. I suspect it’s similar to trying to program a grammar checker. I mention that because I can see green wiggly lines as I type, where my word processing software is ‘trying to help’ and failing to parse a few of my sentences correctly. Trying to be exact about language is difficult. Trying to be exact about anything can be difficult. And yet, you know when you’ve managed to communicate with someone. You know when your mentee has ‘got it’; they then mentor someone else and you sit back and know your work here is done. Last time I mentioned trying to assess the progress of a mentee [Buontempo18]. I couldn’t find any precise metrics, and now suspect that’s the way it goes with crafts.

As a final note on the craftsperson metaphor, consider the process of making or restoring a thing, either code or something more physical. The BBC’s recent ‘Made in Britain’ observed a skilled artisan or craftsperson has a hand in the product from start to end. Some companies talk about the software development lifecycle, expecting more senior devs to be able to step beyond the differences between a for or while loop and talk about how to build and release a product. A really skilled developer can also revive and restore a product once it has been realised. This might include bug fixing, as well as adding new features. I suspect there’s a similarity between new features in code and up-cycling old furniture. I’ll leave the reader to work out a quip about the trendy ‘distressed’ look, wherein an old cupboard or chair is sandpapered to look even more beaten up, then whitewashed and sold for a fortune, and a code based being distressed or even distraught, or bugged, if you will.

In addition to furniture/code, restoration, revival and repurposing, we briefly touched on seasonal fashions reoccurring, meaning many revolutions are just that. What goes around comes around. Coroutines, functional programming, Algol68 or similar, roll back into view regularly. Ideas revolve. I have observed some fashions tend to pop up every other generation. Parents hate tattoos, so the rebellious teenagers start to love them, only to discover Grandma was a painted lady displaying her fine covering of art work at fairs and fashion shows years ago. I wonder if programming paradigms and languages do likewise. The youth don’t know the new trendy stuff happened before and yet Grandad can tell them all about it. Perhaps we could spot some patterns and make predictions about the future. For sure, the next revolution will not be televised, but stream live on some app that doesn’t exist yet, no doubt. When Overload had proper editorials, Rik Parkin suggested ‘The Computing Revolution Will Be Televised (Again)’ [Parkin12], noting that 30 years ago we had to plug our first computers into the TV. Raspberry Pi anyone? He ends by saying, “Nostalgia has never been more cutting edge.”

By looking into the history of a discipline, we can find trends and try to see where things are heading. I tried to find a definitive list of breakthroughs in computing, though this strays into the realms of opinions all too easily. I did find a time line [Aaronson14] Scott Aaronson, a quantum computing expert, compiled for MIT’s 150th anniversary. He lists when the top 150 innovations happened (I know that’s more than 150 – I checked).

Things appear to have tailed off, with a slight uptick when the internet hit the streets. So much of the history entwines with the history of mathematics, and has occasional outburst of skilled craftspeople or engineers managing to build a machine capable of increasingly precise and complicated movements. Games and viruses also get a mention. I don’t think any patterns were obvious, so don’t have any predictions of what to look out for next year. As I read the blog, I realised I am not up to date with cutting edge mathematical research, though I do keep my eyes open for trends in machine learning. An area I know little about is quantum computing. I did learn one thing from the blog headline: “Quantum computers would not solve hard search problems instantaneously by simply trying all the possible solutions at once.” If anyone would care to write a slightly longer summary for Overload, you know what to do.

Now, Scott mentions viruses. In my attempt to track down old trends that are being revived, I did a random walk through the C2 wiki and fell across the ‘Worse Is better’ page [C2]. Part way down, C is described as a virus. This caught my attention. This comes from a paper by Richard Gabriel, where he describes early Unix and C as examples of the ‘Worse is better’ school of design [Gabriel94]. This principle prioritises simplicity over correctness. He says it means,

that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven’t they? Unix and C are the ultimate computer viruses. [my emphasis]

He notes that the virus must be “basically good” in order to spread or gain traction. Once the programming language or approach is prevalent, people will then spend time ironing out some of the flaws. He finally concludes C is the wrong language for AI software. It appears that Python is gaining traction here, though I suspect Richard was suggesting Lisp is the right tool for the job.

If we use a compiled language, like C, we make things (or cmake them or use scons). Even if we use an interpreted language, we are still being creative. I have no idea where this will go next, but the journey is interesting. We are creative and have lots to offer. If you don’t feel like part of the next revolution, take a restorative, and allow yourself time to revive. Cheers and Happy Christmas (assuming you are reading this just after it hits the decks). Or failing that, Happy New year. Viva la revolution!

References

[@PHP_CEO14] https://twitter.com/php_ceo/status/475056653285736448?lang=en

[Aaronson14] Scott Aaronson, ‘Timeline of computer science’ (updated 2014) at https://www.scottaaronson.com/blog/?p=524

[BlackBooks00] Episode 3 of series 1 of Grapes of Wrath, broadcast in the UK on Channel 4 from 2000–2004: https://en.wikiquote.org/wiki/Black_Books#The_Grapes_of_Wrath_(1.3)

[Buontempo18] Frances Buontempo, 2018, ‘Are we nearly there yet?’ in Overload 147, October 2018

[C2] ‘Worse is better’ at http://wiki.c2.com/?WorseIsBetter

[Gabriel94] ‘Lisp: Good News, Bad News, How to Win Big’ Richard P Gabriel, 1994: from https://www.dreamsongs.com/Files/LispGoodNewsBadNews.pdf

[Parkin12] Ric Parkin (2012) ‘The Computing Revolution Will Be Televised (Again)’ in Overload 108, April 2012https://accu.org/index.php/journals/1933

[SC18a] Software Craftsmanship London http://sc-london.com/

[SC18b] Software Craftsmanship conference: https://www.youtube.com/playlist?list=PLGS1QE37I5lSWm0rmE7UkgEmZq6Spg9z7

Frances Buontempo Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD technically in Chemical Engineering, but mainly programming and learning about AI and data mining. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.