_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Perlisisms (1982)
benj111 wrote 17 hours 34 min 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.
gwern wrote 21 hours 53 min ago:
Full original version, without omissions or typos:
HTML [1]: https://gwern.net/doc/cs/algorithm/1982-perlis.pdf
tenderfault wrote 1 day ago:
76! Letâs do this!
jdw64 wrote 1 day ago:
In the long run every program becomes rococo - then rubble.
rpdillon wrote 1 day 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 wrote 1 day ago:
And then try not to fall into second system effect. So plan to build
a third system...
userbinator wrote 22 hours 26 min ago:
Very ironic, considering the story of Perl 6.
isityettime wrote 1 day ago:
> 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.
utopiah wrote 19 hours 13 min ago:
> A language that doesn't affect the way you think about programming,
is not worth knowing.
Yep I have it in [1] 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.
HTML [1]: https://fabien.benetou.fr/Languages/Languages#MakingYourOwn
isomorphic_duck wrote 19 hours 14 min 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.
ebiederm wrote 1 day 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 wrote 1 day 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).
zahlman wrote 1 day 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 wrote 1 day ago:
Why?
layer8 wrote 1 day 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.
MarkusQ wrote 1 day 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 wrote 1 day ago:
Also: 102. One can't proceed from the informal to the formal by
formal means.
shawn_w wrote 1 day ago:
I read this as "Perlism" at first and got excited to see perl on HN.
cwnyth wrote 1 day ago:
One can dream...
zephen wrote 1 day ago:
Technically, I suppose, nightmares are dreams.
cwnyth wrote 21 hours 45 min ago:
Perl is only as scary as its coder can make it.
shawn_w wrote 15 hours 26 min ago:
And, for anything but a throwaway one-liner, it shouldn't be
made scary at all.
wredcoll wrote 20 hours 43 min 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 wrote 20 hours 31 min 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.
rezmason wrote 1 day ago:
These are fun to say out loud in the voice of the Kai Lentit's Perl
programmer [1]
HTML [1]: https://youtu.be/0jK0ytvjv-E?t=43
HTML [2]: https://youtu.be/xE9W9Ghe4Jk?t=238
ripe wrote 1 day 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.
Sharlin wrote 1 day 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.
LelouBil wrote 1 day ago:
> Once you understand how to write a program get someone else to write
it.
Pretty relevant with LLMs and coding agents.
LelouBil wrote 1 day ago:
> A programming language is low level when its programs require
attention to the irrelevant.
Great definition actually
hbcdbff wrote 1 day 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
msla wrote 1 day 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.
rpdillon wrote 1 day 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 wrote 1 day ago:
My CS teacher in the algorithms frequently said, âuntil you
have the question, the answer doesnât help.â
munificent wrote 1 day 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 wrote 1 day 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 :)
munificent wrote 56 min ago:
It's a thing that clicked for me several years ago and that I
think about all the time now.
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.
kbenson wrote 1 day 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 wrote 1 day 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.
addaon wrote 1 day 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 wrote 1 day 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 wrote 1 day ago:
Exactly!
dundarious wrote 1 day ago:
Relevance is relative, very much so.
marcosdumay wrote 1 day ago:
Yes, that's the point.
xn7 wrote 1 day 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.
jancsika wrote 1 day ago:
> 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 wrote 16 hours 38 min 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.
DonHopkins wrote 1 day 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 wrote 1 day ago:
It constantly varies.
chriscbr wrote 1 day ago:
Random self plug - I liked a lot of these quotes from Alan Perlis, so
around a year ago I bought the domain [1] to display them.
HTML [1]: https://perl.is/
summa_tech wrote 1 day 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.
sriram_malhar wrote 1 day ago:
This feels so quaint today. How I'd like to be back in that timeframe.
dtagames wrote 1 day 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."
fhars wrote 1 day ago:
The actual prescient LLM quote is "7. It is easier to write an
incorrect program than understand a correct one."
summa_tech wrote 1 day 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 wrote 1 day 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.
[0]
HTML [1]: https://medium.com/gitconnected/you-are-bugs-improving-you...
hugo0vaz wrote 1 day 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 wrote 1 day 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 wrote 1 day 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 wrote 1 day 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:
HTML [1]: https://medium.com/@mimixco
skydhash wrote 1 day ago:
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.
DIR <- back to front page