Is there something inherent to Lisp that allows it to be implemented in so little code?

I believe I saw someone demonstrate that almost nothing in a Lisp implementation was written as a "built-in" language feature that required the underlying interpreter to provide the functionality.

I always think of this HN post every few years, as an aside, someone really needs to archive that page it links to because I wont be surprised when that site shuts down or deletes old content:

https://news.ycombinator.com/item?id=9699065

https://speakerdeck.com/nineties/creating-a-language-using-o...

First off, you wouldn’t write an actual interpreter for lisp like this if you wanted to use it for anything serious, it’s very slow.

The parser is very simple thanks to the s-expressions, and the only builtin special forms really needed are quote, cond and lambda, that’s pretty much it. The only data structure is a list, so functions are just lists, function calls are lists etc.

Yes there's something inherent. Namely this: the ability to drop all sorts of requirements off the table, yet still call it some kind of Lisp.

It does not need to be compiled to be a Lisp. It doesn't need arbitrary precision integers. It doesn't need hash tables. Garbage collection doesn't have to work; it can just run out of space and terminate. It can just crash on errors without a trace. It doesn't need to report the line number where a syntax error likely began. You get the picture.

Lisp (and similarly, Forth) is closer to a mathematical construct than an actual language. We've had to wrap it in parentheses and named symbols to help make sense of it, to talk about it. Pairs, atoms, GCs, are all an implementation detail.

see previous discussions at https://news.ycombinator.com/item?id=14727881

quoting the submission verbatim:

The original paper of LISP by John McCarthy http://www-formal.stanford.edu/jmc/recursive.html

Or the more accessible explanation by Paul Graham http://www.paulgraham.com/rootsoflisp.html