Thursday, June 4, 2009

A response to "Python sucks"

I recently saw an article on Programming Reddit, titled, "Python sucks: Why Python is not my favourite programming language". I personally like Python quite a lot (see my blog title), but I figured I might read an interesting critique, probably from a very different point of view from mine. Unfortunately that is the opposite of what I found. The post was, at best, a horribly misinformed inaccurate critique, and at worst an intentionally dishonest, misleading, farce. The post can be found here. I felt the need to respond to it precisely because it is so lacking in facts, and reading it one can get impressions that are completely incorrect, and I am hoping I can correct some of these.

The post's initial statements about iterating over a file are accurate. However, he then goes on to say Python supports closures (which is true), and follows this with a piece of code that has absolutely nothing to do with closures, it is actually a callable object (or as C++ calls them, functors). The authors seems to take issue with these (though he doesn't explain why), ignoring the fact that Python has complete support for actual closures, not just callable objects.

The author then claims that Python has many other such arbitrary rules, using as an example the "yield" keyword. The author appears to be claiming the behavior of the yield keyword is arbitrary and poorly defined, however it's very unclear what his point actually is, or what the source of his complaints is. My only response can be to say that the "yield" keyword *always* turns the function it's used in into a generator, that is to say it returns an iterable that lazy evaluates the function, pausing each time it reaches the yield statement, and returning that object.

The author claims that many of the arbitrary decisions in Python are a result of Guido's insistence on a specific programming style, using as an example crippled lambdas. It is generally accepted that in Python lambda is just syntactic sugar for defining a function within any context (which the author completely ignores in his discussion of closure). To say that lambdas are crippled is to ignore the fact that absolutely nothing is rendered impossible by this, except for unreadable one liners.

The author's final complaint is directed at Python's C-API. This is possibly his least accurate critique. The author compares what is necessary to use a C library from within various programming languages. He shows that in Python all you have to do is import the library like you would for normal Python code. However, he goes on to say that for this to work you need to write lots of C boilerplate, and says that in other programming languages (showing examples from Haskell and PLT Scheme) this boiler plate is unnecessary. However, this is a completely disingenuous comparison. This is because what he is showing for Haskell and Scheme is their foreign function interface, not any actual language level integration. To do what he shows in Python is perfectly possible using the included ctypes library. I'm not familiar with the C-API of either Haskell or PLT Scheme, however I imagine that in order to work seamlessly and have the APIs appear the same as in code in those languages it is still necessary to write boiler plate so that the interpreter can recognize them.

In conclusion that blog post was a critique completely devoid of value, not worth the bytes that are used to store it. This is not to say there aren't any valid criticisms of Python, there are many, as evidenced by any number of recent blog posts discussing "5 things they hate about technology X", where technology X is something the author likes, because no technology is perfect, however no such honest critique was present here.

9 comments:

  1. And he goes by the name of "Blog User". I think it's just an elaborate troll blog.

    ReplyDelete
  2. Python lambdas would be a _lot_ nicer if they weren't crippled functions, if you could put more than one statement/expression/whatever in them.

    ReplyDelete
  3. Python's closures do not have write access to variables bound in an outer scope. I would not say Python has "complete support" for closures.

    The following function returns 7, not 9:

    def foo();
    x = 7
    def bar(): x =9
    bar();return x

    Yes, I know why. And the hacks you need to work around this are, well, hacks.

    PS Blogger screwed my indentation.

    ReplyDelete
  4. drj11, this has actually been fixed in Python 3 with the new non-local keyword.

    ReplyDelete
  5. @alex ooh. that'll teach me to live in the past. thanks for the heads up.

    ReplyDelete
  6. Bah... don't even waste time on stuff like that. Let's NOT throw Python on the flame arena, like they love to do with Ruby x Java or Java x .NET...

    ReplyDelete
  7. Python used to be great: simple, clear.

    Now the language is becoming bloated and full of special cases. For example: see 'Problem with generator expression and class definition' in c.l.py and the related discussion from PEP 289: http://www.python.org/dev/peps/pep-0289/#early-binding-versus-late-binding.

    I remember when the term 'pythonic' used to mean simple and elegant. Somewhere along the way developers forgot to remain pythonic. Now python has dozes of built-in functions. Py3000 is going to break (among other things) exceptions and print statements, forcing thousands of packages to be rewritten.

    ReplyDelete
  8. There really is a lot about Python that could be better. Have you seen the number of PEPs that have as their reason for being (or not being) that GvR was simply to stubborn to consider changing the language? A lot of the decisions seem arbitrary to me.

    ReplyDelete

Note: Only a member of this blog may post a comment.