Tag: Programming Language

‘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’ (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”?).

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.