This book repository is dedicated, in respect and admiration, to the spirit that lives in the computer.

---

I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. [...] What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.

— Alan J. Perlis

[...] I select "The Raven" as most generally known. It is my design to render it manifest that no one point in its composition is referable either to accident or intuition — that the work proceeded step by step, to its completion, with the precision and rigid consequence of a mathematical problem. [...] Most writers [...] would positively shudder at letting the public take a peep behind the scenes, at the elaborate and vacillating crudities of thought — at the true purposes seized only at the last moment — at the innumerable glimpses of idea that arrived not at the maturity of full view — at the fully-matured fancies discarded in despair as unmanageable — at the cautious selections and rejections — at the painful erasures and interpolations — at the wheels and pinions — the tackle for scene-shifting — the step-ladders, and demon-traps — the cock's feathers, the red paint and the black patches, which, [...] constitute the properties of the literary histrio. [...]

— The Philosophy of Composition by Edgar Allan Poe

I'd like to welcome you on this course on computer science. Actually, that's a terrible way to start. Computer science is a terrible name for this business. First of all, it's not a science — it might be engineering, or it might be art. Or we'll actually see that computer, so called "science", actually has a lot in common with magic.

[...] And, indeed, on some absolute scale of things we probably know less about the essence of computer science than the ancient Egyptians really knew about geometry. Well, what do I mean by "the essence of computer science?" What do I mean by "the essence of geometry?" See it's certainly true that these Egyptians used surveying instruments, but when we look back on them after a couple of thousand years, we say "gee, what they really were doing the important stuff they were doing, was to begin to formalize notions about space and time." To start a way of talking about mathematical truths formally; that led to the axiomatic method, that led to, sort of, all of modern mathematics. Figuring out a way to talk precisely about so-called declarative knowledge. "What is true?" Well similarly, I think in the future, people will look back and say "yes, those primitives in the twentieth century were fiddling around with these gadgets called computers, but really what they were doing is starting to learn how to formalize intuitions about process — how to do things"

— Lecture 1A | MIT 6.001 Structure and Interpretation, 1986 by Hal Abelson

We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells. A computational process is indeed much like a sorcerer's idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. [...] The programs we use to conjure processes are like a sorcerer's spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform. [...] like the sorcerer's apprentice, novice programmers must learn to understand and to anticipate the consequences of their conjuring.

— Structure and Interpretation of Computer Programs, 2nd Edition, Chapter 1, Building Abstractions with Procedures

[...] LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.

— How To Become A Hacker by Eric Raymond

[...] Every computer program is a model, hatched in the mind, of a real or mental process. These processes, arising from human experience and thought, are huge in number, intricate in detail, and at any time only partially understood. They are modeled to our permanent satisfaction rarely by our computer programs. Thus even though our programs are carefully handcrafted discrete collections of symbols, mosaics of interlocking functions, they continually evolve: we change them as our perception of the model deepens, enlarges, generalizes until the model ultimately attains a metastable place within still another model with which we struggle. The source of the exhilaration associated with computer programming is the continual unfolding within the mind and on the computer of mechanisms expressed as programs and the explosion of perception they generate. If art interprets our dreams, the computer executes them in the guise of programs! [...] Every reader should ask himself periodically "Toward what end, toward what end?" — but do not ask it too often lest you pass up the fun of programming for the constipation of bittersweet philosophy.

— Alan J. Perlis, New Haven, Connecticut

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?

— Alan J. Perlis

What should you do in college to become a good hacker? There are two main things you can do: become very good at programming, and learn a lot about specific, cool problems. These turn out to be equivalent, because each drives you to do the other. The way to be good at programming is to work (a) a lot (b) on hard problems. And the way to make yourself work on hard problems is to work on some very engaging project. [...] Thomas Huxley said "Try to learn something about everything and everything about something." [...] But what's everything? To me it means, all that people learn in the course of working honestly on hard problems. All such work tends to be related, in that ideas and techniques from one field can often be transplanted successfully to others. Even others that seem quite distant. For example, I write essays the same way I write software: I sit down and blow out a lame version 1 as fast as I can type, then spend several weeks rewriting it.

— Undergraduation by Paul Graham

Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile

— Hippocrates

[...] Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in your ten years/10,000 hours

— Teach Yourself Programming in Ten Years by Peter Norvig

SICP was revolutionary in many different ways. Most importantly, it dramatically raised the bar for the intellectual content of introductory computer science. Before SICP, the first CS course was almost always entirely filled with learning the details of some programming language. SICP is about standing back from the details to learn big-picture ways to think about the programming process. It focused attention on the central idea of abstraction -- finding general patterns from specific problems and building software tools that embody each pattern.

— Why Structure and Interpretation of Computer Programs matters by Brian Harvey

