Why Lisp? | Hacker News Reader

Why Lisp?

paragent.com

28 pointsdrm23719 comments

Lisp is not dead, it just smells funny --Edi Weitz

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...

Yes, I've done a major project in Common Lisp and had to do so many things on foot, I just ran out of steam. I guess it depends on how many libraries you can use as they are, and how much you have to write yourself anyway.

I agree. Python is a great language with fantastic support. I'm reading ANSI Common Lisp right now (it was a 30th b-day gift from mom, actually - does that officially qualify me as a geek?). I don't know that I'll get to a point where I'm predominately hacking in Lisp, but the book is clearly written and too enjoyable not to read.

I definately qualifies your mom as a geek ;-)

Hah. I told her that's what I wanted. :)

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.

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.

We're having great results with lisp. We're over 26K lines of code and about to launch, but the ability to create macros and all the other wonders of Lisp let us create extremely complex pages with very little code. We're using many libraries from db interface (cl-sql) to web server (aserve), etc. We're loving it, and my partner who formerly programmed in Java never wants to go back.

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.

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).

vim balances braces-try %

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

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?

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.

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.

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.

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?

You guys do realize that this is possible with Java, right? (It depends on your environment, of course.)

...generally, you wouldn't do this production systems, I would hope, whatever the language.

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.

Reply on news.ycombinator.com