Chapter 1: Introduction

1. New Tools
2. New Techniques
3. A New Approach

Introduction

1.1 New Tools

Lisp is distinctive.
What makes it distinctive is that it is designed to evolve.

1.1 New Tools

L allows you to do things other languages can't.

Some programs look similar in Lisp and (say) C

/* C */
int sum (int n){
int i,s = 0;
for(i = 0; i < n; i ++ ) {
s += i;
}
return s;
}

; CL

(defun sum(n)
(let ((s 0))
(dotimes (i n s)
(incf s i))))

but to write (say) a function that takes the number n and returns a *function* that
adds n to its argument

(defun addn(n)
#'(lambda (x) (+ x n)))

This can't be written in C.

Programming languages teach you to not want what they don't provide. You have to
think in a language to write programs in it, and it is hard to want something you
can't describe.

When pg started writing programs in Basic he didn't miss recursion, because basic
doesn't have recursion, and he was thinking in basic, and could only conceive of
iterative algorithm.

addn shows the use of 'lexical closures'. Lisp programs use lexical closures.

Closures are only one of the features of lisp that other languages don't provide.
another unique feature is that lisp programs can be represented by lisp
datastructures . So you can write programs that write programs. (this feature is
called 'macros')

with closures, run time typing and macros, lisp transcends OO. This point is maed
clear in Chapter 17.

Chapters 2-13 introduce all the
17.
The reward for learning this =>
programmer would feel coding in
programming techniques that are
Basic*.
concepts you need to understand the code in Chapter
you will as suffocated programming in C++ as a C++
basic, ** because a C++ programmer knows
'natural' to him, but impossible to express in

Lisp teaches you new ways to think about programs.

1.2 New Techniques.

Individually the 'new features' of lisp - automatic memory management, manifest
typing, closures, and so on, make programming that much easier. Together they form
a 'critical mass' that makes possible a new way of programming.

(KEY) Lisp is designed to be extensible. Lisp is made up of the same kind of

functions and macros as your (user) programs.
So it is as easy to extend lisp as it is to write programs in it.
Extending lisp is standard practice.
as you write your program down towards the language (?) you are also building up
the language towards your program (?)
you work bottom up, as well as top down.

Almost any program can benefit from having a language tailored to its needs (??)
But the more complex the program, the more valuable bottom up programming becomes.
(KEY) in a b.up program, each layer becomes a sort of programming language for the
one above (??) (_ rough analogy, you write assembler in microcode, C in assembler,
Python in C, then you use Python to write what you want - vs writing what you want
-(say a matrix multiplication program) in microcode. I *think* the idea is that
since 'lisp is extensible' you can do this kind of 'each layer being a different
language' quite easily, wheras each step of microcode to python is quite
significant effort)

Extensibility falls out of bottom up programming. The top most layer of your
program is a programming language for the user.
Programs that use lisp as an extension language - Emacs, Autocad, Interleaf.

Bottom up programming also provides reusability.

The essence of reusability is to separate the general from the specific. B.U
programming creates such a separation. Instead of devoting all your effort to
writing a single monolithic application, you devote part of your effort to building
a language, and part to writing a (proportionally smaller wrt effort) application
on top of it. what is specific to the application will be concentrated in the
topmost layer. The layers beneath will form a language for building applications
like this one. There is nothing more reusable than a programming language.

Lisp allows you to write shorter programs, but also to write them faster. The
'shorter' effect is amplified by the (repl based) edit-compile-test cycle being
very short.

Unless you know lisp well, the above seem to be a list of grand claims. at the
moment these are 'empty lakes'. But as you gain more experience and see examples of
code, these will 'fill up with water'.
1.3 A New Approach

Lisp makes a new approach to programming, replacing the 'plan/spec-in-detail and

implement' possible.
The 'new model' makes the 'cost of mistakes' low.
The 'cost of a mistake' is the time taken to correct it, which can be greatly
reduced with modern languages,tools, environments.
Therefore less planning, more 'design comes from the experience of implementing'.
- speed of prototyping
- functional programming - bugs only have a local effect.
- high level/declarative languages - whole classes of bugs - e.g dangling
pointers - are not possible.
- shorter programs == bugs are easy to find (_ APL!!)
- interactive environments => bugs are less time consuming to fix (no waiting
for huge compiles)

Less planning (and letting implementation guide the overall design) can mean better
design.
Tempera vs oil painting. Oil 'allows for second thoughts'.

Thoughts:
1. the lisp way *of thinking* is the real takeaway, not the minutiae of Common
Lisp.
2. In languages with gc and first class functions, much of the 'uniqueness' of
lisp is eroded. (say with ruby). The delta is what macros let you do.
3. CL macros != Racket (etc) macros. The latter would seem to be more
sophisticated. Treat learning CL macros as a 'first cut'. Learn Racket and CL
'macrology' side by side.

see

https://stackoverflow.com/questions/19664993/is-it-possible-to-implement-common-
lisps-macro-system-in-scheme.

for a rundown about the differences.

The second 'big idea' is 'bottom up programming'. No *specific examples* given of

'layers of languages' with the top layer being 'specific to the application'.
Emacs and elisp is mentioned in passing, but how exactly is elisp 'built up as
layers of languages, with the topmost layer being about the 'specifics' of the
emacs editor'? All I can see is that the editor is mostly written in lisp, with the
'performant core' in C. This could very well be done in Python or Ruby (say). This
makes a case for *not C as much as possible* software or 'core in C + $X language
for the rest' software. Where is the 'bottom up'??

see https://news.ycombinator.com/item?id=16933030 jasode's comments.

see also "On Lisp Chapter 1 Notes"