
How Lisp Became God's Own Programming Language (2018) - Qaphqa
https://twobithistory.org/2018/10/14/lisp.html
======
okine
Gerald Sussman, co-inventor of Scheme and author of SICP, was my undergraduate
advisor. The last several times I visited his office, he was usually with Jack
Wisdom either programming or deep in thought or discussion about differential
geometry and the differential geometry Scheme library they were writing. One
time when he wasn't so occupied, I brought up SICP, and asked if he was aware
that a lot of people think of reading the book as a sort of magical,
enlightening experience. He said, "Yes, I'm aware." I asked if he had any idea
why. He said, "The main reason is that it tells a good story. It also has a
complete, coherent narrative."

~~~
Rerarom
Am I the only person that read the whole of sicp and didn't feel enlightened
in the least? I felt way more enlightened when I read the whole of John Baez's
this week's finds. Maybe it's a book which you need to read when you're
younger.

~~~
gdubs
Curious: did you complete all the exercises in the book? Not doubting you in
any way, just wondering if that’s a possibility. I know I’ve gone through
books without doing the work, while on others I have done the work — and it’s
usually a pretty different experience.

But, not everyone is gonna connect with everything, regardless.

------
mark_l_watson
I have never minded using a so-called niche language. Since 1982 I have been
very fortunate enough to be paid a good fraction of my time for using Common
Lisp - I consider this to be largely good luck and I am grateful for how
things turned out. I also like Scheme but literally no one has ever paid me
for Scheme development. In the USA, we have a saying that “you dance with the
person you go to the party with.” My dance partner has been Common Lisp.

I still feel like I am still a student. I started to read Let Over Lambda (a
reference to closures) a few months ago which has reinforced my realization
that there is so much about a programming language that I have used for 38
years that I still want to explore.

All that said, I have often totally enjoyed building systems with C/C++, Java,
Python, Prolog, etc. Designing and writing code can be fun in any language.

~~~
jjtheblunt
Didn't you work at CCSO back when Prof Kaplan was just down the hall, unless
you were in another building...have you read the Guy Steele original papers on
Scheme? They're actually awesome.

~~~
mark_l_watson
No, that was not me. I do like Scheme (and a long time ago I wrote a Scheme
book for Springer-Verlag), but I was just saying that I haven't used the
language professionally.

------
herodotus
Reading "Lisp 1.5 Programmer's Manual" when I was a post-graduate student at
Waterloo (around 1977) was a revelation to me. In particular, "Appendix B: The
Lisp Interpreter" gives a version of the Lisp interpreter in just 39 lines of
code! (The appendix includes notes, and is 3 pages long.) I remember using
this code to figure out how Lisp evaluated recursive functions. Until this
point in time I had programmed in Fortran, IBM 360 Assembler, Cobol and
Pascal. They all required much more documentation, and, in many cases,
experiments to figure out what would actually happen in certain cases.

I wish the idea of a definitive high-level semantic guide had become a thing.
SwiftUI, for example, seems to be wonderful, but learning it, as far as I can
tell, requires watching hours of talks, or working through many tutorials.
What a contrast with McCarthey at. al's 1985 book.

------
jhbadger
I'm surprised that this didn't bring up Paul Graham's "Blub" concept, in which
non-Lisp languages are thought to be objectively less powerful than the
universal language of Lisp. That's been a lot to blame for the mystical
reverence of Lisp in the 21st century. While I'm a Lisp fan myself, and agree
that it is more powerful than a lot of mainstream languages, the idea that it
is the "most powerful" blinds a lot of hard-core Lisp devotees to things like
Haskell that are worth exploring as well.

~~~
goto11
The "Blub" parable is really clever because it says that when other people
doesn't use Lisp, it is simply because they are _incapable_ of understanding
its power - not because of any practical or technical reason to chose another
language. So any argument the "Blub" programmers might use to justify "Blub"
is automatically invalid.

Of course it can be used for any non-mainstream language, and I have seen it
used for Haskell, where Lisp is the "Blub" language.

~~~
exdsq
I’ve had this recently. Was writing Python but missed the ease of concurrent
functional programming. Used F# but missed type classes. Used Haskell but
missed dependant types. Use Idris but miss the build environment of Python.

~~~
bcrosby95
Yes, once you learn enough languages I feel like you just find yourself
constantly wishing you had aspects of another language, pretty much regardless
of what language you're using. Sometimes its directly related to the language,
sometimes its something like the ecosystem surrounding it.

This is why I'm wary of "right tool for the job" when it comes to languages.
In my experience usually there isn't a singular obvious right language. Maybe
one is 35% right, another is 38% right, and the golden ticket language is
actually just 45% right. And sometimes you won't really know until you're
halfway through the project.

