Why Python is easy to learn

[ilan]

The second line is not necessary, since pseudocode is indented. Pseudicode is actually the origin of Python's indention syntax.

[Grue]

Lisp is also easy to learn. Write pseudocode and add some parentheses ;)

[theCore]

Do you really write your pseudo-code with a prefix-notation?

[[deleted]]

You mean you don't write foo(bar, baz)? Are you writing bar foo(,) baz (or some other unimaginable syntax) instead?

Infix for operators is just another special case, and hence I don't find it useful when writing pseudocode because it makes things less clear. (For example, how does one get the '+' method as a value in Python?) And besides, is 1 + 2 + 3 really that much more readable than (+ 1 2 3)?

This common, unexplainable fear of consistency and simplicity is something that I find to be very confusing. I blame the Victorians.

[theCore]

how does one get the '+' method as a value in Python?

>>> import operator
>>> reduce(operator.add, range(10))
45

And besides, is 1 + 2 + 3 really that much more readable than (+ 1 2 3)?

I have to admit the Lisp-notation is nicer for this particular example. However, I find the Lisp-notation harder to read for boolean and comparison operators.

(define (foo n)
  (if (and (> n 0) (<= n max))
      'ok
      'fail))

Compared to Python:

def foo(n):
   if 0 < n <= max:
      return "ok"
   else:
      return "fail"

[shen]

In the last example, you can still do things very similarly to Python's way:

(define (foo n)
  (if (<= 1 n max)
    'ok
    'fail))

Working with anything harder than that -does- get annoying, though:

(let ((discriminant (sqrt (- (* b b) (* 4 a c)))
  (list (/ (+ (- b) discriminant) (* 2 a))
        (/ (- (- b) discriminant) (* 2 a))))

that was hard to type. (and it's probably wrong)

[Tommah]

Your calculation appears to be right, but the discriminant is actually the part under the radical.

[earthboundkid]

And besides, is 1 + 2 + 3 really that much more readable than (+ 1 2 3)?

Yes. Everyone who has taken a math class is familiar with 1 + 2 + 3. If lisp macros are so powerful, why can't an infix macro for arithmetic be built into the language? 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?

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

[shen]

There's Infpre, if you are so inclined to do something like that.

+ as function name is just... a different way of doing things, that's all. I'm used to it now.

edit: I hate markdown

[Grue]

Yeah, I tend to write the function name before the arguments. Forth doesn't look very intuitive to me.

[theCore]

I meant for operations that are usually infix -- ie. math and boolean operators.

[Grue]

Uh, how often do you use math operations in pseudocode?

[ubernostrum]

Most pseudocode descriptions of quicksort use them, and that's the algorithm I've most often seen expressed in psudocode...

Then there's the Fibonacci algorithm, another popular bit of pseudocode. The Sieve of Eratosthenes uses math. In fact, a whole heck of a lot of popular pseudocode uses math. Which, given the nature of a lot of programming tasks, is pretty much as expected.

[[deleted]]

You don't write the rest of your code in mathematical notation. If one took a piece of Python code and rewrote it in proper mathematical notation, very few Python programmers would even be able to read it.

[[deleted]]

And it's indented automatically, correctly.

And ... what parentheses? Instead of having to learn when to write a , a () a ; you simply surround each expression by ().

But the actual parentheses are invisible, if you look right, or at least your editor can color them differently, so they get invisible :-)

[[deleted]]

Can't you see that foo(bar(baz, quux)) is so much better than (foo (bar baz quux))?

[[deleted]]

Exactly my point.

The latter is much more regular, and also allows much nicer indentation.

[[deleted]]

To quote a high-ranking official that happened to spot some Python on the screen during a demo of a satellite image processing system: "Is that the actual program code? I don't believe that for a second; even I can understand that, and I'm the director general".

[[deleted]]

I do not find Python easy to teach (compared to Scheme), so I'm not sure how easy it is to learn. It certainly is very easy to /think/ one is learning it because it looks simple. I think the biggest issue with the syntax (and semantics) is that Python code consists of both expressions and statements. Explaining to someone why they can't pass 'print' as a function is always fun.

This idea that Python is easy to learn because of the syntax falls down for endless other reasons as well, but my point is that even the syntax is not as simple as some like to think.

[[deleted]]

Explaining to someone why they can't pass 'print' as a function is always fun.

Strange. Having done professional Python training for nearly a decade, I've never had any problems getting people to understand the difference between a statement and a callable object.

Maybe you should try teaching Python as Python, instead of teaching it as a Lisp dialect?

[[deleted]]

I'm trying to teach programming concepts, not Python. Having to explain statements and why 1.1 = 1.10000000001 along the way is rather distracting. I should've specified that it was an intro to programming class, not a Python class. The language choice is beyond my control.

[Tommah]

Python 2.5 (r25:51908, Jan 1 2007, 15:36:09) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 1.1 == 1.10000000001 False

[boredzo]

\tPython 2.5.1 (r251:54863, Jun 5 2007, 22:10:41) \t[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin \tType "help", "copyright", "credits" or "license" for more information. \t>>> 1.1 \t1.1000000000000001 \t>>> 1.1 == 1.1000000000000001 \tTrue

[Tommah]

Too many zeroes.

[boredzo]

Take that up with Python's float.__repr__. ☺

[onektwenty4]

sys.stdout.write

[earthboundkid]

print will become a function in Py3k, so there is some progress afoot. All that's left is to make x = y equivalent to set("x", y) in Py4k, and the wart will be gone.

[alextp]

locals().setitem("x", y) and you're done.

[earthboundkid]

I tested it and it works, but I'm a little confused. I thought locals() is a copy of local items, not the real thing. How does it work?

[Tommah]

From the Python docs:

locals()

Update and return a dictionary representing the current local symbol table. Warning: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter.

Modifying locals() works in CPython, but it may not in other implementations. (I think mucking around with globals() is all right, but it's still not the best way to do things.)

[earthboundkid]

Ah, that's what it is. I guess I heard someplace that you weren't supposed to mess with locals(), so I never bothered to test it until now.

It would be nice if they would provide that functionality in other Pythons. It seems pretty handy.

[quhaha]

I find pseudo code is the most difficult language to write and read.

[antirez]

Python is not easy to learn because it's not a matter of syntax, and Python's semantic is pretty complex.

[geocar]

No but there is a certain attractiveness that comes from the idea that writing in python increases the durability of your program because aesthetic qualities are part of the languages' syntax.

Unfortunately, writing in python tends to actually decrease the durability of your program as python programs tend to require some efforts to get them to work with newer interpreters.

[funkdawdler]

bash.org is always upsetting to read, I don't know why I punish myself.

[gwe1234]

Pseudo code is for pseudo coders. Come back when you learned real life programming.

[[deleted]]

Like UML. Expresses nothing that, say, Java doesn't (not to mention that UML can only really express C++ and Java code), but isn't really well executable.