Live data from Hacker News

Ask PG: Lisp vs Python (2010)

news.ycombinator.com

31–40 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#31
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…

Just wanted to chime in briefly here and say thank-you for your example Lisp interpreter in Python. Made some things much clearer for me and because of it I now have the knowledge to be implementing R5RS over the top of Ruby! Thanks again!

Re: Ask PG: Lisp vs Python (2010)

#32
post #29

Earlier quoted context omitted.

> Obviously not having macros is a given in anything but Lisp At least these languages (that I know of) have macros: http://boo.codehaus.org http://nemerle.org http://www.perl6.org

True, but the syntax for all three of these is pretty hairy. Lisps might not be the only languages with macros, but they're the only ones with elegant and easy to use macro systems. You could argue of course this is a moot point, since even Lispers only write macros infrequently. So who cares if it's hard to write one on the rare occasion you need to?

You could argue of course this is a moot point, since even Lispers only write macros infrequently.

This simply isn't true. In fact it's so far from the truth it hurts my brain. Well written Lisp applications are in large part (and sometimes mostly) macros. PG once mentioned that the ITA guys said over half of their codebase is (was?) macros.

Re: Ask PG: Lisp vs Python (2010)

#33
post #8

Earlier quoted context omitted.

Any chance we might see the draft? :-)

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 the draft to anyone? ;-)

Re: Ask PG: Lisp vs Python (2010)

#34

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…

Re: 8, you don't need decorators to compose functions:

    def comp(f, g):
        def h(*args, **kwargs):
            return g(f(*args, **kwargs))
        # fix up h.__doc__ and friends
        return h
or simply

    (lambda the, args: g(f(the, args))(x, y)
(don't remember comp's semantics, is (comp f g) = f o g or g o f?)

too long; don't read:

Decorators are certainly cool, but semantically they represent something more like a pattern than a FP construct. A decorator represents something you might want to do to lots of functions, a property you want all instances of a function to have without writing it explicitly into each function. Function composition is more along the lines of having two functions which are interesting on their own, but which sometimes you want to compose.

With decorators, it would also be awkward to compose multiple functions. Observe:

    def compose_with(g):
        def decorator(f):
            def decorated_function(*args, **kwargs):
                return g(f(*args, **kwargs))
            return decorated_function
        return decorator

    def h(x): math.sqrt(x)

    @compose_with(h)
    def g(x): 2 * x

    @compose_with(g)
    def f(x): x + 1
versus (for some reasonable definition of apply...)

    def compose(*fns):
        def composition(*args, **kwargs):
            return reduce((lambda computed, next_fn: next_fn.apply(computed)),
                          fns,
                          (args, kwargs))
        return composition

    # define fns as above without decorator
    hogof = compose(f, g, h)

Re: Ask PG: Lisp vs Python (2010)

#35
post #13

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…

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

Re: Ask PG: Lisp vs Python (2010)

#36

I find it hard to maintain large-ish python codebase - it tends to wire up itself into a mess (in my case). It's probably due to my inability to do so, but I don't have same problems with C code.

Is it possible you're comparing lines of code directly? The "size" of a code base is tricky to define, but many people accept a rough rule of thumb that a project of complexity X that might require, say, 10K LOC in competent/straightforward C would require say 2K LOC in competent/straightforward Python/Ruby/etc. The implication is that an average 10K LOC Python program would in fact be a more complicated program than an average 10K LOC C program, and therefore "messier", all things being equal.

Re: Ask PG: Lisp vs Python (2010)

#37
post #35
post #13

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…

> 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 ea…

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.

Re: Ask PG: Lisp vs Python (2010)

#38
post #29

Earlier quoted context omitted.

> Obviously not having macros is a given in anything but Lisp At least these languages (that I know of) have macros: http://boo.codehaus.org http://nemerle.org http://www.perl6.org

True, but the syntax for all three of these is pretty hairy. Lisps might not be the only languages with macros, but they're the only ones with elegant and easy to use macro systems. You could argue of course this is a moot point, since even Lispers only write macros infrequently. So who cares if it's hard to write one on the rare occasion you need to?

Factor supposedly has macros; from my cursory knowledge of the language I could see them being as convenient as Lisp.

Re: Ask PG: Lisp vs Python (2010)

#39

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…

9. INSERT MACRO RANT HERE

Macros are the main reason I decided to create Adder, a Lisp-on-Python with minimal impedance mismatch. Unfortunately, the first macro-heavy program I wrote turned out to be really slow, because macros engage the compiler, which, of course, is in Python.

When I first tried it, it took something like 50s at 2.4GHz, virtually all of which was the compiler. (The compiler runs at load time; obviously, saving the compiled code for the next run would help.) I got it down to...let me try it now...7s at 3GHz, but that's still too slow for a 200-line program.

If anybody's interested, the code's on Github [1]. To see the macro-heavy example, look at samples/html.+, which is an HTML generator. The framework takes 169 lines; the sample page starts at line 171. To see the output, run:

./adder.py samples/html.+

[1] http://github.com/metageek/adder

(Edit: it requires Python 3.x.)

Re: Ask PG: Lisp vs Python (2010)

#40
post #35
post #13

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…

> 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 ea…

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 :)

Post reply on HN