[...] For a course, what you want is a crystal-clear language that highlights the computer science ideas without hiding them in a cloud of syntax or library details. [...] You can learn to program in any language. But it's not just an accident that the authors of SICP chose Scheme as their teaching language. The big ideas in the book — the ones that alumni in the real world tell us they're using in their work — express themselves best in Scheme. Indeed, saying it that way puts the matter backward. [...] SICP is Scheme, in tutorial form.*

— Scheme vs. Python by Brian Harvey

A language that doesn't affect the way you think about programming, is not worth knowing

— Alan J. Perlis

[...] Lisp hasn't survived for over half a century because programmers have begrudgingly conceded that it is the best tool for the job decade after decade; in fact, it has survived even though most programmers do not use it at all. [...] Until we can imagine God creating the world with some newer language, Lisp isn't going anywhere.

— How Lisp Became God's Own Programming Language by Sinclair Target

[...] We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.

— Beating the Averages by Paul Graham

[...] Since 1996 a buddy and I had been bulding our own little software business. Being small is often a great advantage, but sometimes there were projects we just couldn't undertake — we were just two guys. So I was on the lookout for leverage. We started using Jave for this very reason; two guys can get a lot more done in Java than two guys in C++, especially if you need to deploy on multiple platforms, etc. Needless to say, Paul Graham's article resonated with me. After reading it I had to find out if what he was saying was true. And, through a long still-underway learning process I would have to say that yes, it is absolutely true. Lisp is the best programming language ever devised. Nearly every language wish that was in my wishlist is in Lisp (or made irrelevant by Lisp) and each has been better designed and more thoughtfully integrated than I could have ever done myself. And since the language itself is also a compiler and debugger many of the features of my ideal programming IDE are now pointless.

— Chris-Perkins (for The Road to Lisp Survey) by, well, Chris Perkins

The most powerful programming language is Lisp. If you don't know Lisp (or its variant, Scheme), you don't know what it means for a programming language to be powerful and elegant. Once you learn Lisp, you will see what is lacking in most other languages. Unlike most languages today, which are focused on defining specialized data types, Lisp provides a few data types which are general. Instead of defining specific types, you build structures from these types. Thus, rather than offering a way to define a list-of-this type and a list-of-that type, Lisp has one type of lists which can hold any sort of data. Where other languages allow you to define a function to search a list-of-this, and sometimes a way to define a generic list-search function that you can instantiate for list-of-this, Lisp makes it easy to write a function that will search any list — and provides a range of such functions. In addition, functions and expressions in Lisp are represented as data in a way that makes it easy to operate on them. [...]

— Programming languages by Richard Stallman

Study of the Design Patterns book: 16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern

— Design Patterns in Dynamic Programming by Peter Norvig

Common Lisp macros are to C++ templates what poetry is to IRS tax forms

— Lessons Learned Implementing Common Lisp with LLVM by Christian Schafmeister

[...] Remember, I'm not saying that programming is an easy way to express poorly defined ideas! To take advantage of the unsurpassed flexibility of this medium requires tremendous skill-technical, intellectual, and esthetic. To constrain the behavior of a program precisely to a range may be very hard, just as a writer will need some skill to express just a certain degree of ambiguity. A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it.

— Why Programming is a Good Medium for Expressing Poorly Understood and Sloppily-Formulated Ideas by Marvin Minsky

[...] We have been programming universal computers for about 50 years. Programming provides us with new tools to express ourselves. We now have intellectual tools to describe "how to" as well as "what is." This is a profound transformation: it is a revolution in the way we think and in the way we express what we think. For example, one often hears a student or teacher complain that the student knows the "theory" of some subject but cannot effectively solve problems. We should not be surprised: the student has no formal way to learn technique. We expect the student to learn to solve problems by an inefficient process: the student watches the teacher solve a few problems, hoping to abstract the general procedures from the teacher's behavior on particular examples. The student is never given any instructions on how to abstract from examples, nor is the student given any language for expressing what has been learned. It is hard to learn what one cannot express. But now we can express it! Expressing methodology in a computer language forces it to be unambiguous and computationally effective. The task of formulating a method as a computer-executable program and debugging that program is a powerful exercise in the learning process. The programmer expresses his/her poorly understood or sloppily formulated idea in a precise way, so that it becomes clear what is poorly understood or sloppily formulated.

— Why Programming is a Good Medium for Expressing Poorly Understood and Sloppily-Formulated Ideas by Gerald Jay Sussman

