

Why Lisp? - drm237
http://paragent.com/blog/?p=10
Lisp is not dead, it just smells funny --Edi Weitz
======
mrtron
Any major snags you have found going this route?

I enjoy working in lisp, but I find the zillions of libraries in python keeps
me coming back...

~~~
tritchey
Libraries felt like a problem at the beginning, but in the end have not tended
to be an issue for us. So far, we have been able to either find suitable
libraries, or use FFI to hook into 3rd party code. At times it seems like we
have the kitchen sink in there when you look at the dependencies, but asdf
keeps it pretty manageable.

The biggest issue we had was with a limitation in SBCL's serve-event
implementation. It turns out it uses select, which caused some nasty issues
for us when file descriptors climbed over 1024. In our case, we are handling
thousands of persistent ssl connections on the back end. We were using epoll
to service all of these connections, but the database library clsql was using
serve-event. Under certain situations, we would end up handing select an FD >
1024, and things would go all pear-shaped.

The fix was to patch serve-event itself to use epoll. It is a pretty rough
patch at this point, but it works and keeps us going.

The other area we had to punt was with our installer generation. That was as
much because we are running our servers on Linux as anything else. We have a
special windows server that creates the custom MSI files for each account.

Some times the power is a bit too much, as well. While patching a running
server with fixes is cool, I will fully admit to a couple gotchas when we
thought we were making obvious fixes that turned out to have not-so-obvious
repercussions. In those cases, the problem always existed between the keyboard
and chair. We do a better job of checking things offline before rolling them
out.

I know #lisp has a pretty bad reputation, but there are some very smart people
that hang out there, and they want to see Common Lisp succeed. In general it
is a much saner place than c.l.l.

~~~
shiro
Thanks for sharing that.

I have similar experiences that saved myself (more than once) by patching 3rd
party libraries. In our case, they were proprietary and _we didn't have the
source_. Sometime it was an apparent bug in the library, sometimes it was that
the library functionality came short to cover the cases we wanted to handle.

Inspecting their library internals with "apropos", "describe" and other means,
and defining "around" method on their internal generic functions, we could
just inject our fix or enhancement to the libraries. I admit it was nasty;
however, if it weren't Lisp, we had to file a bug report or a feature request
to the vendor and wait for them, or to find alternative libraries, or to
reimplement things by ourselves. (Open source advocates may say it was our
fault to use proprietary library, but proprietary libraries exist for reason;
besides, inspecting and modifying things without recompiling the entire
library is very useful even you have the source.)

Such emergency patching is like a safety net. In the end you may not have
needed it if everything goes smoothly as planned, but it is good to know it
exists, and even good if it saves you from disaster.

------
anaphoric
It's a silly/simple comment. but I just have to make it. Not long ago I
noticed a student writing their first LISP program using vim. I don't know
why, but the editor was not indicating ballanced parentheses. I was horrified
and got this student to give emacs a try.

LISP is my favorite language, but if you use the wrong editor, it can be hell
on earth. If you want to turn someone on to LISP, don't forget to point this
obvious fact out! I wonder how many novices get turned off to LISP because of
this.

~~~
shiro
I've heard somewhere that PG uses vi. Is that true?

Besides, there are some nice Lisp modes for vim, which not only shows matching
parens but indents, autocompletes, and does a lot more (or so I heard; I'm a
emacs user).

~~~
anaphoric
Somehow these modes were turned off and the student had one eye closed and was
counting parentheses. Not fun for him.

------
papersmith
It seems that real-time code update is one of Lisp's biggest selling points.
Any idea how this is done in a distributed environment with multiple Lisp
instances sharing the same code?

~~~
alec
It's a huge development aid - if you're running emacs and slime, you can
reload individual functions or files with a quick key combo, and if you want
code reload over multiple files, a reload function is easy to write - check
times and you're off. You can also do that with compiled code, too - instead
of (load "filename"), use (load (compile "filename")) and it'll be compiled.
The next time the functions are called, they'll use the new ones.

The tricky part is macros and inline functions. Any time you change a macro or
a function you want to inline (CL compilers can't do that automatically
because of the language spec), you need to recompile all the functions that
use that macro/inlined function. ASDF has some dependency-tracking
functionality, but I haven't used it.

~~~
papersmith
The REPL is pretty cool indeed. :) My question is, once you have to scale to
multiple machines, with a separate Lisp instance on each machine, are there
any good ways to call load once and update on all instances.

~~~
gibsonf1
You can easily set up a "reload" button in a global admin part of your website
to coordinate all instances, but my founder pointed out that the danger in
doing that is you cant see any error messages on the load that were
unanticipated, making it harder to quickly fix any problems.

We're using SBCL on Ubuntu, and we have run into some problems with compiled
fsl files. Even though we use an asdf load routine with dependencies defined,
we sometimes run into certain fsl files not properly getting updated. This is
either a dependency error on our part (most likely) or something else, and our
work around is to simply delete all .fsl files just before running the asdf
(which you can make part of the load process). So our routine is for each
machine, (2 net + local instance) is to run an svn update and then run our
loader file (sf-load) and thats it. It is most impressive to keep the same
process running and update the code with no interruption in service.

~~~
papersmith
Sorry if these are stupid questions, since all my Lisp experiences are
academic.

Do you need some kind of remote procedure call to coordinate the updates from
an admin instance?

I only know that there's the swank server for talking to emacs, is there
something similar for talking between CL instances?

Perhaps you just issue an HTTP Post for each server in a loop?

------
michaelneale
I always extend greenspuns 10th to cover any language (including common lisp
itself).

I commonly claim that my job often ends up being fulfilling greenspuns 10th
law.

