Hacker News Reader

Comment by Kurtz79 | Hacker News Reader

It's succint, all right (well, sort of).

But Python's major strength is readability, even more than coinciseness, or better, to provide both at the same time.

C was born as a terse language, sacrificing readability for coinciseness (the original examples in K&R are incredibly succint, almost elegant, but far from readable). I can't see many improvements in C++ (a language that arguably has worse coinciseness than C, without gaining in readability in the process)in that regards, even with the new version.

I work with C/C++ and I could easily understand a Python script even when I wasn't that familiar with the language, the same cannot be really said for that code in C++.

BTW, I'm not bashing C++, that has a lot going for it,just not readability and coinciseness.

View on HN

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

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

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

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.

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.

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.

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

Python, like all dynamically typed languages, has no readability once you start using multiple modules. Static types are important for declaring interfaces between components. I have pretty much written off Python, particularly now that Go exists. I've wasted too many hours tracing down data types in complicated Python programs, usually resorting to printing out the types at runtime to decode them. The problem with Python: it is great for simple programs, where the effort to writing the simple program is much less than the comparable program in C/C++/Java; but simple programs often grow into complicated programs, and then the effort of maintaining Python far exceeds the effort to maintain C/C++/Java. Go, on the other hand, is pretty nice for writing a simple program, and can then scale into a complicated program.

That is a strawman requirement.

It is sufficient if the C++ code I write is reasonably readable to a fellow C++ programmer. I really don't care if it is not readable to a casual observer.

It is nice that Python code is readable to even to non python people. But it is not a requirement for every language.

Reply on news.ycombinator.com