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

51–60 of 98 posts

Re: Lisp vs Python

#51

Post by kenjackson »

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.

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 abstracting syntax too much.

For example, the far more mundane operator overloading debates were about just the topic and the side arguing that not all syntax should be abstracted largely won. This is one reason that despite the fact that Lisp is one of the oldest programming languages and easiest to learn, it has never caught on in a big way. It tends to optimize for that which a lot of people don't want optimization.

Re: Lisp vs Python

#52

Post by gnosis »

lwat wrote: post #47
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…

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.

Have you ever actually programmed in Lisp? Macros can and often do hide all sorts of ugliness that would otherwise make the code a hundred times more unreadable. Much of Lisp's syntax sugar is built with macros.

Re: Lisp vs Python

#53

Post by pavelludiq »

lwat wrote: post #47
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…

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) is obvious. On the internet Lisp is the most unmaintainable language, in practice its pretty maintainable.

Re: Lisp vs Python

#54

Post by jhuni »

Lisp seems to be optimized for writing code; Python seems to be optimized for reading it.

You know what is truly optimized for writing code and not reading it? Mathematical notation - and for good reason, most mathematical equations are written on paper. Mathematicians use one letter variable names like (i, j, n, m, x, y, z), various Greek letters, infix notation, and other things that often makes mathematical equations incredibly hard to read, but easier to jot down on paper.

Almost all programming languages, such as C, Java, Python, and Perl are influenced by this notation that although it was easy to write on paper, is not as easy to read and not nearly as easy to parse.

Lisp is not nearly as easy to write on paper - and it often is harder to type - however - for any experienced Lisper it is the most readable programming language there is, hands down, because once you use it for long enough the parenthesis fade away and you can write/read code without the mental overhead that is entailed by parsing.

Re: Lisp vs Python

#55

Post by silentbicycle »

Locke1689 wrote: post #48
silentbicycle wrote: post #29

Earlier quoted context omitted.

> Languages whose blocks are easier to identify at a glance really are easier to read. Which is why conventions for indenting Lisp code to show block structure have been established for decades. This problem has been solved for longer than Python has even existed . I don't know why people keep bringing it up. Lisp isn't perfect, sure, but this is a very weak criticism. Besides, what about mismatched delimiter problem…

Python would argue that if the primary operating factor in readability is block structure and indentation one should simply add block structure and indentation as a mandatory part of the language and then remove cruft which is no longer necessary.

I'm not convinced that block structure and indentation are primary readability factors, just noting that Lisp programmers established conventions to address that problem long ago.

Re: Lisp vs Python

#56

Post by euccastro »

softbuilder wrote: post #36
jfm3 wrote: post #15

Earlier quoted context omitted.

Decorators are ways to wrap function definitions with code that gets executed at the time the function is defined. Commonly they add stuff that happens every time the function is called. This is certainly something you can do with macros, but it's not even really close to the full semantics. Macros allow you to add new special forms to the language. If Python had macros, for example, the new `with` statements would h…

"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 as

  def f(a, b):
      return a+b
  f = some_deco(f)
Let me repeat: decorators only save you writing the name of the function two additional times. Which is nice and worth it, but not groundbreaking, and, more to the point, has nothing whatsoever to do with macros (except perhaps that in Python you couldn't do it without macros, but that's besides the point).

The equivalent to decorators in Lisp is just normal higher order programming (functions taking functions as arguments, and/or returning functions), with no particular syntax.

  (define f 
    (some-deco 
      (lambda (a b) (+ a b))))
It would be bad form to use a macro for something like this, which is firmly within the domain of normal function definitions and calls.

(P.S.: For short functions like this, you could have said, in Python:

f = some_deco(lambda x, y: x + y)

But this breaks for multiline functions and class definitions.)

Re: Lisp vs Python

#57

Post by Locke1689 »

neutronicus wrote: post #50
Locke1689 wrote: post #46

Earlier quoted context omitted.

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

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"?

Of course it's possible to increase indentation arbitrarily: simply create a new function. Any programmer should know that too many immediate levels of lexical context is bound to confuse the reader anyway.

I'm not really sure what you're trying to show with that code, though. Is your objection that every do_ function is requiring a context?

Edit: I see what the parent was saying now, see bottom comment. Also, see StavrosK's comment if you're fine using Python 2.5 (released 2006).

Re: Lisp vs Python

#58

Post by flatline »

lwat wrote: post #47
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…

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.

Isn't this true of all forms of encapsulation? Deeply nested type hierarchies, event chains, and even method calls can be nearly impossible to decipher, even with a graphical debugger, syntax highlighting and static typing. Writing maintainable code is a skill in any language. Lisp offers a lot of advantages to this end.

Re: Lisp vs Python

#59

Post by lwat »

flatline wrote: post #58
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.

Isn't this true of all forms of encapsulation? Deeply nested type hierarchies, event chains, and even method calls can be nearly impossible to decipher, even with a graphical debugger, syntax highlighting and static typing. Writing maintainable code is a skill in any language. Lisp offers a lot of advantages to this end.

Isn't this true of all forms of encapsulation?

Yes it is.

Re: Lisp vs Python

#60

Post by euccastro »

Locke1689 wrote: post #48
silentbicycle wrote: post #29

Earlier quoted context omitted.

> Languages whose blocks are easier to identify at a glance really are easier to read. Which is why conventions for indenting Lisp code to show block structure have been established for decades. This problem has been solved for longer than Python has even existed . I don't know why people keep bringing it up. Lisp isn't perfect, sure, but this is a very weak criticism. Besides, what about mismatched delimiter problem…

Python would argue that if the primary operating factor in readability is block structure and indentation one should simply add block structure and indentation as a mandatory part of the language and then remove cruft which is no longer necessary.

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.

I'm very familiar with Python and hack occasionally in Scheme. After a really short time, parens really are no problem. They are an asset. In big functions where indentation stops being obvious at a glance (and in smaller ones, what's the problem?), I can more easily see/check the extent of a block in Scheme (with editor paren matching) than in Python. The editor is better able to help me select and operate on such blocks. Moving blocks around (e.g. for refactoring) is easier, faster and feels safer.

If I still use Python more often than Scheme it has nothing to do with parens. Much on the contrary, that's one of the reasons I wish I could spend more time in Scheme.

Post reply on HN