Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask PG: Lisp vs Python (2010)

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#61

Post by pjscott »

francoisdevlin wrote: post #7

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…

It's funny, but the thing I miss most from Common Lisp when I write in other languages is the LOOP macro. It's ugly, and non-lispy, but most loops I have to write can be expressed clearly and concisely using LOOP, and writing the equivalent code in another language is annoying.

I'm tempted to create a LOOP clone for Clojure, then laugh villainously as I unleash it upon the world.

Re: Ask PG: Lisp vs Python (2010)

#62

Post by leif »

francoisdevlin wrote: post #49
leif wrote: post #34

Earlier quoted context omitted.

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…

To expand on what I was thinking with #8, here's how I'd implement a decorator in Clojure (def my-decor (partial comp decor-bevior)) Done.

Well, what python calls a "decorator" is just a function that accepts a function and returns a function with roughly similar functionality. In python, the old way to decorate functions was

    def my_decorator(f): ...
    def my_function(...): ...
    my_function = my_decorator(my_function)
and the new "@my_decorator" syntax is just sugar for this.

Function composition is only one of many things you can do with decorators. You could implement a K-combinator with them if you wanted to:

    def kestrel(x):
        "decorates a function to evaluate that function, but then return x"
        def decorator(f):
            def g(*args, **kwargs):
                f(*args, **kwargs)
                return x
            return g
        return decorator

    @kestrel(4)
    def foo(x):
        y = x + 1
        print y
        return y

    foo(5) # => 4, but prints 6

Re: Ask PG: Lisp vs Python (2010)

#63

Post by lispm »

ntoshev wrote: 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 to the reader via read tables.

The second stage is the syntax of the Lisp programming language. This is defined on top of s-expressions and is really a syntax over data structures (not text). This Lisp syntax deals with: data items, function calls, special forms (thirty something) and macro forms.

This syntax stage is implemented as part of the interpreter/compiler (EVAL, COMPILE, COMPILE-FILE) and can be extended by writing macros, symbol macros and compiler macros. In earlier dialects it could also be extended by writing so-called FEXPRs, functions which get called with unevaluated source code (-> data in Lisp).

So, we get a lot of complex syntax due to special forms and macros. It just looks a bit different, since the data syntax is always underneath it (unless one uses a different reader).

For example a function definition would be:

   (defun foo (a b) (+ (sin a) (sin b)))
The syntax for that is:

    defun function-name lambda-list [[declaration* | documentation]] form*
With more complex syntax for 'function-name', 'lambda-list' and 'declaration'.

Lambda-list has this syntax:

    lambda-list::= (var* 
                    [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
                    [&rest var] 
                    [&key {var | ({var | (keyword-name var)}
                      [init-form [supplied-p-parameter]])}*
                      [&allow-other-keys]] 
                    [&aux {var | (var [init-form])}*])
Not every valid Lisp program has an external representation as an s-expression - because it can be constructed internally and can contain objects which can't be read back.

Not every s-expression is a valid Lisp program. Actually most s-expressions are not valid Lisp programs.

For example

   (defun foo bar)
is not a valid Lisp program. It violates the syntax above.

Re: Ask PG: Lisp vs Python (2010)

#64

Post by leif »

pjscott wrote: post #61
francoisdevlin wrote: post #7

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…

It's funny, but the thing I miss most from Common Lisp when I write in other languages is the LOOP macro. It's ugly, and non-lispy, but most loops I have to write can be expressed clearly and concisely using LOOP, and writing the equivalent code in another language is annoying. I'm tempted to create a LOOP clone for Clojure, then laugh villainously as I unleash it upon the world.

> I'm tempted to create a LOOP clone for Clojure, then laugh villainously as I unleash it upon the world.

DOOOO IT

Re: Ask PG: Lisp vs Python (2010)

#65

Post by Keyframe »

spenrose wrote: post #36
Keyframe wrote: post #25

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…

I can't really describe it. It's as if literal size grows, it's harder for me to wrap my head around what is where and why - I suspect it is due to the fact I don't write very pythonic code... more like I'm writing C code with Python syntax, if you know what I mean.

I am not particularly familiar with python too, I should educate myself properly, dwell more into it though. I only get by for what I need to do in Maya with it.

Re: Ask PG: Lisp vs Python (2010)

#66

Post by metageek »

pg wrote: 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.

Re: Ask PG: Lisp vs Python (2010)

#67

Post by deadwisdom »

pg wrote: 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.

Re: Ask PG: Lisp vs Python (2010)

#68

Post by Goladus »

justlearning wrote: post #59
Goladus wrote: post #54

Earlier quoted context omitted.

Bananas have much more starch than oranges, but oranges are easier to juice.

@Goldus - you seem like a old timer here. why post comments like these? Are you adding any value to the main conversation - python/lisp.

The point of the comment was to demonstrate that sometimes, it's worthwhile or at least interesting to compare (or actually, contrast) bananas and oranges, like Python and Lisp.

(Also, I had already posted my small contribution to the original topic)

Re: Ask PG: Lisp vs Python (2010)

#69

Post by draegtun »

drcode wrote: post #29
bad_user wrote: post #17

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?

Io (http://www.iolanguage.com) is a bit of an exception then.

Its homoiconic but its not a Lisp. And it doesn't have macros yet its code is fully inspectable/modifiable at runtime in an very easy & elegant way.

For eg. if you wanted to have a line like this:

    list(1, 2, 3) each foo bar
which needs to be transformed into below at runtime:

    list(1, 2, 3) foreach(foo bar)
Then this can be done like so:

    List each := method(
	m := call message
	m setName("foreach") setArguments(list(m attached)) setAttached(nil)
	self doMessage(m)
    )
ref: http://www.iolanguage.com/blog/blog.cgi?do=item&id=86

Re: Ask PG: Lisp vs Python (2010)

#70

Post by deadwisdom »

norvig wrote: 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…

> But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.

Communication is increasingly the more important part of programming. Engineering is only really useful if its well communicated, or in a binary you trust.

Post reply on HN