Programming Epigrams

Comments on:

Perlis, Alan J. (1982). Epigrams on Programming. ACM SIGPLAN Notices 17(9), September, 1982. Available online at http://www.pam1.bcs.uwa.edu.au/~michaelw/Perlis_Epigrams.html.

Comments from: Peter Brown, Michael Claveria (*), Davis Hart (*), Brad Miller, Angeline Namai (*), Mark Nettling, Dimitar Tasev.

No comments from: Alex Leach, Dave Ventresca.

One of the things I noticed is that epigrams are a good way of testing knowledge about computer science terms. To understand a lot of them, I had to look up definitions of people and other references online. I noticed that many of the epigrams deal with a handful of particular issues and that several of them compliment each other. I noticed a bunch of religious references, but I didn't really understand the significance until we discussed how strongly some programmers felt about the functional vs. object oriented programming issue.

And about many other issues.

I didn't understand epigram 48: The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman. It's probably because I haven't read Alice in Wonderland so I don't know much about it.

It's clearly time to read it. You can find Alice online in many places, particularly Project Guttenberg.

Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.

This epigram is the one that stand out most in my mind because it reminds me of my friend, John Edwards, who graduated last semester. I swear that he programmed at least 8-10 hours everyday. Even on Fridays, after classes were over, he would be programming in C++, working on making a computer game. I'm not saying that John is like Michelangelo, but I think that greatness comes from passion.

These epigrams are somewhat humourous in the way that they describe programming and computer science. Although funny, these epigrams also hold some truth in them. I find them to be a good synopsis of the programming frustrations I have experienced my entire programming career.

I must say, the reading was fun. It also held a great deal of insite [sic] and humor based on that insite. It seems as though the funniest ones were the ones that seemed most true, or is it that what made them funny was that they were true in my experience.

Sam, this is so far the most interesting reading we've had for the PLC class. It was enjoyable, amusing, and frankly, true. My only suggestion is to assign this reading to people taking CSC151/153 or people deciding on majoring in CS. It would help them in the decision process of whether they want to be programmers or not greatly.

Well, I'm not sure you can understand them until you programmed for some time, but perhaps.

I was not sure how to comment on the fun reading, so I looked up the author to find out what he means to the computing/programming society. It turns out that Perlis was a founding father of computer science as a separate discipline from mathematics, and was the first recipient of the Turing Award, in 1966. Source: [wikipedia].

uriously, while I was searching on Perlis and the epigrams, I found out that there is an experimental functional language called Epigram. It is a dependently-typed, interactive programming environment, and is based on the concept of programming with evidence. It is intended to be terminating, that is, some kind of attempt at solving the halting problem, and Haskell actually uses it as a theorem prover. I doubt that this has any bearing on what you'll be discussing this week, but I thought it to be a strange coincidence that you assigned the reading on the epigrams, yet Epigram is currently under development, and is therefore related to this week's topic, the future of programming languages.

Sources:

• [http://www.e-pig.org]
• [http://haskell.cs.yale.edu/haskellwiki/Libraries_and_tools/Theorem_provers]

Some of the ones I liked:

• It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
• Get into a rut early: Do the same processes 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.
• Perhaps if we wrote programs from childhood on, as adults we'd be able to read them.

Some of the ones I didn't really understand:

• Recursion is the root of computation since it trades description for time.
• In the long run every program becomes rococco - then rubble.
• A good system can't have a weak command language.
• The 11th commandment was "Thou Shalt Compute" or "Thou Shalt Not Compute" - I forget which.

We'll discuss these (and any others folks have difficulty with) in class.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

This epigrams speaks to the difficulty of creating elegance in computer programming. In the context of the course, functional languages seem well suited to offer some relief from complexity by absorbing it. However, I would like to know how the languages do this and still offer at least semi-optimal solutions. I suppose that would be a topic of CSC362 part II.

Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

This epigram cites the need for a language to provide semantics which efficiently and easily arithmetize non-numeric data. The programmer should not have to worry, as in C, about the numeric representation of the string, its characters, and its memory bounds. However, I don't see how we measure understanding by being able to artimetize activities, unless we are designing the language.