Enterpise LISPERRRS

http://tech.grammarly.com/blog/posts/Running-Lisp-in-Production.html

One line paraphrase
Lisp is nice and we used it and here's all the stuff that was broken with SBCL I had to fix.

We use SBCL for production deployment and CCL on most of the developers' machines. One of the nice things about Lisp is that you have an option of choosing from several mature implementations with different strengths and weaknesses: in our case, we optimized for processing speed on the server, and compilation speed in the dev environment

Quicklisp repository hosts more than 1,000 Lisp libraries — not a mind-blowing number but quite enough for covering all of our production needs.

Overall, the problems we face with integrating a Lisp app into the cloud world are not radically different from the ones we encounter with many other technologies. If you want to use Lisp in production, and to experience the joy of writing Lisp code, there is no valid technical reason not to!

oh noes!

We've built an esoteric application (even by Lisp standards), and in the process have hit some limits of our platform. One unexpected thing was heap exhaustion during compilation. We rely heavily on macros, and some of the largest ones expand into thousands of lines of low-level code. It turned out that SBCL compiler implements a lot of optimizations that allow us to enjoy quite fast generated code, but some of which require exponential time and memory resources.

We had to tune the generation sizes, and it turned out that the best option was to use an over-sized heap: our application consumes 2-4 gigabytes of memory, but we run it with 25G heap size which automatically results in a huge volume for the nursery. Yet another customization we had to make — a much less obvious one — was to run full GC programmatically every N minutes. With a large heap, we have noticed a gradual memory usage buildup over periods of tens of minutes which resulted in spans of more time spent in GC and decreased application throughput. Our periodic GC approach got the system into a much more stable state with almost constant memory usage.

oh noes!

Of all these challanges, the worst bug I've ever seen was a network bug. As usual with such stories, it was not a bug in the application but a problem in the underlying platform (this time — SBCL).

oh noes!

As we were just beginning running our service under substantial load in production, after some period of normal operation all of the servers would suddenly start to slow down and then would become unresponsive. After much investigation centering on our input data, we discovered that the problem was instead a race condition in low-level SBCL network code, specifically in the way the socket function getprotobyname, which is non-reentrant, was called.

This is useful

With trace, you define a function to trace, run the code, and Lisp prints all calls to that functions with arguments and all of its returns with results. It is somewhat similar to stacktrace, but you don't get to see the whole stack and you dynamically get a stream of traces, not stopping the application. trace is like print on steroids that allows you to quickly get into the inner workings of arbitrary complex code and monitor complicated flows. The only shortcoming is that you can't trace macros.

LISP is a mental attitude rather than a programming language. It uses a certain process of the mind expressed spontaneously through keyboard. I'm concerned with retaining that process.

LISP is an open-ended programming language for open minds.

Anyone can learn Lisp in a few minutes, but nobody could master lisping in a thousand years.

It bugs me when people try to analyze Lisp as a mathematical theorem. It's not. It's feeling.

Lisp, for me, has always been a place where anything is possible--a refuge, a magical world where anyone can go, where all kinds of people can come together, and anything can happen. We are limited only by our imagination.

I hate static languages. I have to change language to my own way of doing it. That's all I know.

One thing I like about Lisp, kid, is that I don't know what's going to happen next. Do you?

The whole thing of programming LISP is not to control it but to be swept away by it. If you're swept away by it you can't wait to do it again and the same magical moments always come.

My own feelings about the direction in which LISP should go are that there should be much less stress on static exhibitionism and much more on dynamic content, on what might be termed humanity in programming and the freedom to express all that you want.

Not to deny that LISP is a thinking people's programming language, but when I'm lisping if I ever catch myself thinking, I'm in trouble--I know something is wrong.

Lispness is not a state of mind, It's a fact of life!

Surrender your whole being to LISP, and gravity disappears...with few macros, one could write code as deep as the ocean.

Macros are to Lisp what yeast is to bread--without it, it's flat.

Recursion is the ability to talk to oneself.

Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity. — Charles Mingus

Lisp is your own experience, your thoughts, your wisdom. If you don't live it, it won't come out of your REPL.

It is becoming increasingly difficult to decide where LISP starts or where it ends, or even where the borderline lies between between programming in general and LISP. I feel there is no boundary line.

LISP is what we need when other languages fail us, but we cannot remain silent.

"Lisp" stands for "Lisp Is Syntactically Pure"

If it ain't Lisp, it's crap.