Lisp vs Python • Hacker News Board

Re: Lisp vs Python

#41

Post by jfm3 » Sun, Feb 20, 2011, 10:52 PM UTC

Jach wrote: post #39

jfm3 wrote: post #14

"Sometimes (f x) is [one of 6 things]" I don't mean to be the next snarky Lisp guy in the room, but I don't see the difference between reading (if (= a 3) ...) and thinking "that's a special form and a predicate", and reading if a == 3: ... and thinking "that's a special form and a predicate". In either case there's "if". Writing "(f x) could be anything" is a straw man. As soon as you replace "f" with "if" the argum…

Ah, but you can in Scheme. :) guile> (define if (lambda (. args) (display "Haha!") (newline))) guile> (if (= 3 4) 't 'f) Haha!

Cute! And you're right! Scheme should be kept away from people who are prone to hurt themselves, as well as nail clippers and letter openers. Too dangerous!

:)

Re: Lisp vs Python

#42

Post by lispm » Sun, Feb 20, 2011, 10:52 PM UTC

(f x) is not different things. It is just that the meaning of (f x) depends on a context and is only meaningful in a context.

    (f x) alone is a call, a macro or function.

    (let ((f x)) ...) , here (f x) is an item in a binding list.

What a Lisp programmer sees is a pattern introduced by LET:

    LET ((var value)*) body

There are a handful of basic macro code structure patterns. Once they are learned and attached to the symbol of the corresponding macro, the understanding of code is much improved.

Reading Lisp code requires to identify the visual marker - the symbol in front. Depending on that there are code patterns that can be visually destructured: lists, property lists, assoc lists, lambda lists, binding lists, ...

In other languages the visual markers are supported by different characters. In Lisp it is a symbol.

    {
       a := b + x;
    }

vs.

    (progn
      (setq a (+ b x)))

As a Lisp programmer I'm trained to see the PROGN, not the parentheses.

It is a bit like being afraid of riding a bicycle for the first time. How can one move forward and balance at the same time? Difficult. Once learned it is simple and hard to unlearn.

How can one read the various Lisp code patterns? Once you have learned them it is easy and hard to unlearn.

Re: Lisp vs Python

#43

Post by jfm3 » Sun, Feb 20, 2011, 11:01 PM UTC

jerf wrote: post #16

kenjackson wrote: post #9

Earlier quoted context omitted.

Can you expand on this. What is something that macros can do that decorators can't? And likewise, what are some common uses of macros that decorators can do?

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 missing the point, to me.

Imagine it was functions instead. "Well your language already has a sort() function, but say you want to use an in-place sort instead of what you get with the standard library? You need the ability to define your own functions." "No we don't, our BDFL added an in_place_sort() routine to the standard library for the next version of the language." That doesn't make sense to me at all.

Re: Lisp vs Python

#44

Post by kenjackson » Sun, Feb 20, 2011, 11:01 PM UTC

intellectronica wrote: post #10

Saying that LISP is for writing code and Python is for reading code is like saying that cars are for travelling uphill and bicycles are for travelling downhill.

While you were being facetious, I do think that I'd love a device that turned into a bike when I was going downhill and then a car when going uphill. At the very least... a motorized bike for going uphill (which obviously do exist).

Re: Lisp vs Python

#45

Post by Someone » Sun, Feb 20, 2011, 11:11 PM UTC

If that argument is valid, why not go a step further to, say, early basic implementations? Back in the day, there was no discussion possible whether 'x' was an integer, float, or string. If it were a string, it would be x$, if it were an integer, i%.

I do not think his argument is valid. In both languages, once a program is large enough for any syntactic ambiguity to make a difference, there will be more than enough semantic clues to help solve the syntactic disambiguaties.

In other words: yes, one can write really hard to understand Lisp, where (f x) has six meanings in one line, but outside of obfuscated code contests, programmers just do not write such code.

Edit: the semantic clues I refer to are those implied by function names, names of data types, etc.

Re: Lisp vs Python

#46

Post by Locke1689 » Sun, Feb 20, 2011, 11:17 PM UTC

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

Re: Lisp vs Python

#47

Post by lwat » Sun, Feb 20, 2011, 11:19 PM UTC

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.

Re: Lisp vs Python

#48

Post by Locke1689 » Sun, Feb 20, 2011, 11:19 PM UTC

silentbicycle wrote: post #29

Teckla wrote: post #22

Earlier quoted context omitted.

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

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

Re: Lisp vs Python

#49

Post by [deleted] » Sun, Feb 20, 2011, 11:23 PM UTC

Someone wrote: post #45

If that argument is valid, why not go a step further to, say, early basic implementations? Back in the day, there was no discussion possible whether 'x' was an integer, float, or string. If it were a string, it would be x$, if it were an integer, i%. I do not think his argument is valid. In both languages, once a program is large enough for any syntactic ambiguity to make a difference, there will be more than enough…

[deleted]

Re: Lisp vs Python

#50

Post by neutronicus » Sun, Feb 20, 2011, 11:25 PM UTC

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

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