If you wanted a 100% singular obvious correct language, you would have to make
a custom language with traits from a dozen different ones. But in the real
world, the differences between languages you can actually choose from end up
being not that large.

~~~
AnimalMuppet
I think of languages as a multi-dimensional tree, with branches extending in
different directions. I think that the trick is to figure out what the yak-
shaving aspects of the project are going to be (which you can think of as a
vector), and picking the language that goes the furthest in the direction of
that vector (and thereby does the most to minimize the yak-shaving). This
requires that you be able to fairly accurately determine what the yak-shaving
will be up front (which can be problematic).

------
JetSetWilly
I would have thought God would write binaries directly in machine code. The
only purpose of a language, is to allow creatures of limited intelligence to
create abstractions that hide complexity and allow complex problems to be more
easily reasoned about.

Presumably God does not need to use abstractions, and can reason perfectly
with an infinite number of variables, so a programming language would just
prevent an Omniscient being from being able to create as perfect a program as
it could otherwise (as any given programming language doesn't let you create
any binary).

~~~
0xebfc
Machine code is an abstraction, too.

In a Judeo-Christian context, God seems to operate in very abstract terms.
"Let there be light" is a highly abstract instruction.

In some other religions and mythologies, there isn't a single God giving the
instructions from outside, so it seems difficult to make the comparison there.

Abstraction is like a lever, and by first-order logic there is no way to avoid
using an abstraction whenever we communicate, whether internally via vocalized
thoughts, via hn or by some really old books. Maybe that's why humans want to
believe that abstraction is so powerful. Thankfully, we're not totally wrong.

But thank you for making me imagine a world where the "Let there be light"
statement has been meticulously explained in as much detail as possible.

"Then, He realized that adding an extra electron to Hydrogen was not such a
good idea; the entire universe shattered, and, after a brief moment of
embarrassment, he comforted himself with the fact that no-one will ever know
of his folly.

He continued calculating the correct speed-constants for a particle he made
called a photon, which wasn't exactly a particle, but it was small and didn't
carry a lot of weight, it was everywhere, and it was mostly directional -- so
he figured it might be useful for some sort of massively parallel input
apparatus, and his creations can use it to understand all sorts of things
about their environment and themselves. Eventually, humans will suspect that
light is a wave, too; but that wasn't quite right, either. God made is
difficult to figure out for copyright protection reasons, but here's a hint,
and get your notebooks out: ..."

~~~
nwsm
> "Let there be light" is a highly abstract instruction.

The more I think about this, the more I realise it might be _the most_
abstract instruction. It's actually kind of beautiful.

~~~
int_19h
I once worked in a company that used a similar approach. So, for example, the
"chief architect" would file a _bug_ in the tracker titled, "Product X does
not exist". It would then be up to the engineers to "fix" it by creating the
product.

No wonder Satan rebelled. ~

------
at_a_remove
I have heard for decades how Lisp is transformative, how just having learned
it, even if you leave, you will never look at things the same way again. Like
having served in the Armed Forces.

Every so often I get interested in Lisp, but I always run up against the same
conflicts. I look for something that I can run in Windows that has a
reasonable set of libraries and then immediately stumble upon the Crusades.
You know, the religious wars you saw with emacs vs vi, wars that used to be
fought over various Linux distros and window managers, that you will now see
about different flavors of agile or whatever. I am quite sure that there are
religious wars being fought in the territories of Javascript frameworks that
I've never heard of. These wars so often seem to leave the territories barren,
the original objectives cloudy, and the participants scarred. What _was_ this
good for, again?

Anyway, every time I encounter these things I end up asking myself if I have
the knowledge to pick a side in whatever war and if joining up is going to
actually provide a solution to the problems I wanted to solve using
programming, decide I am neither fit nor armed, and back slowly out of the
room.

~~~
kerkeslager
I'm saddened by your story. Our programming communities can be more welcoming.

That said, I think these debates are necessary. Fixing problems starts with
deciding what the problems actually are. The problem isn't that the debates
are happening, it's that people like you are getting dragged into them.

You aren't obligated to participate in debates. Nor do you have to use the
absolute best version of Lisp to get most of the benefits.

My advice is to pick up a copy of MIT Scheme (works on Windows) and then work
through Structure and Interpretation of Computer Programs (SICP), and don't
read anything else about Lisp until you're done, because you don't need to.

MIT Scheme isn't the best Lisp. It's just the Lisp that's used in SICP. You
won't win any debates arguing that MIT Scheme is the best Lisp. You might even
hear people say MIT Scheme isn't even a Lisp. I agree with some of that, but
those debates are irrelevant to your learning.

