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

71–80 of 98 posts

Re: Lisp vs Python

#71

Post by softbuilder »

euccastro wrote: post #56
softbuilder wrote: post #36

Earlier quoted context omitted.

"Damned close" perhaps should be qualified as from the point of view of a Pythonista, given the ideals of that approach to programming. I took issue with the specific point that Python "has no macros", and then I qualified it, knowing full well that Lisp macros do more. Decorators ultimately result in a function that is a substitute for another function. That function can have all sorts of wonderful runtime behavior,…

Sorry to be blunt, but it's only "damned close" from the point of view of someone that doesn't understand either decorators or macros. Decorators are syntactic sugar for a particular mix of assignment and function call. They're just there so you only need to write the name of the decorated object (say, function or class) once rather than three times. For example @some_deco def f(a, b): return a+b Is exactly the same…

You're conflating decorator syntax, which I'm not discussing, and decorator functionality, which I am discussing. If there was no syntax for decorators and the only way to decorate a function was to use assignment/composition like in your example, I would still consider that to be a decorator.

A macro is going to be evaluated at compile time and will result in a matching pattern (often something that is structured like a function call) being expanded into some other construct that will be evaluated at runtime.

A decorator is going to be evaluated at compile time and will result in a decorated function being "expanded" into another function which will be evaluated at runtime.

No, they aren't the same thing. How could they be? The languages are different. But there is an underlying affinity.

Re: Lisp vs Python

#72

Post by kenjackson »

jfm3 wrote: post #65
kenjackson wrote: post #51

Earlier quoted context omitted.

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's a pretty big difference. Both are about DRY. But functions are about abstracting functionality. Macros are about abstracting syntax. Both are useful and can reduce repitition, but in the general dev community, I don't think its clear that everyone is bought into…

> [...] in the general dev community, I don't think its clear that everyone is > bought into abstracting syntax too much. [...] This seems like you're saying "python is better because it does the things people like and doesn't do the things they don't like". But the same argument could be used to claim Microsoft Windows is a great operating system, and that Justin Bieber is a great musician. > Lisp [...] has never ca…

First, I'm not making any claims that Python is better/worse. I'm simply stating that I think many devs (but certainly not all -- and probably even fewer exceptional devs), did not buy into a large degree of syntax abstraction. I personally like some it, but there certainly are limits.

This is factually incorrect. Scaled for the size of the industry,

Sure, if you scale for the size of the industry which found it useful. But that seems nearly tautological.

Re: Lisp vs Python

#73

Post by lwat »

pavelludiq wrote: post #53
lwat wrote: post #47

Earlier quoted context omitted.

Why does Lisp provide macros? Because they make code easier to read. To the person writing the code, yes. To the next coder maintaining the code, not likely.

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?

Re: Lisp vs Python

#74

Post by cesarm »

Teckla wrote: post #22
j_baker wrote: post #18

> Lisp seems to be optimized for writing code; Python seems to be optimized for reading it. Urgh... A hundred times no. I really do appreciate that the author seems to have given Lisp a try. But this is simply wrong. Why does Lisp provide macros? Because they make code easier to read. I say stop focusing on what language abstraction (f x) represents and focus on figuring out what the code is doing . Oh well, at least…

"Oh well, at least he didn't complain about lisp having too many parenthesis." Humans are visual creatures. It really is easy to get lost in Lisp's parentheses. Languages whose blocks are easier to identify at a glance really are easier to read. The attitude of far too many Lisp developers seems to be that Lisp has failed to dominate after all these many decades because people are just too stupid to realize how great…

in lisp one ends up reading code by indentation - much like python. the parenthesis fade into the background after just a couple of days of using lisp. matter of fact i use a light blue background in emacs, and make the parenthesis a light gray. barely see them.

Re: Lisp vs Python

#75

Post by cesarm »

pavelludiq wrote: post #53
lwat wrote: post #47

Earlier quoted context omitted.

Why does Lisp provide macros? Because they make code easier to read. To the person writing the code, yes. To the next coder maintaining the code, not likely.

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

true, but i still find the loop macro confusing.

Re: Lisp vs Python

#76

Post by cesarm »

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?

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

Re: Lisp vs Python

#77

Post by jfm3 »

kenjackson wrote: post #72
jfm3 wrote: post #65

Earlier quoted context omitted.

> [...] in the general dev community, I don't think its clear that everyone is > bought into abstracting syntax too much. [...] This seems like you're saying "python is better because it does the things people like and doesn't do the things they don't like". But the same argument could be used to claim Microsoft Windows is a great operating system, and that Justin Bieber is a great musician. > Lisp [...] has never ca…

