I’ve long been a fan of Guy Steele. I was first introduced to him because he was the author of Common Lisp, The Language. But then I found that he also co-invented Scheme. This blew my Lisp-2 mind. How could he work on Lisp-2 and Lisp-1? Then I found out he wrote the Java spec and was totally baffled. Java? He was supposed to be a Lisper! But it gets worse. He was working on Fortran!
The whole experience of learning about Guy Steele shook me deeply. I realized I was being silly. I believed there was One True Language that all languages aspired and competed to be. But this is not true. And Guy Steele embodies the view that you can be fair-minded, that features can be borrowed, that all languages have warts, and that we’re still learning how best to design languages.
Guy Steele is an amazing figure. He was instrumental in writing the specs for C, Common Lisp, Scheme, and Java.
He’s also a great speaker. His talks are always concise and to the point. He seems like such a nice guy. He never says anything harsh!
Sign up for weekly Clojure tips, software design, and a Clojure coding challenge.
50 in 50VideoPresentation
Guy Steele and Richard Gabriel’s jam that touches on 50 remarks on the history of programming in 50 words each. This is definitely worth watching. It’s a little artistic (as Richard Gabriel tends to roll), but it leads to a deeper appreciate of the ideas.
C: A Reference ManualTextBooks
This reference predated the ANSI standardization of C.
Common LISP: The LanguageTextBooks
The massive description of Common Lisp was written by Guy Steele. Yes, the language is a monster. But boy is this book clear!
Debunking the "Expensive Procedure Call" MythPDFPaper
or, Procedure Call Implementations Considered Harmful
or, LAMBDA: The Ultimate GOTO
This paper is so important in the history of compiler design. Before this paper, it was commonly thought that function calls were very expensive and should be minimized. Steele showed that they could be, in many important cases, be compiled into a single GOTO. This makes function calls strictly better than GOTO and cheap enough to do all the time. Thank this paper next time you write a one-line function.
Fortress Features and Lessons LearnedVideoPresentation
Guy Steele led a team of programming language researchers to develop a language called “Fortress”. It was an amalgam of 20 far-out ideas, including mathy unicode syntax, extreme extensibility, and automated parallelism. The project was eventually defunded. But he shares some of the things they learned with the Julia community.
Four Solutions to a Trivial ProblemVideoPresentation
Guy Steele presents four different solutions to a single problem. The first solution is a purely sequential solution programmed with a
forloop. He then shows how a “build-and-conquer” approach is much better for automated concurrency. His argument is that we will soon have to change the patterns we use for solving problems because they are inherently sequential. As things need to become more parallel, we will need the language to automatically find opportunities (either at compile-time or runtime) to run things in parallel.
Growing a LanguageVideoPresentation
What a great presentation. I don’t want to spoil anything about this. But you will come away with a new understanding of how verbose our current style of programming is and why it is that we have to define everything ourselves. Further, he presents a veritable manifesto of extensibility of languages with a potential solution to the Worse-Is-Better paradox.
A transcript is available.
Guy Steele Interviews John McCarthy, Father of LispVideoInterview
Back in 2008, a small sub-conference hosted at OOPSLA celebrated the 50th anniversary of Lisp. One of the highlights was Rich Hickey speaking. Another was this interview between Guy Steele and John McCarthy. Unfortunately, it was supposed to be Alan Kay interviewing McCarthy. But McCarthy was too sick to travel, so Alan Kay canceled. Still, Guy Steele is a great interviewer.
How to Think about Parallel Programming: Not!VideoPresentation
In this talk, Guy Steele argues that like automatic memory management, parallelism is best left up to the compiler. However, this requires us to give up some of the constructs we have today and code in a new style based on “build-and-conquer” algorithms. Right now, our functional algorithms are based on linked lists, which are inherently sequential—they decompose into a first and a rest. We will need to build equivalent data structures that decompose into two equal parts.
Keynote at Daniel Friedman's 60th BirthdayVideoPresentation
He presents a few cool ideas from Daniel Friedman, including lazy sequences and programmed instruction.
LAMBDA: The Ultimate DeclarativePDFPaper
This paper brings a different perspective to functions. It shows that they can be seen as a naming operation within an environment. The paper takes this expression to logical conclusions, which lead to new compiler techniques.
Lisp-in-Lisp: High Performance and PortabilityPaperPDF
This paper briefly describes an implementation of Common Lisp in another Lisp. It discusses the advantages, which are basically that it’s easier to read and write than an assembly version, and the disadvantages are that it is slower. These seem obvious now. But notice the term Lisp-in-Lisp. I believe this is the origin of the term Clojure-in-Clojure, which was an important goal on the way to a self-hosting ClojureScript compiler.
Organizing Functional Code for Parallel Execution; or, foldl and foldr Considered Slightly HarmfulVideoPresentation
Forget about Monads. We absolutely need to start thinking about Monoids. And not just any monoids. They need to split a problem evenly, not first-and-rest as we typically do with sequences in most functional languages. This talk directly inspired Clojure’s
Panel: The Future of Programming LanguagesVideoPanel
This panel included Guy Steele, Douglas Crockford, Josh Bloch, Alex Payne, and Bruce Tate. Ted Neward moderated the discussion about the future of programming.
Scheme: An interpreter for extended lambda calculusPDFPaper
This is the original paper, from 1975, presenting the Scheme language. The paper is a must-read. It discusses Scheme, language design choices, an exploration of different possible semantics, and includes a complete implementation of an interpreter in another Lisp.
The Art of the InterpreterPDFPaper
or, The Modularity Complex
This paper shows how an interpreter can be used to quickly prototype new language features. They go through a small portion of the history of the features of Lisp.
The Evolution of LispVideoPresentation
An awkward re-enactment of a talk the speakers gave 25 years before. It’s an interesting talk, but a re-enactment? It’s a little stilted. However, if you’re looking for a history of Lisp as it was in 1993, it’s got great information.
There was a paper writter by the presenters on the same topic.
The Fortress language specificationPDFPaper
Guy Steele led a team researching a new language called Fortress, which tried several cool ideas. These included unicode mathematical operators, extreme extensibility, and automated parallelization.
The Java Language SpecificationTextBooks
Guy Steele was hired by Sun to write the Java specification. Why? They heard he was good after having written the Common Lisp book, the Scheme specification, and a C spec. Shortly thereafter, people felt he had betrayed his Lisp roots by going to Java. He was quoted as saying “We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.”