Feel free to hit me up with any questions. I certainly have opinions on all
the holy wars, but I won't bring them up, I'll just help you with the task
you're working on. :) I'm not a Lisp expert by any means, but I've worked
through most of SICP.

~~~
at_a_remove
I have looked over the site once a long time ago, when I had a copy of SICP in
hand. I just looked now.

What I do not see is a robust set of libraries that can help me accomplish the
solving of real-world problems. As mercenary as it sounds, I program to solve
problems my employer has in exchange for money. I solve problems that people
have, rather than problems that books abstractly propose. While Lisp or
whatever dialect might be lovely, it may as well be Logo for practical tasks.
I do not want to re-implement JSON. I do not want to try to write my own ODBC.
I need something beyond a language that lets me solve the problems written in
a book that is divorced from real-world stuff, and that has, for the past
couple of decades, meant libraries.

"The Lisp Curse" is a pretty good explanation of why I won't see those
libraries and the situation hasn't changed, that I can see, since I first read
it.

At the end of the day, if I want to learn a language, I want to have done it
for more than the sake of having said that I have climbed that particular
mountain. I need something up top that is valuable. Climbing it has to have
real-world applicability to me.

Can I use Lisp to interact with these GIS formats and solve real-world
problems? Not without building my own libraries, and so on. This is why I have
liked the war metaphor: all of these folks skirmishing when they could be
building factories.

I am not asking for Lisp to be Python or Perl or whatever. But it should have
a great standard library. Where is this?

~~~
jerf
"What I do not see is a robust set of libraries that can help me accomplish
the solving of real-world problems."

I think the suggestion wasn't to give you the One True Answer to which Lisp to
use. The purpose of suggesting working through the SICP book is to give you in
concentrated, curated form the insights that Lisp is supposed to bring,
whereupon you should turn around and bring those insights back to whatever
normal programming world you inhabit. To the extent it is divorced from real
world stuff, yeah, that's on purpose, and the entire point of the
recommendation of SICP.

Fortunately, the world has changed since the SICP was written. At the time,
there was a much larger barrier between Lisp and the "real computing world".
While by no mean do all languages look like Lisp now, there has been a _lot_
of seepage, and now there's plenty of languages where you can bring the stuff
in SICP into the language you use day-to-day.

The idea is this: You could learn a new language, a couple of frameworks,
half-a-dozen libraries, fight through bugs in all of the above in some
immature cutting edge library, and also fight through a lot of accidental
complexity because you accidentally selected some task that the weird new
language is not very good at, only to arrive after all of this with some new
insights about how computation works and what languages can do after a year or
two. Or, this suggestion is, learn a very small new language and read a guide
book, get the concentrated insights in a few months at most, and then continue
using the frameworks, libraries, and experience you already have.

(Personally, I recommend SICP as the perfect companion to any self-taught
programmer. It is almost laser focused on the sorts of things that the self-
taught programmer will find hardest to pick up on their own. Finish it and you
really will be able to code circles around most college grads, beating them
both practically _and_ theoretically.)

~~~
at_a_remove
I did this once with Prolog and did not come away with the benefits espoused.
I was told that it would really change how I thought about things and so
forth. That didn't happen. I didn't get anything out of it that I could bring
elsewhere. I fear the same result after a similar investment in a similar
situation.

~~~
kerkeslager
_shrug_ That's the risk you take whenever you learn _anything_ new--maybe it
won't be useful.

The alternative is, of course, never trying anything new or learning anything
ever again. Your call!

------
lgas
I thought HolyC was God's own programming language.

------
somewhereoutth
I would have thought that the Lambda Calculus has a better claim to be 'God's
Own Programming Language'.

Apparently McCarthy was aware of, but had not studied, the LC. One quote from
the article stuck out:

"McCarthy invented an alternative, the “true” conditional expression, which
returns sub-expression A if the supplied test succeeds and sub-expression B if
the supplied test fails and which also only evaluates the sub-expression that
actually gets returned."

this is how 'true' and 'false' are encoded in the LC, (\x \y x) and (\x \y y)
respectively, and the final sentence indicates lazy evaluation.

The early (wrong) choice of dynamic vs static (lexicographical) binding, since
corrected, suggest the language was far from 'handed down on stone'.

Homoiconicity is very nice, though I suspect that the macros it has enabled
are often perhaps too powerful a tool.

------
blackrock
It was Einstein that said, “Everything should be made as simple as possible,
but not simpler.”

I think the problem with Lisp, is that it violated this principle.

