Programming languages have settled into a comfortable middle age, with most coming to resemble one another. Many use some variety of ALGOL-derived structure, maybe with the occasional feature that first made its appearance in a LISP variant. Execution starts at the beginning of the file, or the entry point function. Each statement runs in sequence — except the ones with the magic keywords that say something else happens. Edsger Dijkstra would be perfectly at home using any of these languages, with the cognitive toolbox he developed in the 1960s. So why do they look so different?
Mostly, it is because communities of practice develop around these programming languages, and these communities have different rules. Étienne Wenger came up with the idea of a community of practice to describe the observation that people who share a passion come together to perform their shared passion, and get better through these interactions. Such communities develop distinct identities, based on the way that they communicate how they do what they do — and also on what they do not communicate. Tacit knowledge — the unspoken norms in a community — acts as a kind of reinforcement of the strength of membership. It is not necessarily gatekeeping for a community to have tacit knowledge; these are not the secret mysteries of some shadowy guild. They are things that nobody bothers mentioning because everybody thinks that everybody else already knows them.
As such, what we learn from looking at a different programming language in the 2020s is not so much a different way of programming, as it is a different way of programming. We learn what the community around that language values, the tricks they think are clever (and the tricks they think overly clever), and the ways of using their tools that communicate membership in the community.
As Adrian explored in our C++ issue, “Effective C++” is a description of the family of distinct programming languages that comprise C++, and guidance of which of those you should be using. Other programming galaxies provide similar material: “Effective Java” tells you which bits of the Java language to avoid. Famously, “JavaScript: The Good Parts” is a fraction of the size of a definitive guide to the language. This book very clearly delineates the “bad” areas of JavaScript, devoting much of its slim space to telling you how to stop remembering that they exist.
Two programming galaxies take a different approach: they take great delight in showing you all the features the language has on offer, and the fun you can have by trying them out. Perl is one, and Ruby is the other.
A guide to Java would probably steer you away from the Reflection API. A Swift book would tell you that its runtime metaprogramming capabilities are mostly there for backward compatibility. “Eloquent Ruby”, a book by Russ Olsen, dedicates seven chapters to metaprogramming and invites you to fill your boots.
We start, however, with the chapter that tells you what the rules of engagement for the community of practice are: Write Code That Looks Like Ruby. Throughout this chapter, we receive guidance to create code that is “readable”; of course, implicitly this means “readable to people who like to read code that looks like this”. Readable to members of the community of practice. Readable to Rubyists.
The remaining chapters give guidance on using the various features of Ruby: strings and symbols; objects and classes (of course, as Everything Is An Object™ in Ruby); the regular expression API; and the aforementioned metaprogramming facilities. Each chapter contains about a page on what you might see “in the wild”, helping to contextualize its advice or identify alternative ways of doing the same thing. It also contains somewhere between a paragraph and a couple of pages on “staying out of trouble”: guidance to avoid problems caused by, for example, using a symbol where you need a string, or vice versa.
It is here that we see the difference between the programming galaxies. Guidance on C++, Java, JavaScript, and friends tells you which bits of the language to avoid in order to get your work done. Guidance like “Eloquent Ruby” shows you what the language is capable of, and waits to see what creative things you produce when you make use of them.
Cover photo by the author.