
Tutorial on Good Lisp Programming Style (1993) [pdf] - fanf2
https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
======
pieterk
I wish I had internalized this earlier in my career — to write code for human
readers first, and compilers second.

I hope someone proves me wrong, but I think you really need a Lisp to do this
right. Things always break apart with other languages because they don’t fully
decouple from a computer architecture, and architectures change. When
expressing ideas, human brains do not operate as Harvard machines (even though
certain programming languages will try convince you so).

Lisp does provide the means to limitlessly abstract and combine knowledge.
There is no predefined architecture to mold an idea into, so concepts and
their connections can get expressed in a natural way.

For example in C-style languages, the means of combination aren’t general at
all, e.g. the way to combine a function with a type is very different than the
way to combine a function with a number. You’re forced to structure an idea so
that a specific compiler version can compile it to machine code. These brittle
constructs don’t lend themselves very well to separate ideas from their
current implementation. Implementations change, and knowledge get lost.

Lisp code always seems to survive though.

Thanks for posting this tutorial, it’s been a joy to read!

PS. “Almost all Bad Code examples are taken from published books and articles
(whose authors should know better, but will remain anonymous)”

~~~
zaro
> to write code for human readers first, and compilers second.

I find this very ironic in this context. After all lisp is a language where
the human does half of the job the compiler is doing, because you need to
write directly in AST instead of higher level language.

~~~
dreamcompiler
Two points: It's easy to learn to think in ASTs; it just takes practice. No
more practice than it takes to get good at any other programming language.

Second: ASTs contain no ambiguity. English contains ambiguity. Javascript
contains ambiguity. The full meanings of most programs cannot be discerned
from just looking at them; you also need external documentation that describes
the conventions in play (e.g. operator precedence).

This is less true with Lisp than with any other language. Lisp novices
complain about Lisp being write-only, but a well-written Lisp program written
today will still be self-evidently unambiguous (and likely even runnable) in
1000 years. Try that with C++.

Lisp is the Latin of programming languages.

~~~
_emacsomancer_
Latin also contains ambiguities, at various levels (lexical, syntactic, &c.),
just like any other natural language.

Lisp is, however, rather similar to Montague Grammar-style analyses of natural
language, assuming a modern Chomskian binary-branching tree structure.

------
mark_l_watson
I just took the time to read through the entire style guide. I have been using
CL since 1982 and still learned useful tips to keep in mind. CL really is an
ageless language and is excellent for one person projects because it
facilitates both getting things working quickly and a style of building small
libraries of reusable code so future projects go faster.

------
tempodox
Those are still good tips, irrespective of language and even the document's
age.

~~~
lgessler
I agree with you, though I think a few things maybe don't hold anymore:

> Sign and date your comments!

> (Should be an editor command to do this)

Now that everyone uses a VCS (well, almost everyone), this is no longer
necessary.

~~~
TeMPOraL
It's still a good idea. Hell, I recently configured my editor to expand
"todo"/ into "TODO | -- $name, $date" (where | is where the caret ends after
expansion).

Code often outlives its VCS history. I've seen it in every company (except
one) I worked for. Signing and dating comments lets you evaluate whether the
remark is still applicable and who to bug about regardless of how deeply the
VCS goes, and doesn't require you to jump through multiple Blame sessions to
filter out commits that only touched or moved, but otherwise not changed the
comment.

~~~
celeritascelery
Todo’s are probably the only place where signing and dating the code are not
horrible. That way you can filter out all the random todos by intern Jim last
summer.

But I have seen that people who put their name in comments are too
lazy/ignorant to know how to use blame. It’s super easy and keeps your code
clean. If the author is older then the VCS, they are no longer relevant.

~~~
TeMPOraL
> _Todo’s are probably the only place where signing and dating the code are
> not horrible._

Not just todos. Also notes bringing in external context to why some code looks
the way it is, because that external context can invalidate over time, and a
date is then useful to evaluate whether the code needs changes.

> _If the author is older then the VCS, they are no longer relevant._

You'd be surprised. Loss of VCS history happens for various reasons. In my
career, I've seen one because the company switched to a different VCS. I've
seen another because someone forked the project by copying out some parts of
older project and committing them in a first commit of a new repo. I also
worked with a codebase that's older than I am, predating Git, SVN and _CVS_ ,
that someone at some point open-sourced on Github.

------
mietek
Does anyone know the Lisp macro tutorial by Allan Wechsler that is referenced
on page 81?

------
HerrMonnezza
This is from (1993)

~~~
moocowtruck
and then

~~~
HerrMonnezza
The initial submission lacked the tag in the title.

