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

Lisp vs Python

amitp.blogspot.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Lisp vs Python

#91

Post by Locke1689 »

euccastro wrote: post #81
Locke1689 wrote: post #67

Earlier quoted context omitted.

Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. Because they screwed up? I think indentation like the following should be mandatory across multiple lines: fun_a(long_arg_a, long_arg_b, long_arg_c)

And does that remove the need for parentheses? ;) Because actually, it gets more complicated than that. Sometimes it makes more sense to say: def open_window(x, y width, height, resizable=True, caption="") Without parens, is x, y a tuple or two separate arguments? And do I want to remember that? Also, what's inside the parens could have been a generator expression, which could have been conceivably partitioned in mor…

True, although Haskell does show we can do function application without excessive parentheses.

I think you're definitely right about Python, though. Fundamentally, Python is still a procedural, block style language. If it were written in the same functional style as Lisp it would probably be just as complex.

Re: Lisp vs Python

#92

Post by rayiner »

lwat wrote: post #73
pavelludiq wrote: post #53

Earlier quoted context omitted.

Do you have any data(even if anecdotal) to back up your claim? My experience is that macros don't obfuscate code at all(unless misused, I'm talking about idiomatic use of course). If i have the code loaded i just type (documentation 'macro-or-function-name 'function) to get its docstring. Slime can also show me its documentation and its argument list. Not to mention that a good macro(like any other well written code)…

Here's an anecdote from the other day: http://news.ycombinator.com/item?id=2240461 On another note, why do you think lisp isn't more widely used?

Why isn't Smalltalk, Prolog, Modula, ML, Eifel, FORTRAN, Ada, APL, etc, more widely used? Because there can only be a couple of "mainstream" languages, and C/C++ took up all the mindshare in that period.

In fact, a more useful question is: "why is Lisp even used as much as it is?" The current Common Lisp standard is 20 years old, and yet it supports a pretty active if small user community, which is more than can be said of most of its contemporaries.

Re: Lisp vs Python

#93

Post by [deleted] »

euccastro wrote: post #83
neutronicus wrote: post #70

Earlier quoted context omitted.

One could also throw the separate stuff into a new function. That's the elephant in the room in all of these "my language is more readable" discussions, isn't it?

To be fair, that's what Lisp's let is syntactic sugar for, too.

[deleted]

Re: Lisp vs Python

#94

Post by euccastro »

sausagefeet wrote: post #88
euccastro wrote: post #85

Earlier quoted context omitted.

Add at least two spaces at the beginning of each line and it will be treated as a preformatted block. What you try to do is not legal Python. The else clause can't go in the same line. I get your point, though. Python's scope is not in terms of literally 'indentation' blocks. Scope units are: module toplevel, and (possibly nested) function and class definitions. To create a new scope you create a new function. This i…

Fixed, thank you for the tip. Yeah the point I was showing was that the 'c' exists after the if or else, showing that scope is not bound to indentation level. On the subject of scope, this behavior has gotten me a few times (I find it unintuitive although I understand why it works this way): x = 2 f = lambda : x print f() x = 3 print f()

Yes, the first assignment works as a Scheme 'define', and all subsequent ones as 'set!'s. The whole function/class/module is a monolithic scope, inherited/superseded/extended by functions and classes defined within.

Re: Lisp vs Python

#95

Post by delackner »

sigzero wrote: post #3

Without reading the article, can this be summed up as "People actually use Python"?

In general, any time you find yourself beginning to write a comment that says "I didn't read the article" is probably a good time to just click on the article, or go back to the news feed, or close the tab and move along.

Re: Lisp vs Python

#96

Post by jerf »

jfm3 wrote: post #43
jerf wrote: post #16

Earlier quoted context omitted.

One thing that answers both your questions at once are macros that create new control structures. Macros can take a chunk of syntax tree but not evaluate it, and decorators can only manipulate functions, they can't be used in a function. That said, the usual answers to the question of "Why do I need macros" are slowly but surely being chewed through by Python. The relatively-recent (albeit years old) addition of "wit…

