Hacker News new | past | comments | ask | show | jobs | submit login

"I never had problems with SBCL on any machine"

I did, and so did this author.

So who's anecdote wins?




Reddit was initially built on CMUCL on FreeBSD. Here is what Steve Huffman said on why they switched to python one weekend.

"The biggest trouble that plagued us was that we could never quite get Lisp reddit stable enough to sleep at night. There were weird threading issues that would bring the site to its knees a couple times a day and required constant monitoring."

You can read more of it in this blog entry.

http://www.findinglisp.com/blog/2005/12/reddit-and-lisp-psyc...

Edit: Corrected :-)


Reddit wasn't built on SBCL, which you would know if you had read the blog entry you linked to.


I used CMUCL a bit, and SBCL almost never. Does SBCL really deliver on what it set out to do? Is it better, faster, more portable? As far as I know, the Windows port never matured. Which of the two do people recommend using?


SBCL set out to make a version of CMUCL that was easier to build and maintain. I'm pretty sure that was delivered.

But of course that's not of much interest to the average user. I think SBCL is in general faster, is developed more actively, has more features that are relevant in the modern world (eg. lose a Motif interface, gain native threads), and currently runs on more platforms than CMUCL does.

My impression is that most people using CMUCL are ones who started using it 10 years ago and are comfortable with it, new users would tend to go with SBCL. But I'm biased, so it's quite possible that there are real and substantial reasons to prefer CMUCL.


_...the Windows port never matured_

I was subscribed to SBCL list some months ago. I could see that Windows port was quickly progressing. "Never matured" suggest a project that was tried and later abandoned. It seems more of an ongoing effort. Versions are still being created regularly. I would try in a few months.


They would have had fewer issues with sbcl on linux.


As did I. In my case, the problem was running it on a VPS that had no user-visible swap, no way to add swap space and possibly some other memory-related oddities that I don't remember. The workaround ended up being to limit SBCL's memory usage with --dynamic-space-size.


Noone's. The point is it's not a valid argument. The sameway the author had problems deploying SBCL on his machine, I could have problems deploying JVM on mine.


I'm going to have to disagree with you here. You rarely hear about people having issues getting the JVM set up on a random machine. On the other hand, deployment of SBCL is a complaint you hear somewhat regularly from people using shared hosting.

It's not necessarily a fault of SBCL, as much as it is a function of Java's popularity. But to say they equally share deployment problems seems a bit misguided to me.


Yeah, you are probably right. Because of Java's popularity and high demand, hosting providers have to be Java-ready and nowadays, it's not a problem.

However, it seems I've been living in a cave. Besides the Reddit case, I haven't heard (or at least can't remember) about problems running a CL environment. Can people who had this problem please reply - what disto, what implementation, what was the issue?


My experience trying to move some code from SBCL/OS X to a particular version of Linux is partially documented here.

http://groups.google.com/group/comp.lang.lisp/msg/0450136edf...

The use case was a final class project, where the instructor needed to be able to run the final version of the program just by executing a script in an unpacked tar file. Couldn't get SBCL to run with the limited time I spent on it. Got CMUCL to run, but not in a way that could be deployed in a self installing manner. Punted and used Java (was easier to work with team members that way, too).

Clojure would have been perfect.


I've had a lot of issues with JVM in a cheap hosting with Virtuozzo (a VPS). I assume people that are using Java choose a provider that gives it preinstalled.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: