NHacker Next
- new
- past
- show
- ask
- show
- jobs
- submit
login
▲Perlisisms (1982) (cs.yale.edu)self.__VINEXT_RSC_CHUNKS__=self.__VINEXT_RSC_CHUNKS__||[];self.__VINEXT_RSC_CHUNKS__.push("2:I[\"aadde9aaef29\",[],\"default\",1]\n3:I[\"6e873226e03b\",[],\"Children\",1]\n5:I[\"bc2946a341c8\",[],\"LayoutSegmentProvider\",1]\n6:I[\"6e873226e03b\",[],\"Slot\",1]\n7:I[\"3506b3d116f7\",[],\"ErrorBoundary\",1]\n8:I[\"a9bbde40cf2d\",[],\"default\",1]\n9:I[\"3506b3d116f7\",[],\"NotFoundBoundary\",1]\na:\"$Sreact.suspense\"\n:HL[\"/assets/index-BLEkI_5r.css\",\"style\"]\n")>
Rendered at 01:45:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
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.
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 :)
Our software engineer mindset tends to immediately put us in "criticize" mode and with social media comment threads, there's a tendency where a single correct critical observation leads people to discard an entire article.
But that's dumb. We should read critically, of course, but we should apply that in a finer-grained way so that we ignore the parts of an article that are wrong and try to learn from the parts that aren't.
There is often a lot of baby in that bathwater we are so quick to discard.
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.
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.
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.
https://youtu.be/0jK0ytvjv-E?t=43
https://youtu.be/xE9W9Ghe4Jk?t=238
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".
Did you ever have one of those days when variables didn't and constants weren't?
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.
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.
That brings back some memories. Just glad I eventually learned better.
Pretty relevant with LLMs and coding agents.