A few examples of Lisp code typography (2013)

Also, don't forget that beauty is relative.

Sure, 1960's LISP doesn't look that nice nowadays, but it's day and night if you compare it to e.g. the contemporary FORTRAN IV.

Agreed.

Using square brackets in place of some parens is something some of the Racket professors started doing. I assumed it was because they thought it would be helpful to teach high school students in http://htdp.org/ . I defer to them on teaching, but I think it looks ugly, is harder to type, and seems like it's more confusing in code examples (people thinking it's significant, when it's not).

One thing I did do is make an Emacs mode, https://www.neilvandyke.org/quack/ , in which typing square brackets instead inserts parentheses when appropriate. This is helpful on US keyboards, on which parens require a multi-key press but square brackets do not.

[] as a quoted list shows up occasionally. [foo bar] vs '(foo bar). I think I prefer that but it's hard to be sure.

I find them very useful in the way Racket uses them, which is by convention only. In Racket, `[<expression>]` is identical to `(<expression>)`. But Racket uses them in a conventional sense, for example, in `let` bindings:

    (define test
      (let ([a 1]
            [b 2])
        (+ a b)))

Reader macros/literals allow for explicitly differentiating between built-in data types, and provide semantic meaning to otherwise indistinguishable forms. For example, defining a function:

In Racket, you write `(define (foo arg1 arg2) (+ arg1 arg2))`. Why isn’t `(foo arg1 arg2)` evaluated as a function? It’s a list and it isn’t quoted, so it should be evaluated. However, `define` is a macro (I think, might be a special form), so that list isn’t evaluated and doesn’t have to be quoted. That violates the basic tenant of “unquoted forms wrapped in a list are evaluated as fiction calls.”

In Clojure, you write `(defn foo [arg1 arg1] (+ arg1 arg2))`. The [] is a reader macro, a vector literal. It communicates that it’s not a function call but simply data (in this case, a vector containing two symbols).

Maybe I’m just used to it but I find this stuff really helpful.

Same here. It obscures the notion of code is data, data is code.

"Foo" has a long and deep history. There was a comic strip called Smokey Stover that started in 1935 whose title character was a "foo fighter" (firefighter) and drove a "foomobile" (a tiny fire truck with only two wheels). The author of the strip claims to have discovered the word "foo" when he saw it written on the bottom of a Chinese figurine, but I don't think that's the real etymology. I think "foo" was just short for "phooey", and was used to designate things deemed nonserious or trivial (somewhat similar to how "lol-" or "lulz-" is used in modern times).

Whatever the case, "foo" became associated with "bar" via WWII slang "FUBAR"; WWII also gave us "foo fighters" in the UFO sense. War is like the internet in that it brings together people of different backgrounds who otherwise might never interact, so it's not surprising that with things like foo, FUBAR, and Kilroy, WWII had something resembling a predecessor of modern meme culture. It entered hacker culture via the MIT TMRC culture in the 1950s. Their railroad layout had a "foo counter" which was a digital clock which would display the word instead of the time when certain scram switches were pressed. When MIT people began cultivating an interest in programming computers for its own sake, they brought "foo" with them and it spread into the greater hacker meme diaspora.

There's nothing quite as hacker-y as the word "foo", and the strong association with hacker culture goes back as long as hacker culture was a thing, and even before. It still reminds us to not take things so seriously, mess around, and have a little fun.

"foo" might have an association to the whistle from the steam engine era. I have a memory of the whistle in very early Disney animation. Also, I believe in Mandarin Chinese "foo" indicates the end of the sentence.

Ugh, to me that's strictly worse. Not really any more terse, harder to read, harder to parse, harder to navigate.

I see lines that start with punctuation as incredibly ugly, so that to me is strictly worse.

This makes copy and paste between files or to/from a repl _really_ annoying. Splice a delimited sequence anywhere and auto-format is categorically better.

Structural editing is one of the amazing things you get for free in Lisps, but I cannot imagine how it could be done without parentheses. I also don’t really find it more readable without them, but it might just come down to what you’re used to. Alas, this is a nice experiment nonetheless.

This basically happens in my mind when looking at Lisp code. Parens are just handles that allow me to manipulate the expressions for structural editing.

For Common Lisp, there are several free books available:

- Practical Common Lisp (aimed at people who know how to program in a more mainstream language already) [1]

- Paradigms in Artificial Intelligence Programming (my personal favorite) [2]

- Common Lisp: A Gentle Introduction to Symbolic Computation (aimed at absolute beginners of programming) [3]

I highly recommend the r/lisp Reddit community. Reddit as a platform has its issues, but the Common Lisp community there is very responsive and very helpful.

Lastly, you might be interested in checking out Kandria [4], a game written entirely in Common Lisp, to be released imminently on Steam.

[1] https://gigamonkeys.com/book/

[2] https://github.com/norvig/paip-lisp

[3] https://www.cs.cmu.edu/~dst/LispBook/

[4] https://store.steampowered.com/app/1261430/Kandria/

That's a broad question, to be honest.

Especially today, since Lisp rather than being a single thing, is a family of languages. I mean, there's some truth to "JavaScript being a Lisp", so you can see that it's a bit open ended.

If you're looking for an embedded Lisp, then I would concentrate on finding one that simply appeals to you. That is, find one that integrates easily, or has a particular feature that you like, or any of many things that may catch your eye.

Once you pick one, then simply "learn that". Consider GIMP originally started by integrating SIOD (Scheme in One Defun), which is a simple Scheme interpreter. They have since moved on to TinyScheme (of which I'm unfamiliar).

But, SIOD has been around forever. SIOD begot SCM which begot GUILE, which is specifically designed to be embedded. It's also pretty large.

ECL, which stands for Embedded Common Lisp is, well, a Common Lisp. Scheme and Common Lisp are both Lisps, but quite different from each other.

That's why rather than saying "pick this", simply find one you like and learn that. The landscape is wide and rich.

I always recommend Make a Lisp [0]. It's a guided experience creating a Lisp in whatever language you already know. If you go through all the steps, you'll have created a self hosting Clojure-like Lisp.

For me implementing a Lisp piece by piece helped me better understand its core ideas.

[0] https://github.com/kanaka/mal

MIT OpenCourseWare has 6.001, SICP. Watching the '80s videos was how I got started with Scheme. Though on the book front I would definitely recommend starting with Concrete Abstractions before SICP.

With Common Lisp I think the standard road is Gentle Introduction followed by Practical CL followed by PAIP.

> undifferentiated sea of lowercase letters just makes my eyes glaze over

Like prose? Books have not many symbols nor syntax highlighting. You have to read the actual words to know what it's talking about.

Strange to me. The "modern" style (roughly mid 80s) is super clear to me, with the indentation doing a lot of work and the symbol names so clear (I still find the MixedCase jarring and significantly slower to parse, while using-dashes or even using_underscores much easier).

This style also encourages blocks to be compact so they almost fit right into your fovea. The spread-out "C" style that emphasizes the curly braces on their own line seems so backwards, emphasizing precisely the thing you don't care about.

Rainbow brackets really help.

Funny, because traditionally it was (ALL-UPPER-CASE)

Nowadays, indentation does a bunch of heavy lifting when it comes to readability. Modern Lisp-inspired languages (such as Clojure, but also some dialects of Scheme) also use other symbols in addition to parenthesis (like square brackets). Usually they are interchangeable, but I found that it can sometimes help.

I find it difficult to read LOOP macros. And some versions of LET. But they are bastions of readability if you compare with languages like_c<with<templates>>(T) and_macros(void);{}