> A language that doesn't affect the way you think about programming, is not worth knowing.
This one stood out to me. I'd say it's a favorite.
These others are interesting in the age of LLMs:
> 93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
> 114. Within a computer natural language is unnatural.
> 115. Most people find the concept of programming obvious, but the doing impossible.
> 27. Once you understand how to write a program get someone else to write it.
> 113. The only constructive theory connecting neuroscience and psychology will arise from the study of software.
This one remains worth thinking about in terms of the consequences and costs of automation and computerization, LLM-powered or not:
> 99. In man-machine symbiosis, it is man who must adjust: The machines can't.
zahlman 19 hours ago [-]
> 99. In man-machine symbiosis, it is man who must adjust: The machines can't.
It seems worth noting here that the English verb "to adjust" is ambitransitive.
NuclearPM 18 hours ago [-]
Why?
MarkusQ 18 hours ago [-]
It either means man must adjust (themselves), or must adjust (the machine).
So it's a somewhat arch joke than may not be apparent due to shifts in language usage. (Also, "man" in this context was short for "human" without regard to sex (which we now call gender)).
layer8 18 hours ago [-]
The parent alludes to the fact that the sentence could conceivably be read as "In man-machine symbiosis, it is man who must adjust [the machine]", i.e. reading "adjust" as transitive rather than as intransitive.
However, I think it's clear that the intended meaning is intransitive.
utopiah 12 hours ago [-]
> A language that doesn't affect the way you think about programming, is not worth knowing.
I keep it in mind especially when I discuss about programming with non programmers, arguing that the point isn't to bend a machine to your will but rather to become a better thinker. Getting machines to do what you need is "just" an extremely powerful side effect. This is also inspired by Papert and others.
layer8 1 days ago [-]
Also: 102. One can't proceed from the informal to the formal by formal means.
ebiederm 17 hours ago [-]
> 36. The use of a program to prove the 4 color theorem will not change mathematics -- it merely demonstrates the theorem, a challenge for a century, is probably not important to mathematicians.
ink_13 17 hours ago [-]
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).
isomorphic_duck 12 hours ago [-]
Also 100, which speaks to the infinite demand of software - We will never run out of things to program as long as there is a single program around.
rezmason 1 days ago [-]
These are fun to say out loud in the voice of the Kai Lentit's Perl programmer
> A programming language is low level when its programs require attention to the irrelevant.
Great definition actually
dundarious 1 days ago [-]
Relevance is relative, very much so.
xn7 1 days ago [-]
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.
marcosdumay 21 hours ago [-]
Yes, that's the point.
24 hours ago [-]
hbcdbff 1 days ago [-]
Disagree - like many of the quotes on this page, it seems interesting at a very superficial level but upon further inspection turns out to be nonsensical.
If something requires attention, it’s by definition relevant
munificent 1 days ago [-]
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.
movpasd 21 hours ago [-]
> 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.
Thank you for that line --- I may steal it :)
rpdillon 1 days ago [-]
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.
abirch 21 hours ago [-]
My CS teacher in the algorithms frequently said, “until you have the question, the answer doesn’t help.”
addaon 1 days ago [-]
"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.
gwerbin 1 days ago [-]
And if I'm writing a script to query the Google Maps API then I really don't want to have to think about registers at all.
Maybe "high-level"" low level" should be understood in terms relative to the task and its goals.
wbl 24 hours ago [-]
Exactly!
kbenson 1 days ago [-]
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.
skydhash 24 hours ago [-]
Relevant to the problem you’re trying to solve. If it’s only relevant to what you’re using for solving it (i.e. choosing a different tool would have make those issues disappear), then that make them irrelevant.
Each tooling set will bring its own irrelevant details. But you can rank them according to the amount and complexity of the irrelevant of details you have to think about.
msla 19 hours ago [-]
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.
chriscbr 1 days ago [-]
Random self plug - I liked a lot of these quotes from Alan Perlis, so around a year ago I bought the domain https://perl.is/ to display them.
summa_tech 1 days ago [-]
Neat! What do you think about adding a "-2, -1, 0, +1, +2" agreement scale to each quote and showing the average instead of votes?
I think many of those are pretty subjective, and maybe not always right for everyone or for all time. But there are certainly going to be some universal pearls of wisdom, and neither of us can - by ourselves - tell which ones they are.
shawn_w 1 days ago [-]
I read this as "Perlism" at first and got excited to see perl on HN.
cwnyth 18 hours ago [-]
One can dream...
zephen 17 hours ago [-]
Technically, I suppose, nightmares are dreams.
cwnyth 14 hours ago [-]
Perl is only as scary as its coder can make it.
shawn_w 8 hours ago [-]
And, for anything but a throwaway one-liner, it shouldn't be made scary at all.
wredcoll 13 hours ago [-]
I've never understood why so many self-declared programmers are so eager to brag that they can't understand a programming language which is, frankly, not really that complicated.
I don't particularly like, say, lisp, but I can in fact understand lisp programs or write them if I need to.
zephen 13 hours ago [-]
I admit I also don't understand the characterization of perl as a write-only language, although I can make a guess about how it's because a lot of perl programs have many embedded regular expressions, and, like many programmers, I'm not particularly thrilled by things like sigils, and I don't find the syntax particularly good.
You are right that it's not that complicated, but like any language that I'm not interested in mastering, the amount of learning that it would take to create idiomatic perl is not an investment I'm willing to make.
And, given that none of the perl scripts that I was tasked with modifying were very long, I have always treated it, rather than a write-only language, as a read-only language; when someone hands me something in perl that needs to be updated, it gets recoded in something else.
dtagames 1 days ago [-]
And in #27 we find the rationale behind all LLM coding agents, "Once you understand how a program works, get someone else to write it for you."
hugo0vaz 1 days ago [-]
I think you misunderstood what the phrase actually means. You can only successfully manage or outsource a process once you understand it well enough to explain it. Therefore, most of the people doing agentic engineering are not following this Perlisim.
dtagames 1 days ago [-]
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.
skydhash 24 hours ago [-]
> People who do understand how software works should absolutely be having agents code it.
I don’t think there’s such people.
Either you’re writing a software for the first time and so the premise is not true. Or you’re writing it a second time and what would be the point? Just reuse the code you already have.
dtagames 23 hours ago [-]
There are lots of people who understand how software works, including the fact that every line of code is new or else you wouldn't need to write it.
Personally, I love "philosophy of software" questions like these, especially in the AI era. I write quite a bit about this on Medium:
Maybe we need a definition of “understanding how software works”. There’s the technical aspect (computation theory, computer organization, compilation, executable format, …) and there’s the necessity aspect (the domain).
The technical aspect can be learned although you can stop at the top of the abstraction tower (the programming language and its ecosystem). The domain aspect encompasses the whole world pretty much. Contributing to Blender does not qualify you to review a Krita patch. You have to learn the latter’s code first.
fhars 1 days ago [-]
The actual prescient LLM quote is "7. It is easier to write an incorrect program than understand a correct one."
summa_tech 1 days ago [-]
Once you understand how a program works, get someone else to write it for you. Then, you will quickly find out your understanding was insufficient.
dtagames 1 days ago [-]
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.
> 2. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.
A good way to enforce this is to encrypt the data at the beginning of the process.
Then any function that returns structured data is clearly foolish and can be marked for removal.
geon 9 hours ago [-]
What does the quote mean?
As you point out, I would prefer to parse a text string as early as possible, so that I could pass around structured data instead of having to parse the same string over and over.
That seems so obvious that I can't imagine what the author meant.
rpdillon 1 days ago [-]
My favorite has always been:
> 31. Simplicity does not precede complexity, but follows it.
Kind of close to "build the first one to throw away".
0xbadcafebee 22 hours ago [-]
And then try not to fall into second system effect. So plan to build a third system...
> 102. One can't proceed from the informal to the formal by formal means.
Seems to be a strike against LLM-based programming systems like Claude.
Sharlin 23 hours ago [-]
To be fair, I don't think anyone is claiming that the process is anywhere close to formal. The word "vibe" implies anything except formality.
What Perlis probably meant that formal methods are useless unless you already have a formal specification. The formalization process itself is by necessity informal.
sriram_malhar 1 days ago [-]
This feels so quaint today. How I'd like to be back in that timeframe.
benj111 10 hours ago [-]
>18. A program without a loop and a structured variable isn't worth writing
I kind of disagree. It may not be a very big or interesting program but a hell of a lot of useful stuff is done on spread sheets without any loops or anything but numbers.
DonHopkins 1 days ago [-]
>1. One man's constant is another man's variable.
Did you ever have one of those days when variables didn't and constants weren't?
layer8 1 days ago [-]
It constantly varies.
jdw64 24 hours ago [-]
In the long run every program becomes rococo - then rubble.
LelouBil 1 days ago [-]
> Once you understand how to write a program get someone else to write it.
Pretty relevant with LLMs and coding agents.
tenderfault 24 hours ago [-]
76! Let’s do this!
23 hours ago [-]
Rendered at 19:23:47 GMT+0000 (Coordinated Universal Time) with Vercel.
This one stood out to me. I'd say it's a favorite.
These others are interesting in the age of LLMs:
> 93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
> 114. Within a computer natural language is unnatural.
> 115. Most people find the concept of programming obvious, but the doing impossible.
> 27. Once you understand how to write a program get someone else to write it.
> 113. The only constructive theory connecting neuroscience and psychology will arise from the study of software.
This one remains worth thinking about in terms of the consequences and costs of automation and computerization, LLM-powered or not:
> 99. In man-machine symbiosis, it is man who must adjust: The machines can't.
It seems worth noting here that the English verb "to adjust" is ambitransitive.
So it's a somewhat arch joke than may not be apparent due to shifts in language usage. (Also, "man" in this context was short for "human" without regard to sex (which we now call gender)).
However, I think it's clear that the intended meaning is intransitive.
Yep I have it in https://fabien.benetou.fr/Languages/Languages#MakingYourOwn and few other places in my notes.
I keep it in mind especially when I discuss about programming with non programmers, arguing that the point isn't to bend a machine to your will but rather to become a better thinker. Getting machines to do what you need is "just" an extremely powerful side effect. This is also inspired by Papert and others.
https://youtu.be/0jK0ytvjv-E?t=43
https://youtu.be/xE9W9Ghe4Jk?t=238
Great definition actually
If something requires attention, it’s by definition relevant
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.
Thank you for that line --- I may steal it :)
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.
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.
Maybe "high-level"" low level" should be understood in terms relative to the task and its goals.
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.
Each tooling set will bring its own irrelevant details. But you can rank them according to the amount and complexity of the irrelevant of details you have to think about.
I think many of those are pretty subjective, and maybe not always right for everyone or for all time. But there are certainly going to be some universal pearls of wisdom, and neither of us can - by ourselves - tell which ones they are.
I don't particularly like, say, lisp, but I can in fact understand lisp programs or write them if I need to.
You are right that it's not that complicated, but like any language that I'm not interested in mastering, the amount of learning that it would take to create idiomatic perl is not an investment I'm willing to make.
And, given that none of the perl scripts that I was tasked with modifying were very long, I have always treated it, rather than a write-only language, as a read-only language; when someone hands me something in perl that needs to be updated, it gets recoded in something else.
I don’t think there’s such people.
Either you’re writing a software for the first time and so the premise is not true. Or you’re writing it a second time and what would be the point? Just reuse the code you already have.
Personally, I love "philosophy of software" questions like these, especially in the AI era. I write quite a bit about this on Medium:
https://medium.com/@mimixco
The technical aspect can be learned although you can stop at the top of the abstraction tower (the programming language and its ecosystem). The domain aspect encompasses the whole world pretty much. Contributing to Blender does not qualify you to review a Krita patch. You have to learn the latter’s code first.
[0] https://medium.com/gitconnected/you-are-bugs-improving-your-...
A good way to enforce this is to encrypt the data at the beginning of the process.
Then any function that returns structured data is clearly foolish and can be marked for removal.
As you point out, I would prefer to parse a text string as early as possible, so that I could pass around structured data instead of having to parse the same string over and over.
That seems so obvious that I can't imagine what the author meant.
> 31. Simplicity does not precede complexity, but follows it.
Kind of close to "build the first one to throw away".
Seems to be a strike against LLM-based programming systems like Claude.
What Perlis probably meant that formal methods are useless unless you already have a formal specification. The formalization process itself is by necessity informal.
I kind of disagree. It may not be a very big or interesting program but a hell of a lot of useful stuff is done on spread sheets without any loops or anything but numbers.
Did you ever have one of those days when variables didn't and constants weren't?
Pretty relevant with LLMs and coding agents.