Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

The Lisp vs. Python story really hasn't changed terribly much in the past five years or so. Both are still great languages once you learn to speak the idioms of the language. Both languages have persistent problems with people refusing to do so and then bitching that it's not $SOME_OTHER_LANGUAGE. Both languages have places where I'd suggest one of them over the other. Neither language is even close to a replacement for the other, and programming Lisp in Python is as big a mistake as programming Python in Lisp.

(Of the two though, Python seems to have more problems with people refusing to speak the native idioms and insisting on writing $LANGUAGE in Python instead. Python Is Not A Functional Language. It is a multiparadigm language where the functional is definitely the foreign and borrowed paradigm on top of an imperative/OO core. Ignoring that will bring you grief, but it won't be Python's fault.)

Later edit: In fact, refusing to speak Python's native idioms has been getting noticeably worse in the last six months. If you want a solid OO language with some decent functional borrowing, learn Python. If you want a pure functional language for whatever reason, do us all a favor and don't learn Python. Or at least don't add to the chorus of people complaining Python isn't Haskell, just go learn Haskell. Or Clojure, or whatever.

> The Lisp vs. Python story really hasn't changed terribly much in the past five years or so.

Actually there have been three significant developments in the last five years that IMO tilt the scales back over to the Lisp side:

1. Clojure

2. Clozure Common Lisp a.k.a. CCL (a very unfortunate confluence of names -- the fact that Clojure and Clozure differ by only one letter but otherwise bear almost no resemblance to each other causes no end of confusion).

3. The state of Common Lisp libraries has gotten a LOT better in the last five years.

Fair about Clojure, I was assuming Common Lisp. Point 3 I consider not much net change, though, as the same is true of Python, and pretty much every other competitive language.

Before, Lisp had the edge in native code compilation and functional programming, Python had the edge in libraries. In the modern landscape, that made Python win IMO. Now CL has caught up to Python (mostly -- it's 90% of the way there) in libraries and retains its edge in the other two areas, so in my book CL has pulled back into the lead. YMMV.

The state of Common Lisp libraries has gotten a LOT better in the last five years.

And a lot (perhaps equally LOT) better still in the last couple weeks, with Quicklisp. Not that I've tried it yet :)

Could you elaborate a little more on CCL? I thought it was mainly used to access Cocoa frameworks, but maybe things have changed since the last time I checked it. Are there any chances it can now work with Cocoa touch?

CCL has very good ObjC/Cocoa integration, and a well integrated IDE. But it also runs on Linux and Windows, it has native threads (that feature alone puts it head-and-shoulders over Python), and it has a wicked fast compiler. So it makes a kick-ass webapp development platform.

I don't know about Cocoa touch, but the CCL compiler was recently ported to run on ARM processors.

One down side to CCL is that it will not run on Intel boxes that don't have the SSE2 instruction set extensions. That isn't a big deal if you're doing a web application on the server of your choice (which will probably have SSE2), but if you want to use CCL on a desktop application that runs on Windows (or Linux), it could be a very big deal. People still use old computers, and I believe some of the newer netbooks don't have SSE2. If you're doing a desktop app, the last thing you want your customer to see is "sorry, you can't run that on this machine".

You can read more about this on clozure.com:

http://trac.clozure.com/ccl/wiki/SystemRequirements

And that points to a list of SSE2-capable (and some non-SSE2-capable) machines:

http://en.wikipedia.org/wiki/SSE2

I bring this up only as a caveat to those thinking about using CCL. I think it is great that it is available as a free Common Lisp implementation. It would be even better, however, if this limitation didn't exist.

> that feature alone puts it head-and-shoulders over Python

Uh no it doesn't. Python uses OS threads. It cripples them with the GIL (hence multiprocessing), but it never used green threads.

And of course, using green threads can be an advantage if you're not dumb about it (see Erlang).

> it has a wicked fast compiler. So it makes a kick-ass webapp development platform.

What?

CCL has no GIL.

Which has absolutely nothing to do with the original claim that:

> it has native threads (that feature alone puts it head-and-shoulders over Python)

As I wrote previously (and both you and lisper apparently decided to ignore), Python uses OS threads as well.

Native threads that are locked against each other by a GIL, are still native threads, but less useful native threads. An important purpose/use of native threads is that they are scheduled by the OS and not hindered by a GIL, so that in multicore machines multiple threads can run concurrently.

CCL does that. Python with the GIL not.

> Uh no it doesn't.

Uh, yes it does.

> Python uses OS threads. It cripples them with the GIL

And CCL doesn't. QED.

> using green threads can be an advantage

Not if you have multiple cores.

> What?

http://www.youtube.com/watch?v=snW3cM1KipQ

;-)

> Uh, yes it does.

That makes no sense, having the exact same feature doesn't make CCL superior.

> And CCL doesn't. QED.

QED nothing, not having a gil does something, using OS threads doesn't.

> Not if you have multiple cores.

Yes if you have multiple cores as well. You just have to map your green threads onto OS threads or processes, that's what Erlang does.

> ;-)

Smileys don't give meaning to nonsense.

Reply on news.ycombinator.com