> A programming language is low level when its programs require attention to the irrelevant.
Great definition actually
dundarious 1 hours ago [-]
Relevance is relative, very much so.
xn7 3 minutes 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.
hbcdbff 57 minutes 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 4 minutes 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.
addaon 47 minutes 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 40 minutes 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.
kbenson 41 minutes 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.
chriscbr 3 hours 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 2 hours 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.
ripe 17 minutes ago [-]
> 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.
dtagames 3 hours 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 3 hours 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 hours 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.
fhars 1 hours ago [-]
The actual prescient LLM quote is "7. It is easier to write an incorrect program than understand a correct one."
summa_tech 3 hours 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 hours 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.
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.
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.
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.
Seems to be a strike against LLM-based programming systems like Claude.
[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.
Pretty relevant with LLMs and coding agents.
Did you ever have one of those days when variables didn't and constants weren't?