Hacker News Reader

Common lisp isn't functional in that sense.

When I learned (Common) Lisp at Georgia Tech in the summer of 1995, we were encouraged to make as many functions as possible purely functional, and if mutation was needed, to try to hide it within the bounds of a function.

So while Lisp may not be purely functional, the culture hewed that way.

That's interesting, because I had the opposite experience. I started getting into Lisp around 2004, but bounced off of the community because the culture I was experiencing hewed heavily toward imperative code and global variables in the name of efficiency.

I specifically remember the breaking point being third-party library where none of the functions had any parameters. Instead, everything was controlled by using dynamic binding to adjust the variables within the functions. Various forum members kept praising its beauty and elegance, but I found it needlessly confusing.

I have a soft spot for the Lisp family of languages. I've been using Emacs for almost thirty years and have used both Scheme and Clojure in production. However, my experiences back in 2006 have left me with a permanent bias against Common Lisp.

Sure the language might not be immutable but the lisp machine alt universe's "overton window" would I imagine be more functional then today's (JVM? maybe that's the qnalog?) reality.

Reply on news.ycombinator.com