It has a lot of strange little constructs. It came from a time when
programmers tried to type as little as possible. In doing so, the language
adopted all these little quirks. I’m not saying it’s bad, but it’s just
different.

Whereas the human mind is a simple graphical machine, and we like to see
associations. Like, the usage of an equal sign, to see that we’ve made a
variable assignment. Maybe this reaches back to our childhood algebra days,
where we associate equivalence with an equal sign. Who knows.

But Lisp did away with all that. It created its own style. It gave us
parentheses to enclose our statements, which is to be honest, actually a nice
feature. But it forced us into knowing the specific ordering, sequence, and
symbols in order to make a legal statement.

Anyways, I like Lisp, and have always been wanting to use it for something.
But not quite sure what.

It’s great for writing short macros in Emacs though. You can write a multi
line function, then compress it back into a single liner, because of the
parentheses. This helps keep your config file short.

It doesn’t really work for video game programming, as it doesn’t seem to have
the libraries for it. It’s not as fast as C for speed critical applications.

It kinda lives in that medium realm, where internal business applications can
use it for internal business processing, that can run uninterrupted for
decades. But, this space is where Python excels at.

Anyways, one day, I’ll finally create that programming language idea of mine,
and it’ll be some fusion of Lisp and Smalltalk, but can run almost as fast as
C.

~~~
gumby
Some implementations (e.g. Common Lisp) have legacy oddities in them for back
compatibility but newer implementations like scheme tend not to. Instead of
CAR and CDR they have first and last, for example.

Emacs lisp is quite slow but adequate for purpose. You can write very high
speed numeric programs in Lisp — another book by Sussman was on HN the other
day and it’s all about physics, all written in scheme. The fact that code is
data allows lots of complex optimizations that are harder or impossible to
represent in c

~~~
Oreb
I think you got this backwards. Common Lisp does have `first` and `rest` as
synonyms for `car` and `cdr`. As far as I know, Scheme does not. I believe you
have to use `car` and `cdr` there (unless, of course, you define your own
synonyms).

I could be wrong about Scheme: My Scheme knowledge is badly outdated, and was
always incomplete.

~~~
sigzero
Racket has `first` and `rest`. I just tried it. But I tried an online scheme
interpreter and it did not have it.

