Perlisisms (1982)

Why?

For the sake of completeness, the Four Colour Theorem was proved with the aid of a computer in 1976, although there were, er, quibbles with the original published result not finally put to bed until 1989. It was the first major theorem to be proved with computer assistance (Appel and Haken broke the theorem down to ~1400 configurations that were all computer verified).

That makes that quote even better, no? What is relevant to you might not be relevant to me, the right level for you might too far low level for me.

Yes, that's the point.

If you want to go out of your way to interpret things as uncharitably as possible, you'll find yourself missing out on a lot of potential wisdom.

Obviously, it's relevant if the language itself forces the user to worry about some pointless minutia. The problem is that the language created that relevance, when it is otherwise irrelevant to the problem the user is trying to solve.

Forward declarations are relevant in C because the program won't compile without them. But they aren't relevant in any meaningful way to any domain a user might be writing C programs for.

"If something requires attention, it’s by definition relevant"

Not really. Consider an assembly language for a processor with a very orthogonal register set. The number of registers used by a block of code is relevant, but the identity of those registers isn't. That is, if the code can be written without spilling with six distinct, uniform registers, the choice of one of the 6! possible assignments of those six registers are irrelevant. But when writing that code, you still need to make the choice. And in real assembly languages, it's not necessarily obvious whether the choice here is arbitrary and unconstrained, or externally constrained (e.g. when choosing a mapping that avoids a move instruction by forcing the caller to pass a certain value in an agreed register; or when using an almost-orthogonal register set where it's unclear if later code cares that the value is left in a register that is also the possible target of a div instruction or something), so this requires attention at both write-time and read-time, even when irrelevant.

These were published in the Communications of the ACM in the 1980s, I discovered them in the early 2000s, and have been reading them annually since. Every year, one of the ones that didn't make sense to me the previous year suddenly does.

In this particular quote, Perlis is talking about relevancy to the problem. He's hinting at the difference between incidental complexity and inherent complexity. Inherent complexity is a property of the problem, and incidental complexity is a property of the solution. He's arguing against solutions that bring incidental complexity that requires attention to aspects that aren't relevant to the problem.

OK, how is manual memory management relevant to writing a program to get weather information from an Internet API and display it to the user? In that context, "relevant" is the domains of getting the data (network communications) and displaying it (console vs GUI, converting units to the user's preferences, determining how much to show) and how the program internally manages its buffers is a distraction from those important concepts. Every line of code I have to write to ensure I have the space to store the data I need to work with is visual and cognitive noise, which is why programmers developed garbage collection.

But relevant to what? Some things are relevant directly to the outcome by nature of what you're trying to express, while some other things are essentially incantations you need to repeat the same every time. Bad build systems and what you have to do to make them work are definitely relevant towards building a working program when you're using them, but at the same time the specific details are often somewhat irrelevant for your goal.

Also, many stupid or nonsensical statements can often yield wisdom if you meditate on them enough. Indeed, many (most?) zen koans are so simplistic that to get any usefulness out of them you have to insert you own assumptions and try to determine how it might apply.

Technically, I suppose, nightmares are dreams.

Oh, that's exactly what I meant, except its corollary. People who do understand how software works should absolutely be having agents code it. And we do.

Is that ever true! I wrote a whole Medium article[0] about this, one of my most popular. It's called "YOU ARE BUGS" as a joke from Three Body Problem on Netflix.

[0] https://medium.com/gitconnected/you-are-bugs-improving-your-...

Very ironic, considering the story of Perl 6.