First, I'm not making any claims that Python is better/worse. I'm simply stating that I think many devs (but certainly not all -- and probably even fewer exceptional devs), did not buy into a large degree of syntax abstraction. I personally like some it, but there certainly are limits. This is factually incorrect. Scaled for the size of the industry, Sure, if you scale for the size of the industry which found it usef…

Okay, then I agree. Lispers use macros sparingly. But not having them at all pinches me terribly and I wish I could explain that better. Decorators don't help much with that pinching :)

I mean the size of the industry that programmed computers at all, not the size of the industry that programmed in Lisp.

Re: Lisp vs Python

#78

Post by neutronicus »

StavrosK wrote: post #69
neutronicus wrote: post #50

Earlier quoted context omitted.

Can you increase indentation arbitrarily, though? Like, say I want to initialize some data for a loop, that I wouldn't need later, could I: main_scope_stuff() c = create_context() for foo in foos: do_something(foo, c) do_other_thing(foo, c) accumulate(foos, c) more_main_scope_stuff() to emphasize that c was only important to the loop and the call to "accumulate"?

Yes: main_scope_stuff() with create_context() as c: for foo in foos: do_something(foo, c) do_other_thing(foo, c) accumulate(foos, c) more_main_scope_stuff() That signifies that "c" isn't supposed to be available after scope of the "with" statement. The variable will still be bound, but conceptually it's unavailable, since it's not supposed to be used. Also, the object in create_context() needs to support being called…

That's nice, I didn't know about that, thanks. I'll definitely be using it the next time I have to use Python.

It's a little bit unsatisfying, since all of the context has to be wrapped in a single object, but that does cover a common class of Lisp macro use cases.

Re: Lisp vs Python

#79

Post by sausagefeet »

Locke1689 wrote: post #46
neutronicus wrote: post #40

It's easy to read. You can determine how to interpret something—a string, a list, a function call, a definition—just by looking at the code locally. I actually find that Lisp scores some local-readability points over Python in a few cases, mainly because Lisp is more explicit about scope, e.g. (let ((a (something)) (b (other-thing)) (frobnicate a b)) ...other code versus a = something() b = other_thing() frobnicate(a…

Python is explicit about scope by using the same indentation block. I can glance at python code and immediately tell what the scope is because it's in the same indentation block (removing for the moment things like the global keyword, which tend not to be a problem in practice).

This isn't true, consider:

  if 1
(I'm retarded and don't know how to do comments that have new lines in the, but hopefully you catch the drift. The 'print c' is at 0 indentation)

Re: Lisp vs Python

#80

Post by euccastro »

softbuilder wrote: post #71
euccastro wrote: post #56

Earlier quoted context omitted.

Sorry to be blunt, but it's only "damned close" from the point of view of someone that doesn't understand either decorators or macros. Decorators are syntactic sugar for a particular mix of assignment and function call. They're just there so you only need to write the name of the decorated object (say, function or class) once rather than three times. For example @some_deco def f(a, b): return a+b Is exactly the same…

You're conflating decorator syntax, which I'm not discussing, and decorator functionality, which I am discussing. If there was no syntax for decorators and the only way to decorate a function was to use assignment/composition like in your example, I would still consider that to be a decorator. A macro is going to be evaluated at compile time and will result in a matching pattern (often something that is structured li…

> You're conflating decorator syntax, which I'm not discussing, and decorator functionality, which I am discussing.

Guilty as charged. I admit I thought you were talking about decorator syntax. Because decorator-the-technique makes even less sense as an alternative to macros.

Decoration is a technique of higher order programming (taking functions as arguments and/or returning them). The fact that you can use it at "compile time" (whatever that means in Python) is a property of the dynamic nature of the language.

Yes, that stuff is powerful. But Scheme has all that, and its designers still saw the need to add macros, mostly to do the things that you can't do by executing higher order functions at "compile time".

Macros are not essentially about doing stuff at compile time; they're about messing with the very syntax of the language.

My point is not just that decorators and macros aren't the same thing; it's that macros are meant explicitly to do what decorators can't.

I guess most Python programmers don't miss macros simply because they've never seen the need for them in first place, not because Python has any replacement. The closest alternative that Python has to macros would be eval.

In my opinion, what ultimately allows most Python programmers who have been exposed to macros to almost never miss them is the syntactic sugar that the Python authors keep (judiciously) adding every release.

Post reply on HN