Episode 197: 🇬🇧 Algorithms & Tersity with Aaron Hsu

[codereport]

Episode Link: https://adspthepodcast.com/2024/08/30/Episode-197.html

Feel free to write comments or ask questions 🙂

[jvstech]

This is a fantastic episode. Easily one of my favorites. Aaron is very well-spoken and describes the ideas very clearly. And I agree with his assertions... to a point. It's possible I'm misunderstanding this, but I'm taking it to mean that terseness should apply to the entirety of a program, instead of just the application of algorithms. And to that point, I'm looking at this from the perspective of team-based programming.

Elevating how we grasp complexity is a noble goal, and we should have more efficient tools and abstractions. But there’s a balance between theoretical elegance and practical collaboration that has to be maintained.

The conversation did a great job diagnosing the historical buildup of complexity in programming. However, it draws a false dichotomy between terseness and abstraction, assuming that one must come at the expense of the other. "Institutional momentum" is mentioned in a way as if readable code is some bureaucratic standard imposed to crush efficiency. That’s an oversimplification. Readability didn’t become popular because it’s trendy -- it became essential because software development is a collaborative endeavor. We can wax poetic about APL (sorry, Conor!) or regex, but those are niche tools precisely because they prioritize terseness at the cost of accessibility. The point is, readable code isn't just a buzzword; it's a survival mechanism for handling complexity. Teams of people -- often strangers to each other’s code -- need to work together, and concise, cryptic code destroys that dynamic.

Terseness is not inherently simpler. It sounds nice to say terseness leads to economical expression, but in reality, terse code often obfuscates intent. APL and regex are perfect examples -- yes, they’re concise, but they’re terse to the point that they require specialists to decipher them. Regular expressions are notorious for being write-once-read-never code. At a certain level of complexity, once you use it and six months (or however much time) passes by, well, good luck remembering why it worked or what it did unless you leave a trail of comments behind it. Algorithms might be the vocabulary, but notation only empowers thought if it's understandable, not just economical.

Terse code may work beautifully in small, controlled environments or for very specific languages (like APL, which thrives in its niche), but once you scale up, terse code collapses under its own weight. The expressiveness you gain from economy of notation only works when the problem space is narrow enough to handle it. The complexity of modern systems demands more structured abstraction. Terse notation doesn’t buy you simplicity at scale; it trades one type of complexity for another -- one that’s harder to manage across a team, a project, or over time.

So how about the aforementioned problem spaces? Aaron spoke of using mathematical notation for pattern matching to elevate out of complexity. At first, I was convinced this was one hundred percent spot-on. But then I thought about it a bit more, and I only think that's true for a small subset of both problems and people.

It was mentioned that human minds, through "chunking" and pattern recognition, thrive on concise representations. Fair enough, because that's true. We have proof of that through research. But how does this actually translate into programming practice? It's an idealized picture where terseness somehow "magically" (for lack of a better term) enhances the brain’s ability to handle complexity by enabling rapid pattern recognition, akin to what happens in mathematics. That’s a compelling vision, but it’s built on a series of assumptions that don’t hold up under the weight of real-world programming constraints.

Math notation is terse and powerful, but mathematics and programming are fundamentally different activities. Math is about discovering truths, finding patterns, and manipulating abstractions in controlled, often single-author environments. Programming, on the other hand, is about building concrete systems that work -- often with teams, with evolving requirements, under real-world constraints. The level of terseness that works in math falls apart in large-scale software because programs need to be understood, maintained, and modified by many people over time. Mathematical notation can be cryptic for the uninitiated, and terse code in a team environment leads to a similar problem: obscurity and a higher cognitive burden, not less.

The cognitive "chunking" talked about is indeed a way to reduce mental load, but that doesn’t mean terseness automatically enhances it. Chunking relies on recognizable patterns, and there’s the rub: what’s recognizable to one person might be an impenetrable puzzle to someone else. Yes, you might develop muscle memory for short, symbolic code, but in industry, you’re not writing code just for yourself. When other developers come along, they may not share your same mental shortcuts or familiarity with those patterns. So, while you might be able to "chunk" terse expressions, you’re creating a barrier for anyone who hasn’t built that same internal library of patterns. Collaborative programming thrives on shared understanding, not just internal efficiency.

Terseness doesn’t necessarily make things more memorable. Terseness works when there’s a tight, well-defined context -- like a well-known algorithm or simple math equation. But when it comes to software, terseness can introduce ambiguity and cognitive load. A short, dense expression that leverages a specific language’s quirks might be harder to recall or decipher than a slightly more verbose, but clear expression. If someone revisits terse code after a few months or a year, there’s no guarantee it’ll immediately spark recognition -- it might just look like a riddle. Patterns in programming aren’t always as universal or easily chunkable as this episode is making them out to be.

I also believe the argument that expanding individual capacity through terseness will somehow benefit the team is flawed. Teams don’t need individual brilliance; they need clear, understandable, maintainable code that allows for collaboration. Terse code might enable you to reason about complex systems faster, but it’s a massive liability for teams where turnover, on-boarding, and hand-offs are common. It feels like saying a team should adopt shorthand communication because a few team members can speak it fluently. What happens when they leave? Suddenly, the terse code becomes an obstacle, not a tool.

The assertion was made that by leveraging terse code, programmers could "shift the scope" of what they can manage, thereby eliminating the need for many abstractions. But this strikes me as idealism. Most programming complexity comes not from the code itself, but from the problem domain, the integration of various systems, and the changing requirements over time. Terse code won’t magically make those complexities go away. In fact, if your "terse" abstractions aren’t immediately clear, you’re likely to increase complexity by introducing harder-to-decipher code that demands more specialized knowledge to maintain.

Wow, that was a lot. Let me try to summarize all of this.

What's being proposed -- relying on terseness to expand the capacity of an individual programmer -- sounds attractive, but I don't believe it works in practice. Terseness, while sometimes elegant, decreases clarity, increases cognitive load for others, and doesn’t scale well in collaborative environments. It's banking on the idea that everyone will share the same internalized patterns, but that’s not how teams work. What makes terse code easier for one person to grasp often makes it more opaque for another.

Let’s not confuse "mathematical elegance" with applicable practicality. We’ve seen this play out already: APL, Haskell, and other languages with terse notations have their place, but they’ve never become mainstream for precisely this reason. (Again, sorry Conor!) They’re too specialized, too cryptic for wide adoption in environments where readability, maintainability, and extensibility matter. And here’s the kicker: teams, not individuals, drive successful projects. A team that can read, understand, and evolve code trumps a lone prodigy writing terse code that no one else can maintain.

Sure, terseness might increase the scope of what you can handle, but that’s not the goal of modern programming. The goal is to build systems that last, can be extended, and can be understood by others. That means sacrificing the intellectual purity of terse expressions in favor of clearer, more accessible code. Terseness doesn’t empower teams -- it isolates them. That's why I believe we shouldn’t strive for this. What we should strive for is code that balances clarity and efficiency, because that’s how you actually manage complexity in the long run.

I hope this wasn't too critical or sounding too much like an attack of some sort. As I said, I really enjoyed this episode. It made me think. A lot. (Is the wall of text enough evidence of that?) Any other chances you can get to have Aaron on the show, please, do so!

[codereport]

Thanks for the thoughtful post @jvstech! And no need to apologize, half of the time I am of two minds on topics like this and I love hearing both sides. I will at Aaron (@arcfide) to see if he wants to respond here (if not I will have him on in the future so we can chat about the points you bring up)

[arcfide]

Absolutely love this response, and there's a lot of good points to spring off a really good discussion. I'd love to discuss such a thing on a podcast, but I feel like it wouldn't be quite right without @jvstech to defend his points!

I'll try to put together a proper response here as well. There's a lot of good stuff here that is worth discussing and brings up elements and nuance that we just didn't have time for at the pub.