December 06, 2005
Reddit Chooses Python Over Lisp
Reddit's Lisp-based engine was completely rewritten. In Python.
Emacs and SLIME are a killer combination, but I develop on a Mac, and reddit.com is a FreeBSD box. On my Mac, my choices of threaded Lisp implementations was limited to OpenMCL, and in FreeBSD it's CMUCL. Because of the low-level socket and threading code we had to write, reddit would not run on my Mac, and I was always tethered to our FreeBSD development server. Not being able to program offline is a pain.
If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented. Since we're building a site largely by standing on the shoulders of others, this made things a little tougher. There just aren't as many shoulders on which to stand.
Posted by jjwiseman at December 06, 2005 01:24 AM
Of course it is not just the number of shoulders but also in how many places these people with shoulder stand. With Python, Ruby, Perl, ... you have basically only a single implementation so all libraries work for that one implementation.
For Lisp there may be many good libraries but you are almost guaranteed that for any good selection of libraries you won't find an implementation that works with all of them so you are back to square one: doing it yourself or modifying the library to work with your choice of implementation. The latter is often a non-trivial task as for certain basic things (e.g. characters, sockets) implementation details vary more than would be expected.
Incompatible implementations are annoying, though I can't 100% agree that there are no shoulders to stand on. Thanks to such giants as Edi Weitz programming web applications with common lisp is a lot easier than it was a year - two ago.
My blog is written 100% on common lisp and with less than 500 lines of code I have some ajax, syntax highlighting, ZopeExternalEditor support, rss feed and i can administer the blog through ssl while *everything* I am using is asdf-installable:
tbnl, cl-ppcre, yaclml, cl-fad, net-telent-date, xmls, colorize.
It would be interesting to know what are the libraries they needed and that they did not find in lisp.
I have been using sbcl/tbnl for my little web-applications and I have not yet needed anything that was not already written and distributed as free software.
I didn't say the are *no* shoulders to stand on. There are just fewer.
Without a doubt, Edi Weitz single-handedly made reddit possible. He's an army-of-one producing good Lisp libraries. The issues that made it really hard to stick with Lisp weren't particularily Lispy.
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.
It's interesting that Ignas' comment adds more evidence to the claim about things not working together. As an example, tbnl requires threads. OpenMCL has threads but runs on MacOS only. SBCL and CMUCL have threads, but only for certain arch/os combos. For freebsd, which was specifically cited by the reddit guy, I don't think there is a free implementation that does threads, therefore no tbnl. Perhaps some of the commercial implementations support threads, but then you're comparing a free language and its free, open-source implementation to a commercial product, which is a whole different comparison. Yes, these implementations can, should and hopefully will be extended to support threads, but the current lack of a free, threaded lisp on freebsd seems like a deal breaker to the reddit guys. Makes some sense, if you ask me.
Now that my ANSI testing work is winding down, I'm thinking of devoting my time to beefing up/pulling together libraries.
I don't like the approach of having users pull libraries from many places on the net (asdf-install). It's a nonstarter from a configuration management point of view. I think there's room for the equivalent of linux's distributions; that is, coordinated collections of libraries and utilities that have been tested together. Who knows, money could be made this way, like the linux distributors have.
Allegro provides excellent shoulders to stand on, but it costs money. Well worth it in my opinion.
I'm not at all surprised that the original implementation, which grew into what it was, where the authors didn't know what they were building from the start -- I'm not at all surprised that it had some weird bugs and stability problems. Nor am I surprised that the rewrite is more stable. However, I would be surprised if this effect had anything to do with implementation language. Stability and easier extensability are the things that normally come out of rewriting prototypes, regardless of the language(s) involved.
Couldn't he have investigated a Scheme? Would that have been so bad?
Gambit-C 4.0, a Scheme system that compiles to C code, can handle up to 1.35M threads (yeah, 1.35 million) with 2Gigabytes of RAM. (Compare this with Red Hat's NPTL which can handle at most 0.38M threads.) Threads are REALLY cheap (thread creation takes 2.5 microseconds on a 2.8 GHz Xeon).
Gambit-C would probably work on FreeBSD (the developers just didn't test it) and it does compile on MacOS X.
I believe Bigloo would also fit his requirements
(maybe DrScheme, too).
Here's a little comparison about threads in Schemes:
Methods of threading implementations in Scheme implementations.
Gave up too soon?...
Henry Lenzi, if you were betting the farm on a real-world web app, and found that Lisp had too few libraries and lacked stability, would you switch to Scheme? I wouldn't. I'd switch to a language that has a large community and is battle-tested, which means Perl, Python, or Ruby (I refuse to say the J*** word). Even though I think those languages are far inferior to either Common Lisp or Scheme.
rps, I believe the premise to effect that Lisp has few libraries and lacks stability is itself debatable. The self-imposed constraint of 1) OSX development and 2) FreeBSD deployment and 3) OSS implementation and 4) native threading, may understandably be a issue. However, LispWorks or ACL, I believe, satisfy the requirements, except for the 3), which begs the question "Why OSS?". Then there's 5) libraries (which ones did the reddit authors miss in Lisp that they couldn't at least link to via FFI?) and 6) language community (have they approached the Lisp community for help and failed to get any?).
Yeah, P-P-R is tried and true. Wait, is it? What was Ruby 3-4 years ago? Would you trust Ruby before the hype of Ruby on Rails? How about Perl before Perl5 ? It didn't even have lexical scoping! I didn't see /that/ stopping people from using it.
People get easily enthused over new scripting languages. /Still/, they forget that the /majority/ of their new cool hacks (continuations, metaprogramming) comes from the Lisp Well.
I'm sorry rps, but I'm not so sure there's ample evidence to support the view that Scheme and Common Lisp are lost causes. We have seen again and again a large part of the programming community take up these scripting languages with great adoration. One thing is clear, though: it seems the crucial factor is always libraries, integration with the underlying OS, and ports to various UNIXes and Windows. These are the only true technical merits I see in Python, Ruby and Perl that make them "superior" to Common Lisp and Schemes.
The type of programmer that just thought Ruby was truly revolutionary was the type of guy who never could see the Smalltalk in it. Unfortunately, free Common Lisp have problems in the 3 areas I mentioned, and I think free Schemes do somewhat better (an opinion shared by Bill Clementson (see: http://bc.tech.coop/blog/040111.html)). Maybe technical difficulties and differences between the huge CL and the small Scheme are factors in this problem, I don't know.
I can undestand some criticism, but apparently emotional factors are playing a role too.
Person with no name: I suspect that 4 years ago few people were using Ruby when they needed it to scale like reddit will need to scale if it becomes as popular as its creators hope, and when the personal stakes were as high as they are for a startup. I suspect that Ruby users were probably hackers who were willing and able to take the time to write or fix libraries if problems cropped up (I also suspect that the average IQ and skill level of Rubyists is plummeting like the Hindenburg as it becomes popular, BTW).
I'm writing a web application in Scheme, despite the many libraries I'm missing, so I'm basically one of the converted. But the fact of the matter is, I could have made faster progress in P-P-R because I'm implementing things that P-P-Rers get for free, and fixing library bugs that would probably have been discovered if they were more popular. I can live with that. I like Scheme, I don't like P-P-R, my non-existent startup won't fail if it takes an extra month. But if you're running a startup, you're under more pressure and you don't want to debug other peoples code and write libraries when you don't have to.
What about webapps in scheme using siscweb you get to use scheme + all of java's library goodness.
I also develop on a Mac, and my deployment platform is also FreeBSD, and I have no problem with compatibility (perhaps because I use one implementation on both platforms: CLISP).
The point not yet mentioned: do they really need threads? Is load so big that old good 'select' (buried under something like CORBA or UCW) doesn't do the job?
"I also suspect that the average IQ and skill level of Rubyists is plummeting like the Hindenburg as it becomes popular, BTW"
Actually, from someone who's been with an obscure language and cringed as it's been thrust into the mainstream I would say that you lispers have no idea how good you've got it. Your language is nice and powerful but too obscure for the plebs to get their sticky, buzzwordy hands all over it (unless of course, they're quoting paul graham blog entries).
I don't know exactly why it bothers me so much but Rails, and the recent rise of Ruby makes me itchy. I have a sneaking suspicion that all of you lispy fiends would feel quite similar if Lisp all of the sudden regained popularity.
I guess what I'm saying is- work on improving shit but stay the hell away from trying to make it popular because that would just fuck it up for everyone.
"I guess what I'm saying is- work on improving shit but stay the hell away from trying to make it popular because that would just fuck it up for everyone."
What arrogant bull**** this is. This reminds me of the "damn foreigners" attitude that Americans have--like their ancestors were born in America or something.
How would making something better mess it up for everyone? Imagine if Edi Weitz or Peter Siebel hadn't latched on to Lisp. Who cares about posers--they're mostly harmless and end up jumping ship to the next hyped thing anyway.
This whole Reddit thing should be seen as an educational tool about how the outside world (including potential Lisp contributers--when did you first hear about Lisp and what did you go through?) sees Lisp.
Yeah, it is arrogant and it's also at least half bullshit.
However, there is something very real to be said though about a close community of users with a passion for a language. That changes in a very big way when a language becomes mainstream. That said I am quite happy about the good things that are happening with Ruby since it's ramp up in popularity such as the maturation of its libraries. I'm just a bit bummed as well.
One of the biggest issues was the lack of widely used and tested libraries.
ONE of the issues?
Why not give a full and honest answer to why you changed? I find the "libraries" explanation to be very weak.
Go ahead, 'fess up: give us a list of detailed problems and bugs encountered, tell us who made the decision and what inputs he had. I'll be there were more than a few Pythonheads unfamiliar with Lisp involved.
"One of the biggest issues was the lack of widely used and tested libraries."
Is this really true ?
Using Lisp was a first clever move. They received funds from a special VC firm which was only too happy to support a Lisp start up. They gained high recognition within the small group of Lispers. And they can always adorn themselves with knowing something exotic, like rocket science. This is not bad for daily live, if you can prove that you are are not a muser and came down to earth.
That's why they now go mainstream. May be the next funds will only be provided if they demonstrate that they cope with a well established widely used technology. Then it is a second clever move to use the existing Lisp system and transpose it to the other language on a weekend. They do not need "standing on the shoulders of others", they stand on their own shoulders.
One can argue that they betrayed the worth of a philosophy merely for cheap money. But didn't they use Lisp for what it is famous, rapid prototyping? From this perspective it looks very positive. Use lisp for system development and testing, then transfer it to any suitable platform. Thus, reddit is a real proof of the power of Lisp, it is already popular and will gain even more popularity.
Remember that a very popular success story of Lisp, viaweb, started out from not too much Lisp content, see footnote  of "Beating the Averages" by Paul Graham.
But still, the above statement is not convincing.
One can argue that they betrayed the worth of a philosophy merely for cheap money.
Ye gods, enough with the conspiracy theories already. Y Combinator didn't know Reddit was going to use Lisp when we funded them. And the reason they switched (or at least, the last straw) was all too mundane: some thread bug in CMUCL that made the site keep crashing.
Thing is, they made a typical newbie mistake of choosing the OS before they choose the software to run on top of the OS. There is little reason to run FreeBSD over Linux, if Linux gets you threaded execution that works better - the better threading will beat out any BSD advantages.
Second, they have shown they don't quite understand how to run servers in production - the errors should have been caught immediately with a monitoring script and the offending daemon process automatically restarted.