Comment by ajross | Hacker News Reader

Comment by ajross | Hacker News Reader

Parent Full thread

I call shenanigans. That's true of simple scripts, I'm sure. But you can't seriously claim to me that you can understand decorator idioms, iterables or list comprehensions without a deep understanding of the language. What you say might have been true for Python c. 1998, it certainly isn't true today.

Broadly: reading code is just hard. It's much harder than writing code. There are no non-trivial codebases that can be considered "easy to read" (if you think there are, then you're fooling yourself), and the choice of language makes only mild difference.

(edit: I'm amused at the multiple people who had to jump in to explain "decorators aren't hard!" instead of responding to my core point. First, I know what a decorator is. Second, no one who isn't a reasonably proficient python programmer is going to have any clue what @classmethod does or why all the old code doesn't break without using it. It's non-standard, language-specific syntax in exactly the same way that an STL iterator is, and the only reason you think one is easy and not the other is because you know Python and not C++.)

Here's an example: A co-worker looked at a function I wrote that converts a table to a tree, and he said to me, "I thought Python was supposed to be readable, but I have no idea what this is doing."

See for yourself: https://gist.github.com/3988350

I agree with your co-worker. The indirection is kind of annoying to follow to be completely honest, so if your co-worker isn't proficient in Python I can understand how this would seem impossible to sort out.

Manually capturing free variables via:

  def __init__(self, x, y, ..):
    self.x = x
    self.y = y

Is so tedious and DRY-violating.

This is true. I'd prefer scala-style constructor syntax - though I'm not sure how you could retain python's wonderful symmetry between constructors and methods, and the distinction between allocation and initialization.

I don't know Scala, but the Erights language does something like (pseudo-syntax):

  def Circle(center, radius):
    circumference = 2 * pi * radius
    return object:
      to getCircumference():
         return circumference
      to ...

The "self" is the lexical scope. Simple and more effective than Python's method, IMO.

Ironically, I didn't understand Python's list comprehensions until I learned about Haskell's version (which is the original source of Python's), along with the explanation that Haskell's list comprehensions are taken straight from mathematics. Indeed, Haskell's version are almost ASCII-art mathematical set notations.

Even now, I still like Haskell's

   [fn(x) | x <- myList, x < 5]

over Python's equivalent

   [fn(x) for x in myList if x < 5]

Of course, I'm a mathematician, so that probably explains everything about my convoluted path of understanding these things, and my preferences to this day. :-)

List comprehensions are not deep magic. If you use SQL as your frame of reference, it's actually pretty easy to pick up. They also add a hell of a lot to readability once you know what it does.

Your critical phrase phrase being "... once you know what it does.". I didn't say it was hard, I said it required learning and experience to use. The OP claimed that non-expert python programmers could read it without that experience. The same is true for virtually all of C++ too.

That is a given, I agree.

But a complex program written in C++ (or using advanced C++ constructs) will scale much worse than a Python one, in my opinion.

I don't think that's necessarily true. In my opinion, both languages can be used by novices for simple scripts and by experts for complicated tasks. However, C++ seems to be getting easier for simple tasks (lambdas, initializers, auto, alias templates, etc.), while Python is getting more complex/powerful (metaclasses, exception tweaks, new I/O and function annotations — just to name a few).

RuntimeError: cannot add String and Integer

Absolutely agreed: to me, Python is a local maximum rather early on the readability vs. complexity graph. I think as complexity increases, an explicitly-typed language becomes much more understandable because local type annotations require less context switching to reason about when compared to an implicit language.

List comprehensions read like what they are (except for the stupid backwards order if you have multiple 'for's).

Decorators are pretty opaque; idiomatic python makes minimal use of them, and uses them only for things that don't change the meaning of the method inside. I've never used @classmethod and hope to never have to. I don't think it's fair to compare to an STL iterator, which is something you're encouraged to use as much as possible.

I don't know what you're talking about for iterables; aren't they obvious?

The iterable point was that the syntax is obvious but the behavior is not. They "look like plain data" sometimes, and some times they don't; and the only way to tell the difference is to know the characteristics of what you are iterating over. They're the same kind of too-clever-by-half design that C++ tends to confuse people with. People who know it love it, and people who don't think it's voodoo.

Decorators aren't difficult to understand. It tells you that the function is modified in some way. Iterables and list comprehensions are also easy to read, and I do not have a deep understanding of Python at all.

Right. I saw my first decorator before I knew what one was, and just from looking at it I knew enough to ask my friend "This thing looks like it's modifying the function somehow, what is it?".

Reply on news.ycombinator.com