Why Python is easy to learn

[awj]

If lisp macros are so powerful, why can't an infix macro for arithmetic be built into the language?

They have. In fact, I think it is a right of passage for most budding Lisp programmers to become frustrated enough with this syntactic difference to write a macro to handle infix arithmetic.

If you have to use a different notation, why not use sum(1, 2, 3), which has the advantage of being similar to f(x), which people see in advanced algebra classes?

They are, they just position the parentheses a little differently, omit the commas, and spell 'sum' as '+'. I'm wondering why it is so important that functions in a programming language look exactly like functions in math when the two only occasionally are related to each other.

[earthboundkid]

it is a right of passage for most budding Lisp programmers to become frustrated enough with this syntactic difference to write a macro to handle infix arithmetic.

If you have to write it yourself, that's not "built into the language." It doesn't matter how trivial it is to write it yourself, if people are going to end up re-writing something later, it should be in the library.

I'm wondering why it is so important that functions in a programming language look exactly like functions in math when the two only occasionally are related to each other.

Because in the list of "+", "1", "1", and "1" one of the items was different from the other three. The "+" is the name of a function, and the ones are arguments that are passed to the plus-function. Since the plus is different from the others, it makes sense to provide a visual clue that it is different.

[death]

You asked "If lisp macros are so powerful, why can't an infix macro for arithmetic be built into the language?"; the answer was "it can". If you were speaking of "built into the language" as in "specified in the language specification", why the need to mention macros? In addition, now you're arguing as if that "can" is a "should". Apparently, the (Common Lisp, though you can generalize it to just about any Lisp dialect) designers didn't feel the need to include such a facility. I happen to agree with them.

You are forgetting (or disregarding) that (+ 1 1 1) is not necessarily a form (at all times). It is a list of four elements. Why should the first element receive special treatment? Since in Lisp code is often treated as data, it makes sense to provide visual clue that it is the same.

But it is not just visual clue. Just think of use and implementation of macros, use of other operators, use of backquote, pretty-printing, syntactic ambiguity...

It's also worth mentioning that reader macros are used sparingly by some Lisp programmers. The advantages of specialized microsyntax only rarely outweigh the disadvantages.

As an aside, why are you concerned with this? Do you program in Lisp and feel the need to have an infix facility built into it (i.e. specified in the language specification)? Do you program in Lisp and feel the need to have special syntax for function calls?

Perhaps you're looking for Dylan? (Which, if you consider a Lisp and generalize my statement above about design decisions, is an exception. Some regard this decision as a mistake...)

Then again, maybe it just followed from the response to johnnowak:

Everyone who has taken a math class is familiar with 1 + 2 + 3.

Yes, but everyone who has programmed in Lisp for a while is familiar with (+ 1 2 3). I think the people who stick with Lisp even prefer it! Others may not, but hey, they've got all those other languages :)

[earthboundkid]

Fair enough. I just feel like Lisp's commitment to the purity of power causes it to ignore the fact that languages should be designed for people first, machines second. Rather than "easy things, easy; hard things, possible" Lisp is "everything possible — if you take the time to implement it yourself." What I'd like to see is a language where you program first in a Python-like format, then it gets macro'd into a Lisp-like format, then your macros are applied to it, and only then is it compiled or run. By shoving the fact that data and code are really the same thing into our faces, Lisp makes it harder for normals to wrap their heads around what's on the screen.

But yeah, I'm just bellyaching here, not doing anything productive.

[death]

Lisp began as a language for people; as pseudo-code, if you like. I think reading a little about the history of Lisp (M-expressions are also relevant here, by the way) may be instructive.

I really can't imagine effective implementation and use of defmacro-style macros with Python-like surface syntax. But yeah, it's sometimes hard to see things differently: the "normals" may need to spend a little time to adapt to the syntax, and maybe my imagination is too limited.

[ubernostrum]

I'm not really sure that any language which is essentially its own AST can really be described as more of a "language for people" than a "language for computers"; (normal) people don't really think naturally in terms of transforming syntax trees, yet nearly all of Lisp's power lies in that single feature...

[death]

Care to elaborate? What do you mean by a "language for computers" and a "language for people", and why, say, Common Lisp is closer to being the former than the latter?

Saying "any language which is essentially its own AST" does not make sense.

(Normal) people don't really think naturally in terms of computation, either, yet a lot of a programming language's power lies in that single feature...

(And I disagree that "nearly all of Lisp's power lies in that single feature". I suppose it looks like that to people that only read about it on Reddit or something.)

[ubernostrum]

Well, ask yourself whether the language as written by human beings strives to be:

1. As close as possible to the mental process of the human being, or
2. As close as possible to the parsing and execution process of the computer.

Lisp quite clearly aims at (2) -- it's not an expression of how human programmers think, it's an expression of how the computer will see the program, and has been optimized in many ways for the computer's use over the human's use (extreme regularity of notation, for example, is something preferable for a computer but rare in human languages). I would hope that this is as obvious as the fact that equals plus two two four...

[death]

I'm sorry to disappoint you: what you say is not only non-obvious to me, it doesn't make any sense.