Epigrams in Programming (1982) [pdf] | Hacker News Reader

Epigrams in Programming (1982) [pdf]

gwern.net

92 pointsustad41 comments

This version shouldn't be linked, even though it's the canonical one everyone links, because it's bad. If you check it against the original paper (https://gwern.net/doc/cs/algorithm/1982-perlis.pdf) you can see it has transcription errors and omits a bunch - it just drops the last 10! Perlis goes to 130, not 120!

Ok, I changed to that from https://cpsc.yale.edu/epigrams-programming on the grounds that accuracy and completeness are more important than (somewhat) degraded readability. Thanks!

Edit: https://web.archive.org/web/20230127130734/http://pu.inf.uni... has an HTML version - thanks to o11c (https://news.ycombinator.com/item?id=38746206).

oh, the last 10 are meta-epigrams, the epigrams themselves are difficult, meta-epigrams more so.

Related. Is there a definitive year for this btw?

Perlisms – “Epigrams in Programming” - https://news.ycombinator.com/item?id=33702150 - Nov 2022 (8 comments)

Epigrams in Programming - https://news.ycombinator.com/item?id=32176598 - July 2022 (1 comment)

Epigrams in Programming - https://news.ycombinator.com/item?id=25984343 - Feb 2021 (1 comment)

Epigrams in Programming (1982) - https://news.ycombinator.com/item?id=20628827 - Aug 2019 (24 comments)

Epigrams in programming (1982) - https://news.ycombinator.com/item?id=8674919 - Nov 2014 (7 comments)

Epigrams in Programming - https://news.ycombinator.com/item?id=3613900 - Feb 2012 (2 comments)

Perlisisms - "Epigrams in Programming" by Alan J. Perlis - https://news.ycombinator.com/item?id=1701683 - Sept 2010 (2 comments)

Perlisisms - "Epigrams in Programming" [repost] - https://news.ycombinator.com/item?id=1277519 - April 2010 (2 comments)

"Epigrams in Programming" by Alan J. Perlis (ACM SIGPLAN Sep-82) - https://news.ycombinator.com/item?id=482630 - Feb 2009 (3 comments)

The (1982) seems legit, at least for the collection. However, the Yale site is incomplete, stopping at 120 instead of 130.

Canonical location is https://doi.org/10.1145/947955.1083808 leads to https://dl.acm.org/doi/10.1145/947955.1083808 (preview page, incomplete and not text-selectable), PDF link https://dl.acm.org/doi/pdf/10.1145/947955.1083808 is seems to have text data though?

https://web.archive.org/web/20180827170243/http://thecoremem... is a reformatted text PDF of the full version, and https://web.archive.org/web/20230127130734/http://pu.inf.uni... is a full HTML version, which only went offline this year.

https://en.wikipedia.org/wiki/Epigrams_on_Programming

> stopping at 120 instead of 130

Maybe that’s somewhat reasonable (?) given the last nine are epigram epigrams, not directly about programming…

  If there are epigrams, there must be meta-epigrams.
  122. Epigrams are interfaces across which appreciation and insight flow.
  123. Epigrams parametrize auras.
  124. Epigrams are macros, since they are executed at read time.
  125. Epigrams crystallize incongruities.
  126. Epigrams retrieve deep semantics from a data base that is all procedure.
  127. Epigrams scorn detail and make a point: They are a superb high-level documentation.
  128. Epigrams are more like vitamins than protein.
  129. Epigrams have extremely low entropy.
  130. The last epigram? Neither eat nor drink them, snuff epigrams.

But that's no excuse for omitting "121. In seeking the unattainable, simplicity only gets in the way."

The Yale version includes that one. (#60) I’m not sure which one is missing.

Edit, the old #60 is missing:

  Dana Scott is the Church of the Lattice-Way Saints.

That one’s totally obscure, it seems okay to elide. Even the pun’s reference will elude most readers.

Thanks! I added that last link to https://news.ycombinator.com/item?id=38751846, and the year to the title.

I believe this is the original publication, 1982: https://dl.acm.org/doi/10.1145/947955.1083808

Ah, the age - 41 years! - explains a lot and makes me so much more forgiving of these. They certainly come from another era.

I stopped reading around #60, but I've gotta say that the first 40 or so really resonated with me.

This reminds me a lot of "Bumper Sticker Computer Science" from Programming Pearls (1985):

https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf

Good advice for 1985:

Allocate four digits for the year part of a date: a new millennium is coming.

David Martin

Norristown, Pennsylvania

Love it! I keep a similar set of quotes. Lots of fun. https://snarfed.org/software-engineering-quotes

Ha! I'm going to steal some of these for my list: https://www.oranlooney.com/quotes/

> 10. Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

A beautiful thought and I would add that Shakespeare only wrote in english, developing his ability in that beautiful if messy language further and further, rather then trying all sorts of different languages to gain different perspectives on writing.

"It is easier to write an incorrect program than understand a correct one."

That's why it's harder to write a fully typed program in TypesScript than just hack it JavaScript.

A static type system will show you edge cases; probably more than you encounter in practice, but also the few that you will.

Do we have this one yet?

> 70. Over the centuries the Indians developed sign language for communicating phenomena of interest. Programmers from different tribes (FORTRAN, LISP, ALGOL, SNOBOL, etc.) could use one that doesn’t require them to carry a blackboard on their ponies.

This will resonate with any programmer who's known the frustration of asking for time from management to execute a comprehensive code refactoring.

> 105. You can't communicate complexity, only an awareness of it.

Reading the epigrams,

a flash of insight:

Perlis was a secret Zen master.

You know, I dismissed these too easily in a different comment. Thinking of them as koans - containing contradictions, not holding truth, but revealing insights via the reader’s debate and struggle and resistance - makes me like them a lot more!

へー

https://translate.google.com/?sl=auto&tl=ja&text=heh&op=tran...

Make sure to press the speaker icon in the lower box. ;)

