3 ms·

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

by mrtron 19y ago

chris_l 19y ago
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.
jkush 19y ago
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.
- fauigerzigerk 19y ago
  I definately qualifies your mom as a geek ;-)
  - jkush 19y ago
    Hah. I told her that's what I wanted. :)
tritchey 19y ago
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 19y ago
  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.
gibsonf1 19y ago
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.

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

by mrtron 19y ago

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

chris_l 19y ago

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.

jkush 19y ago

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.

fauigerzigerk 19y ago
I definately qualifies your mom as a geek ;-)
- jkush 19y ago
  Hah. I told her that's what I wanted. :)

tritchey 19y ago

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 19y ago
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.

gibsonf1 19y ago

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.