[...] The true test of a language is how well you can discover and solve new problems, not how well you can use it to solve a problem someone else has already formulated. These two are quite different criteria. In art, mediums like embroidery and mosaic work well if you know before hand what you want to make, but are absolutely lousy if you don't. When you want to discover the image as you make it-- as you have to do with anything as complex as an image of a person, for example-- you need to use a more fluid medium like pencil or ink wash or oil paint. And indeed, the way tapestries and mosaics are made in practice is to make a painting first, then copy it. (The word "cartoon" was originally used to describe a painting intended for this purpose).

— Succinctness is Power by Paul Graham

[...] The key to being a good hacker may be to work on what you like. When I think about the great hackers I know, one thing they have in common is the extreme difficulty of making them work on anything they don't want to. I don't know if this is cause or effect; it may be both. To do something well you have to love it. So to the extent you can preserve hacking as something you love, you're likely to do it well. Try to keep the sense of wonder you had about programming at age 14. If you're worried that you current job is rotting your brain, it probably is.

— Great Hackers by Paul Graham

[...] It's hard to find work you love; it must be, if so few do. So don't underestimate this task. And don't feel bad if you haven't succeeded yet. In fact, if you admit to yourself that you're discontented, you're a step ahead of most people, who are still in denial. [...] Although doing great work takes less discipline than people think — because the way to do great work is to find something you like so much that you don't have to force yourself to do it — finding work you love does usually require discipline. [...] "Always produce" is also a heuristic for finding the work you love. If you subject yourself to that constraint, it will automatically push you away from things you think you're supposed to work on, toward things you actually like. [...] Whichever route you take, expect a struggle. Finding work you love is very difficult. Most people fail. [...] But if you have the destination in sight you'll be more likely to arrive at it. If you know you can clove work, you're in the home stretch, and if you know what work you love, you're practically there.

— How to Do What You Love by Paul Graham. Note: as a poem by J. R. R. Tolkien went, "not all those who wander are lost".

[...] There are three variants of procrastination, depending on what you do instead of working on something: you could work on (a) nothing, (b) something less important, or (c) something more important. That last type, I'd argue, is good procrastination. That's the "absent-minded professor," who forgets to shave, or eat, or even perhaps look where he's going while he's thinking about some imteresting question. His mind is absent from the everyday world because it's hard at work in another. That's the sense in which the most impressive people I know are all procrastinators. They're type-C procrastinators: they put off working on small stuff to work on big stuff. What's "small stuff?" Roughly, work that has zero chance of being mentioned in your obituary. [...] Good procrastination is avoiding errands to do real work. [...] I think the way to "solve" the problem of procrastination is to let delight pull you instead of making a to-do list push you. Work on an ambitious project you really enjoy, and sail as close to the wind as you can, and you'll leave the right things undone.

— Good and Bad Procrastination by Paul Graham

One of the characteristics of successful scientists is having courage. Once you get your courage up and believe that you can do important problems, then you can. If you think you can't, almost surely you are not going to. Courage is one of the things that Shannon had supremely. You have only to think of his major theorem. He wants to create a method of coding, but he doesn't know what to do so he makes a random code. Then he is stuck. And then he asks the impossible question, "What would the average random code do?" He then proves that the average code is arbitrarily good, and that therefore there must be at least one good code. Who but a man of infinite courage could have dared to think those thoughts? That is the characteristic of great scientists; they have courage. They will go forward under incredible circumstances; they think and continue to think.

— You and Your Research by Richard Hamming

Anyone can cook, but only the fearless can be great.

— by Auguste Gusteau, chef in Ratatouille

[...] Quite a lot of designing programs well, in my experience, comes down to this: we have these common psychological quirks that lead us to bias our thinking in certain ways. To actually come up with good designs, we have to remember to actively work against our worst impulses. The scientific method isn't some simple, clean universal approach to finding the truth of our universe; it's a rather messy, ad-hoc, extremely human approach to overcoming the flaws that cause us to believe things that aren't true. To do design well, we have to work around ourselves, too.

— The one ring problem: abstraction and our quest for power by Ted Kaminski

[...] the other thing that seems really important to me is that we spend all our time modifying existing code. Okay? The problem is our code is not adequately evolvable. Right? It's not adequately modifiable to fit the future. In fact, what we want is to make systems that have the property that they are good for things that the designer didn't even think of or intend. [...] What can we do with these Propagators? And I'm only pushing this idea not because I think it's the right answer. I've tried to twist us. So that we say "this is a different way to think." Okay? Some other — we have to think 52 different ways to fix this problem. I don't know the answer to how to get out of this. I don't know how to make a machine that builds a person out of a cell. Okay? But I think the problem is that we've been stuck for too long thinking about the fact that we have been diddling with our details, we're sitting here worrying about our type system, where we ought to be worried about how to get flexible machines and flexible programming.

— We Really Don't Know How to Compute by Gerald Jay Sussman

— [Scheme'22] Programming is (should be) fun! by Gerald Jay Sussman