or, in perlis's own words:

> 125. Epigrams crystallize incongruities.

Ah, the duality! as some Advaitins would say ;)

> 39. Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

How does this need to be rewritten in the sight of Dall-E, Midjourney and friends?

It doesn't. Consider the first 10k words in my /usr/dict/words equivalent.

They start:

    A
    a
    aa
    aal

and end:

    anticonductor
    anticonfederationist
    anticonformist
    anticonscience

How do you want to describe those with a picture?

(ok, these days one could make a long, thin screen shot, but a non-trivial picture, that doesn't factor through a textual representation? Even representing the 8 strings given here via graphics sounds iffy to me...)

That epigram is referring to a fundamental asymmetry of information between words and pictures. Having a machine that can come up with many different pictures from a few words doesn’t only not say anything about how to make a picture from any 10K words, it somewhat reinforces the epigram’s point.

Those models may be more adequately described by #63: When we write programs that “learn”, it turns out that we do and they don’t.

It doesn't need to be rewritten at all. I can ask Dall-E for a picture that conveys the meaning of the Sermon on the Mount, say, or of Einstein's 1905 paper on special relativity. Whatever I get will not convey the content that the sermon or the paper convey - not even close.

This one anticipates ChatGPT, LLMs etc:

92. The computer is the ultimate polluter: Its feces are indistinguishable from the food it produces.

> 51. Bringing computers into the home won’t change either one, but may revitalize the corner saloon.

Maybe of these are great, but X-D that one didn’t age well.

I don't know, to me it seems ahead of its time...

Please elaborate, I’m curious why. I was thinking of 1) the iPad (not to mention cell phones) 2) my kids spent a majority of their childhoods inside playing video games, unlike mine spent outside with kids from the neighborhood, and 3) Netflix, AppleTV, Amazon, Paramount, etc.. 4) Internet shopping and home delivery, 5) email.

Oh I tried to kick my kids out to play, it just didn’t work very well. The computer options I had as a kid were few and far between, and it was absolutely nothing like the vast sea of high quality entertainment they have on their multiple computer devices today. I got so bored with the sparse choices, I had to learn how to program my own games. My kids, on the other hand, had so many insanely good games and TV shows, they didn’t have the patience to learn to write code (until very recently) despite a lot of interest.

Nobody writes handwritten letters anymore (and even though it was fun, I’m not sure we should.) Movie theaters are dying since everyone can stream movies at home on big screen TVs (that are stuffed with computers now). Many many brick-and-mortar stores are closing their physical shops and going increasingly online. It seems like the computer has already changed the household immensely and irreversibly, not to mention the whole world we know.

* many

Mostly really good, but I have a problem with this one:

> 67. Think of all the psychic energy expended in seeking a fundamental distinction between “algorithm” and “program”.

I mean... it's semantics but I feel like taking the bait here. I have a weird concept of fun.

I've always understood it as a program takes external input and/or gives external output (like keyboard presses, display to screen, write to disk, etc) whereas an algorithm is self contained and can run on any turing machine regardless of capabilities.

Basically "Side Effects", but I avoided using that phrase because input isn't clearly a side effect, but if your semantics don't require no side effects for an algorithm, then yeah a program is functionally equivalent to an algorithm.

Mostly semantics don't capital-M Matter, but can be important to clarify meanings. Depending on what project/team I'm working on I can have completely incompatible definitions of the same word in the same day.

Instead of attempting to offer a distinction between algorithm and program, how about the following relations?

    spec -< algorithm -< program -< executable

where each (a -< b) says both that b implements a and that there are almost always multiple valid potential bs for any given a.

I always thought it was obvious: a program is/contains a concrete implementation of an algorithm.

A recipe book contains an algorithm for baking cookies, but how you do it vs how someone else does it is going to have slight differences (accuracy of measurements, size of cookie, etc).

> There will always be things we wish to say in our programs that in all known languages can only be said poorly.

And that, folks, is why I am studying programming languages for my PhD.

#/usr/bin/env jokelang --dialect punlang

Did Perlis diss Perl, or miss Perl?

Is Perl A. Perlis language?

Perl is a language Perlis did miss.

#Please don't diss, this was a chance too good to miss.

Proto-buzzfeed? I guess this is like other forms of candy: it's great that it exists and you still shouldn't eat it.

this one is very thought-provoking:

> 4. Every program is a part of some other program and rarely fits.

Reply on news.ycombinator.com