>I'm not sure what massive win for macros is left. From my point of view, not being able to define new syntax is as serious a limitation as not being able to define new functions, or data structures. There are a number of specific examples usually cited to explain why the ability to define new syntax is important. Answering these specific examples by adding more static syntax to the language seems to be severely miss…

"From my point of view, not being able to define new syntax is as serious a limitation as not being able to define new functions, or data structures."

Which is exactly my point. We've gone from "Well, I can use it to define a ternary operator" or "I can use it to define a 'with' block" or "I can create continuations" or a number of other specific examples to "Uh, well, I just like them, here I do this with them" and in my experience there's always an easy "Well, the Pythonic way to do that is this and it's not all that much harder, may even be easier, and is a standard part of a relatively simple language rather than your own hand-rolled thing".

It's a very different argument than it was ten years ago when I first got into Python. It's gone from really strong pro-macro points to personal opinion. I respect and acknowledge that opinion, no sarcasm. But it's not the same.

Your last paragraph isn't relevant to me because the specificity of your example is misleading. It's really hard to come up with an actual macro use case that is not covered by modern Python and is still actually a good idea. (It's trivial to come up with bad uses of macros not covered by Python, but I'm hardly crying about that.)

Re: Lisp vs Python

#97

Post by jfm3 »

jerf wrote: post #96
jfm3 wrote: post #43

Earlier quoted context omitted.

>I'm not sure what massive win for macros is left. From my point of view, not being able to define new syntax is as serious a limitation as not being able to define new functions, or data structures. There are a number of specific examples usually cited to explain why the ability to define new syntax is important. Answering these specific examples by adding more static syntax to the language seems to be severely miss…

"From my point of view, not being able to define new syntax is as serious a limitation as not being able to define new functions, or data structures." Which is exactly my point. We've gone from "Well, I can use it to define a ternary operator" or "I can use it to define a 'with' block" or "I can create continuations" or a number of other specific examples to "Uh, well, I just like them, here I do this with them" and…

> It's really hard to come up with an actual macro use case that is not covered by modern Python and is still actually a good idea.

sqlalchemy (and now mongoalchemy) is begging for macros. See CLSQL for an answer.

Regular expressions are infinitely more readable as expressions in a dynamic syntax. See the rx package in Emacs for starters.

What if you want shell/Ruby style back quotes, which in essence create a closure that runs a batch job? See my SHELLSHOCK library (jfm3.org) for the Common Lisp extension. It's not much code at all.

What if you want large literal strings which respect the indentation of their surrounding code, without uglying things up with What if you want something like Python's r"string", but you want more control over which things are escaped and which are not? See CL-INTERPOL for that.

What if you want anaphora in your control structures?

What if you want Lex/Yacc style parser generator specifications where the type of productions is extensible, and the productions themselves can be generated dynamically at compile time? (This will make no sense to you unless you've ever had no choice but to run m4 on your .l and .y files.)

I could go on. It's not hard for me.

Re: Lisp vs Python

#98

Post by silentbicycle »

Locke1689 wrote: post #91
euccastro wrote: post #81

Earlier quoted context omitted.

And does that remove the need for parentheses? ;) Because actually, it gets more complicated than that. Sometimes it makes more sense to say: def open_window(x, y width, height, resizable=True, caption="") Without parens, is x, y a tuple or two separate arguments? And do I want to remember that? Also, what's inside the parens could have been a generator expression, which could have been conceivably partitioned in mor…

True, although Haskell does show we can do function application without excessive parentheses. I think you're definitely right about Python, though. Fundamentally, Python is still a procedural, block style language. If it were written in the same functional style as Lisp it would probably be just as complex.

The ML and APL families also do function application without excessive parens.

I don't think Lisp's grouping rules are complex. There are a few functions with special grouping, particularly let and cond, but anybody doing real programming in Lisp gets used to them pretty quickly. (Lisp is hardly the only language with special cases in its syntax!) User-added functions seldom have elaborate nesting schemes, or at least have a damned good reason.

Post reply on HN