~~~
catalogia
first and rest are in racket, but racket has many things not in scheme (and
doesn't have some things that are.) If you use the r5rs #lang (e.g. `racket -I
r5rs`) you'll see that it doesn't have first and rest.

Also, first and rest in racket aren't synonyms for car and cdr. car and cdr
take pairs, while first and last only take lists. Try this: (car '(1 . 2)) and
(first '(1 . 2))

------
Qaphqa
The fractal flowers and recursive roots: The most lovely hack I’ve seen.

~~~
steve_gh
"To iterate is human, to recurse is divine"

[not sure who I am quoting]

~~~
gumby
I’m pretty sure that was guy Steele and he would have written “recur” (like
“to occur”)

------
kelvin0
Lisp has many parallels with Ayahuasca: Both are tough to 'swallow' and not
everyone comes out on the other side 'enlightened'.

No doubt about the potency of both though ...

------
sgt101
I like the Prolog story "PROably the Language Of God"

~~~
amelius
LOGO is the Language Of God, and we are His turtles.

    
    
        L: Language
        O: Of
        G: God
        O: Only God knows what the last "O" stands for.

~~~
DonHopkins
A tail recursive acronym!

------
tardygrade
The responses I see to lisp seem to vary on a huge range from idolatry to
dismissiveness. It's interesting that Gerald Sussman's own point of view on
lisp seems to be very much more moderate - that different programming styles
and philosophies suit different domains, and ultimately, you should choose the
right tool for the right job. Lisp is flexible in that it does not bind you to
any philosophy, and is good as a general tool insofar there isn't a
specialized tool that would fit the problem better.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=18225870](https://news.ycombinator.com/item?id=18225870)

------
eternalban
It is borderline blasphemous to think God can't handle a little syntax and
would use barebones parse trees cum s-expressions. Do you see DNA chains
cranking around without a higher layer phenotype? You do not. QED.

------
forgotmypw17
I thought that was Perl...

~~~
nathell
Obligatory XKCD: [https://xkcd.com/312/](https://xkcd.com/312/)

~~~
colomon
Wait, isn't this the obligatory one in this context?
[https://xkcd.com/224/](https://xkcd.com/224/)

~~~
nathell
Yes, in the context of the OP. But in the context of someone mentioning Perl,
the one that I quoted makes sense.

Here's the Frost poem alluded to:
[https://www.poetryfoundation.org/poems/44263/fire-and-
ice](https://www.poetryfoundation.org/poems/44263/fire-and-ice)

------
jankotek
Obligatory xkcd reference: [https://xkcd.com/224/](https://xkcd.com/224/)

~~~
mellavora
i was wondering what took so long for this to be posted

------
Koshkin
This, then, is a proof of the multiplicity of gods (there must be at least as
many gods as there are Lisps).

------
ertucetin
Try Clojure, learn properly then we talk...

------
phoe-krk
A lot of people, including some prominent faces in the programming world in
general, have been writing about Lisp as secret sauce, silver bullet, God's
language, source of programming enlightenment, yadda yadda; basically a set of
mystic-sounding buzzwords that, other than causing some people to indeed try
Lisp, have left a lot of people confused and amused by the wording - or just
plain angry and disappointed at the false marketing that I consider the above
hyperboles to be.

I can see the benefits of the comments that follow the "any publicity is good
publicity" rule. In addition, the more-functional-in-approach Lisp dialects
certainly follow the "breaking the long-built mental model" scheme that you
mention, and so does Common Lisp, since it mixes programming paradigms
(including functional one) rather freely. Still, after seeing the effects of
the aforementioned hyperbolization of Lisp in the long run, I'm not convinced
that its execution went well at all.

Lisp is a very good language, but no, sorry, it's not the Magical Silver
Bullet of Enlightenment™®© that some people like pg or esr or (to some extent)
the author of this post claim it to be.

~~~
reikonomusha
I think it _is_ a silver bullet of enlightenment of a certain understanding of
what programming languages are. It is _not_ a silver bullet for all of your
programming tasks or problems.

Most people I know who cast off Lisp are people who read the Wikipedia page,
didn’t feel enlightened, then began to complain online about how they were
disappointed by their Lisp experience. Or perhaps they went a tad further, got
upset by Emacs being unfriendly to setup, and proceeded accordingly.

In the Modern Age (TM), programming Lisp is unlikely to convince you to change
your usual dev stack to it. But if learned properly, it will enlighten you on
the structure of a language and how syntactic malleability is a powerful
abstraction for solving many kinds of problems.

Enlightenment usually comes from realizing that it’s not a feature bolted onto
Lisp, but an exposed interplay between many otherwise ordinary aspects of
programming languages: syntax, semantics, interpretation, and the runtime. At
this point one typically “sees” how this interplay could (and perhaps even
opaquely does) play out with other, non-Lisp languages.

These kinds of things could in principle be learned in a compiler course, but
compiler courses tend to be extraordinarily opaque as to how such a course
would help your day-to-day coding. Lisp provides a visceral, hands-on
experience of many (though certainly not all) of the same principles.

If you happen to be the kind of programmer who likes absolute control over
your environment, because that helps you work through gnarly problems more
efficiently than duct taping a bunch of dependencies together, then you may
actually end up switching to Lisp.

~~~
cat199
> syntactic malleability

this is the key point - not quasi/proto FP

most comments I see that are skeptical of the 'lisp as magic' claim seem to
focus on the quasi-FP-ability of lisp, leave out the fact that the lisp family
is pretty much unique when it comes to _symbolic programming_ , and then
optionally go on to talk about how some typed functional non-symbolic language
is a better functional language.

this is ignoring the 'too many parens', 'no market share', and 'doesnt work
well in my editor' people.

~~~
lisper
Syntactic malleability is actually a red herring. The key insight of Lisp is:
Lisp code is not text. Lisp code can be _serialized_ as text, and it can be
_parsed_ from text, but it is not text, it is S-expressions, and S-expressions
are not text, they are data structures, specifically, they are trees of cons
cells. And because they are trees of cons cells you can construct them without
ever constructing any text, i.e. without any parsing.

Syntactic malleability is a _consequence_ of this property of the language. It
is not in and of itself the central idea.

~~~
cat199
good point..

though arguably if code is data we are somewhat saying the same thing :)

in any event, this unique overall property/combination of properties is often
overlooked in these discussions

~~~
lisper
The "code is data" slogan also misses the point. Text is data, so all code is
data, whether or not it's Lisp code. (The only code that isn't data is code
that has been compiled down to hardware. In the olden days computers were
programmed by plugging wires into plugboards. That code wasn't data. But any
code that is rendered in the same medium as the data it processes is data, and
nowadays that includes all code.)

What matters is that text is structured fundamentally differently from trees
of cons cells. Text is a vector of characters. It is a fundamentally flat data
structure. It is well suited for humans to read and write with pencil and
paper, or chisels and stone tablets. It is not natively suited for describing
hierarchies of abstractions, which, it turns out, is what you want when you're
writing code.

