←back to thread

Hofstadter on Lisp (1983)

(gist.github.com)
372 points Eric_WVGG | 1 comments | | HN request time: 0.241s | source
Show context
dahart ◴[] No.41860159[source]
> Why is most AI work done in Lisp?

That’s changed, of course, but it remained true for at least another 15 or 20 years after this article was written and then changed rather quickly, perhaps cemented with deep neural networks and GPUs.

Other than running the emacs ecosystem, what else is Lisp being used for commonly these days?

replies(14): >>41860189 #>>41860283 #>>41860409 #>>41860450 #>>41860590 #>>41860851 #>>41861146 #>>41861256 #>>41861289 #>>41861317 #>>41861331 #>>41861541 #>>41861549 #>>41866917 #
tombert ◴[] No.41860283[source]
Can't speak for the entire industry obviously, but at a few jobs I've had [1] Clojure is used pretty liberally for network-heavy stuff, largely because it's JVM and core.async is pretty handy for handling concurrency.

I know a lot of people classify "Clojure" and "Lisp" in different categories, but I'm not 100% sure why.

[1] Usual disclaimer: It's not hard to find my job history, I don't hide it, but I politely ask that you don't post it here.

replies(1): >>41860365 #
packetlost ◴[] No.41860365[source]
> I know a lot of people classify "Clojure" and "Lisp" in different categories, but I'm not 100% sure why

It mostly boils down to Clojure not having CONS cells. I feel like this distinction is arbitrary because the interesting aspect of Lisps is not the fact that linked-lists are the core data-structure (linked-lists mostly suck on modern hardware), but rather that the code itself is a tree of lists that enables the code to be homoiconic.

replies(1): >>41860430 #
pfdietz ◴[] No.41860430[source]
I mean, you can have a tree of vectors also, so I don't see why lists are needed for homoiconicity.
replies(2): >>41860605 #>>41860737 #
1. packetlost ◴[] No.41860737[source]
That's mostly my point. A linked-list structure is not the interesting part. I use the "generic" reading of list above and don't mean to imply some particular implementation