Live data from Hacker News

Ask PG: Lisp vs Python (2010)

news.ycombinator.com

71–80 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#71
post #43

This question sounds like it's from 2005 rather than 2010. Lisp seems to have become fashionable again now, thanks to Clojure. I'm sure Python has very good libraries, but I would find it constraining to program in a language without proper macros.

The Python philosophy is that macros do more harm than good, making it harder for someone to read/understand your code in the long term. These and other "constraints" make the code more accessible to others and even yourself.

Macros are just another abstraction tool. If you poorly use an abstraction tool, it makes the code harder to read, if you properly use an abstraction tool, it makes the code easier to read.

Here's a function that makes code harder to read:

def sumAList(aList): return 7

This doesn't mean that functions are bad.

Now there is an argument that macros make code harder to read in that I've yet to see a really good macro system that isn't dependent on the code having very little syntax (e.g. S expressions), since the more different the code is from the AST, the harder it is to manipulate the code successfully.

Combined with the fact that more syntax can make code much easier to read, there is a conflict here.

However, I don't think that's the argument you are making.

Re: Ask PG: Lisp vs Python (2010)

#72
post #43

This question sounds like it's from 2005 rather than 2010. Lisp seems to have become fashionable again now, thanks to Clojure. I'm sure Python has very good libraries, but I would find it constraining to program in a language without proper macros.

The problem with the Blub paradox is that there's no total ordering. I do Common Lisp and C++ at my day job (ITA), and I do much of my personal hacking in Python. In Python and C++ I miss macros; in Lisp and Python I miss RAII and strong typing; in Lisp and C++ I miss dictionary literals. And, in all of them, I miss algebraic datatypes.

I did mention in the original essay that it was only a partial order, in footnote [4].

Re: Ask PG: Lisp vs Python (2010)

#73
post #33

Earlier quoted context omitted.

Oh, it's so ugly, and it hasn't been checked for mistakes, etc. I'd be embarrassed to have my name associated with it.

I read you comment quickly and only now realized it's from you (Dan Weinreb, über lisp guru of ITA fame). I understand your felling (to put an early draft out). But, there is any chance you could send a copy to interested people who know the quality of your work (the man worked on the Common Lisp specification for god's sake!) and will read it as an early draft (no citations allowed ;-) and will promise not to send t…

You would probably entangle him in a two-hundred thousand dollar bet with Scott Aaronson.

Re: Ask PG: Lisp vs Python (2010)

#74
post #72

Earlier quoted context omitted.

The problem with the Blub paradox is that there's no total ordering. I do Common Lisp and C++ at my day job (ITA), and I do much of my personal hacking in Python. In Python and C++ I miss macros; in Lisp and Python I miss RAII and strong typing; in Lisp and C++ I miss dictionary literals. And, in all of them, I miss algebraic datatypes.

I did mention in the original essay that it was only a partial order, in footnote [4].

Sorry, I haven't read it in a while.

Re: Ask PG: Lisp vs Python (2010)

#75
post #43

This question sounds like it's from 2005 rather than 2010. Lisp seems to have become fashionable again now, thanks to Clojure. I'm sure Python has very good libraries, but I would find it constraining to program in a language without proper macros.

The problem with the Blub paradox is that there's no total ordering. I do Common Lisp and C++ at my day job (ITA), and I do much of my personal hacking in Python. In Python and C++ I miss macros; in Lisp and Python I miss RAII and strong typing; in Lisp and C++ I miss dictionary literals. And, in all of them, I miss algebraic datatypes.

I can't help you with strong typing, but I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp.

Re: Ask PG: Lisp vs Python (2010)

#76
post #23

Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself eno…

(This is why I love HN)

Re: Ask PG: Lisp vs Python (2010)

#77
post #58
post #41

Earlier quoted context omitted.

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.

Re: Ask PG: Lisp vs Python (2010)

#78

Earlier quoted context omitted.

The problem with the Blub paradox is that there's no total ordering. I do Common Lisp and C++ at my day job (ITA), and I do much of my personal hacking in Python. In Python and C++ I miss macros; in Lisp and Python I miss RAII and strong typing; in Lisp and C++ I miss dictionary literals. And, in all of them, I miss algebraic datatypes.

I can't help you with strong typing, but I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp.

That's true; we've already got special cases like WITH-OPEN-FILE.

Re: Ask PG: Lisp vs Python (2010)

#79

I'm a Clojure guy that just wrote my first Pylons app. Here's my impression: 1. Python doesn't suck. I was able to mix FP & OOP approaches to get to my goal fairly quickly. 2. iPython was fun to use, helped out a lot, but it's not SLIME. 3. Guido has an excellent goal with making code readable, and significant white space is not a bad choice. However, I find being able to analyze active data structures in a Clojure n…

2. iPython was fun to use, helped out a lot, but it's not SLIME.

what exactly were you thinking about?

Re: Ask PG: Lisp vs Python (2010)

#80
post #63
post #55

There is a language and there is an ecosystem surrounding it (libraries, community, etc). Ignoring the ecosystem, the question "to lisp or not to lisp" pretty much boils down to "syntax or macros" - if you want macros, you go with a lisp, if you want syntax, you go with Python or another modern language. I used to think macros matter more than syntax, because you can freely define your own micro-languages. I didn't r…

Lisp has a lot syntax. It is just a bit different and it looks different externally. Lisp has a 2-stage syntax. The first stage is the syntax of s-expressions , which is surprisingly complex. S-Expressions provide a textual syntax for data: symbols, lists, pairs, strings, various number formats, arrays, characters, pathnames, ... The first stage is implemented by the 'reader' and can be reprogrammed by an ancient API…

"The first stage is implemented by the 'reader' and can be reprogrammed by an ancient API to the reader via read tables."

Readtables aren't any more ancient than the rest of ANSI INCITS 226-1994 (R2004) (the language standard formerly known as X3.226-1994 (R1999)), but the interface to them is very low-level and non-modular.

The current readtable is specified by a dynamic variable, so the readtable facility can be made modular with a nicer interface, in a portable manner. This is exactly what the library Named-Readtables does: http://common-lisp.net/project/named-readtables/

Now realize the significance of this: Common Lisp is the only language allowing total unrestricted syntactic extension and modification in a modular and (somewhat) composable way.

I've been using named-readtables for the past month, and between it and Quicklisp, I haven't been this excited about programming in CL since I started (which is 8 years ago, not that long, but I'm not a total noob either).

Post reply on HN