Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Full original version, without omissions or typos: https://gwern.net/doc/cs/algorithm/1982-perlis.pdf
  • > 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.

    by ripe
  • 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.

  • >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.

  • >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?

  • It constantly varies.
  • 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".

  • And then try not to fall into second system effect. So plan to build a third system...
  • > 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.

  • 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.

    by geon
  • 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."
  • 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.
  • The actual prescient LLM quote is "7. It is easier to write an incorrect program than understand a correct one."
  • 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.
  • I read this as "Perlism" at first and got excited to see perl on HN.
  • One can dream...
  • 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.
  • 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.

  • These are fun to say out loud in the voice of the Kai Lentit's Perl programmer

    https://youtu.be/0jK0ytvjv-E?t=43

    https://youtu.be/xE9W9Ghe4Jk?t=238

  • > A programming language is low level when its programs require attention to the irrelevant.

    Great definition actually

  • 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

  • Relevance is relative, very much so.
  • > 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.

  • 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.
  • > 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.
  • > A language that doesn't affect the way you think about programming, is not worth knowing.

    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.

  • Also: 102. One can't proceed from the informal to the formal by formal means.
  • > 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.