Tag: philosophy

LAMBDA: The Ultimate GOTO

‘LAMBDA: The Ultimate GOTO’ (found here) is a paper that was written in 1977 by Guy Steele. It is fun to read, informative, and accessible to a wide-variety of programmers and interest levels. Here are some interesting bits about the paper (I will leave the detail to the paper, no sense in trying to re-state what Steele has already done so well):
(All bits are either copy-and-paste, or summaries directly from the referenced text, along with my comments)

  • Must programming language designers admit that they can’t possibly get it right for every programmer? Yes. Failure to do so results in programmers using the wrong structures to solve their problems.
  • There is a marked difference between programming language concepts and language constructs.
  • Tail-calls (tail-transfers) are really GOTOs.
  • In FORTRAN and APL (at the time the paper was written at least), a distinction is made between built-in and user-defined functions. For example, you can’t pass in a user-defined function as an argument to some built-in functions, whereas you can pass in a built-in function to a built-in function. This may be an interesting historical note for anyone wondering why Scheme lauds that it doesn’t introduce an artificial separation between built-in and user-defined functions.
  • Any notation should accentuate the unusual and make the unobtrusive the usual. To argue that today’s fashionable languages state this is as “Convention over configuration” is a very big stretch.
  • Tail-recursion (trail-transfer) is useful in many more situations than just iterative recursion. Calling tail-transfer tail-recursion was such a mistake. It has got nothing to do with recursion.
  • The difficulties in dealing with programming and programming languages stem from the fact that no distinction is made between the abstraction of program organization and the concrete embodiment of those notations as programming language constructs.
  • For every programming concept found to be useful, there ought to be more than one programming language construct to embody that concept. Philosophically, a marked difference from Python’s “my way or the highway” approach today.
  • The features of tail-recursion allow for a new mental approach for programming.
  • In trying to understand a program, it is necessary to determine not only what construct is being used, but what concept it is intended to express.
  • A language should be so designed that one is encouraged to use a construct if, and only if, it is appropriate; it must also provide enough constructs to cover all reasonable programming constructs.
  • Regarding GOTO, they tried to eliminate unwanted concepts and programming styles by banning a construct.
  • This paper is full of gems.

LAMBDA: The Ultimate Imperative

‘LAMBDA: The Ultimate Imperative’ (found here) is a paper that was written in 1976 by Guy Steele and Gerry Sussman. It is fun to read, informative, and accessible to a wide-variety of programmers and interest levels. Here are some interesting bits about the paper (I will leave the detail to the paper, no sense in trying to re-state what Sussman and Steele have already done so well):
(All bits are either copy-and-paste, or summaries directly from the referenced text, along with my comments)

  • Most programming language constructs can be modeled in terms of lambda, letrec, and if. This might seem pretty radical to folks used to so called “big languages” today. It also might offer some insight into the “minimalistic” nature of Scheme.
  • “Applicative order” of evaluation implies “Call-by-value”. In other words, arguments to functions are evaluated before passing control to the function receiving that value.
  • The paper demonstrates how you can conceptually go from a purely functional world, to one of an imperative nature by leverage call-by-value and macros. This is very, very cool.
  • ‘Tail-recursion’ is perhaps the biggest misnomer of the century. It should be called ‘tail-transfer’. After reading this paper, along with ‘LAMBDA: The Ultimate GOTO’, this becomes quite obvious.
  • Lazy evaluation is introduced, and discussed.
  • Be sure to read the conclusion. It contains numerous gems (both overt and covert) about the role of language, the programmer, and the programming language designer.
  • Keep in mind that this paper was written over 32 years ago. When you take into account the functionality that they describe, and the reasons for its importance; you must put as much effort into thinking about the computing landscape in 1976 as you put into wondering why these kinds of features aren’t in “fashionable languages” today (In my opinion, only Lisp is an acceptable Lisp, and additionally, what does that tell you about “fashionable languages”?).

Always act with choice

Always act with choice. The worse possible thing you can do for yourself is to perform actions begrudgingly. This trains your mind that you are no longer free to make decisions for yourself. Doing so undermines the very foundation on which your ego is built. Live free and choose your actions.
Not every choice will be fun, but the important to always remember is that it is indeed, a choice.

The Lambda Papers

The Lambda Papers are a series of seminal works on programming language design and implementation written by Guy Steele and Gerry Sussman.
You may have heard about them because of the very popular Lambda the Ultimate website, or maybe you just heard about them because you are studying Scheme, or are a student of programming history. Whatever the case, they are very much worth reading (you’ll have to trust me on that).
You should start with ‘AIM-353 Lambda:The Ultimate Imperative’ and follow it with ‘AIM-443 Lambda: The Ultimate GOTO’. Both may be found here.

ACM SIGPLAN Lisp Pointers

While reading a (now forgotten) comp.lang.lisp post, I saw the publication ACM SIGPLAN Lisp Pointers mentioned. Unfortunately I don’t have access to this part of the digital library (for that you need to be a paying member). Perhaps this is something in to which it is worth looking.
Any time folks are interested in something which is now seen as arcane ought to look into that topics history. With enough research, the air of mysticism is usually lifted enough so that one may start to grow a more accurate perspective on the topic. This is especially relevant for Lisp and programmers today.

Analogies are a bridge

Analogies are often used to introduce folks to new ideas, introducing them not directly, but through comparison and inference. This seems to work well in all areas, including technical. The risk in using them in technical matters, though, is that person will never move past the analogy and into the realm of accurately understanding the subject matter.
For a long time, I very much disliked analogies. Perhaps this was due to bad personal experiences in my study path with them, or alternately, hearing other folks go on and on about how “such and such is just like such and such” when that is simply not the case. In the past year, though, three interesting things have happened.
The first is that I’ve chatted with someone, who is very level headed and takes the time to talk through his point of view, who is a proponent of analogies.
The second is that I’ve taken a much closer look at how people teach, and, they certainly don’t do it by throwing their students into the deep end.
The third is that I visited a foreign country where it was clear to me that it wasn’t just the language, but just about everything, that I didn’t understand. On the trip I had the experience of analogies about “how things work” in the country just keep popping into my head. It was the strangest thing, but it was interesting, too, because I finally realized the role of analogies:
Analogies are a helpful bridge, that you must cross. If you stay there, you will never get to where you really want to be.

On Lisp

During my vacation, I skimmed Paul Graham’s book On Lisp. There were many interesting bits in there:

  • He really tries to “sell the wonder of Lisp”. I’m not sure is possible, though.
  • “Users prefer double edged swords to blunt ones”
  • I think that he loves Scheme, but uses CL for practical reasons.
  • He digs deep into code, heavily visiting macros and even implementing continuations, non-determinism, and an object system
  • He is probably a world-class hacker who will never be recognized for his talent, but instead his success
  • This is probably not a good “first Common Lisp book” as it is very deep stuff