Chad Perrin: SOB

10 March 2006

The Problem With Python

Filed under: Geek — apotheon @ 07:15

This is the second installment in what will hopefully be a longish series of explanations of problems I see with programming languages. I say “hopefully longish” because I hope to learn enough about a lot of languages to be able to continue this for some time to come, though future installments are likely to come much more slowly than these first two did.

I have some personal issues with Python that go beyond problems with the language itself, of course. For one thing, I don’t like the lack of end-delimiters for blocks of code at all. I’ve been known to say that Python makes my eyes bleed. It just looks wrong. All of that aside, however, it is of course not perfect in and of itself, as no language is perfect.

There are two things wrong with Python:

  • Rigidity
  • Rigidity

No, that’s not a typo. I really did mean to list rigidity twice. There are two types of utterly gratuitous rigidity screwing up Python.

The first is the rigidity of the language. This is actually great for teaching programming, as long as you’re trying to teach programming to students who think in a manner compatible with Python’s rigidity. It is like Pascal that way — it does things in a very carefully and rigidly structured way that helps to teach good habits to beginning programmers. Pascal was for years the de facto standard for an instructional programming language because it could teach “good habits” by way of its rigidity. As Pascal was to compiled languages in academia, so Python has come to be similarly useful amongst similarly dynamic languages.

Unfortunately, it can also contribute to tunnel vision in the student if you never let the poor student know that “good habits” aren’t synonymous with “the One True Way”. One of the marks of a true master is that (s)he knows when to break the “rules”, to discard those good habits, in favor of some elegant and unexpected solution where the “right thing” is, in fact, wrong.

Python makes that sort of thing very difficult. It does a fantastic job of dragging programming to a greater average level of elegance than Perl for instance, but to gain this it exchanges some potential for greater elegance. More to the point, however, in order to get that greater average level of elegance for programmers suited to Python use, it gives up a great deal of usability for many, many more programmers who don’t think exactly like everyone else in the Python community. That problem for many programmers is most clearly demonstrated by The Whitespace Problem. Indentation has a single Right Way in Python, and not only are you considered Wrong if you do it differently, but you simply can’t get the damned program to run. This is a problem with pretty much everything in Python. If you don’t like the way something is generally done in Python, you’re Wrong, and not only are you Wrong but your Wrong Way of doing things often won’t work, period.

The second type of rigidity screwing up Python is community rigidity, which is actually an outgrowth of the root cause of the language’s rigidity. This problem has been referred to as the Permafrost Problem — the Python community is permanently frosty to anyone that doesn’t think like the Python Collective, generally speaking. If you don’t do things the Python way — what to the Python community is the Right Way, with all other things being the Wrong Way — you’re Wrong. There are no appeals, though you may rehabilitate with dedication and contrition. It is in large part because of this second form of rigidity that the first form will probably never be fixed. Then again, maybe it shouldn’t be. As I said, it’s good for teaching good habits, and it’s still a good language the way it is. Its rigidity is useful a lot of the time.

An example of the problem of both forms of rigidity is Python’s handling of lambdas. Ruby, by contrast, allows anonymous “blocks” to be used and passed around as though they were individual discrete semantic elements. Python lambdas, on the other hand, do work similarly, but are (arbitrarily) limited to a single statement. Because of the rigidity of the community and core developers’ attitudes, that’s unlikely to change any time soon.

As with Perl, it would be nice if there were a binary executable compilation option for Python, but that’s not really endemic to the language. Python also has a couple other problems not endemic to the language: Ruby and Perl 6.

Ruby is, to many, all of Python’s benefits, none of its detriments, and some really cool bennies in addition. It’s much of Lisp’s list-handling, Eiffel’s and Perl’s syntactical ease, regexen almost on a par with Perl’s, Smalltalk’s masterful implementation of OOP, Perl’s flexibility, CLU’s iterators, and Python’s encouragement of good habits — or, more to the point, Ruby encourages and rewards good habits, while Python by contrast seems to merely punish bad habits.

Python succeeded in large part as an alternative to frustrations many had with Perl. Much of that frustration centers around such factors as the jury-rigged object oriented programming capability of Perl. It looks like the final release of Perl 6 may well sweep away pretty much all but the most superficial objections to Perl that make it unacceptable to many Python users.

I’m not nearly as familiar with the goings-on of Python development as I am with Perl or even Ruby development. For all I know, there might be exciting things happening in Python that will render all this Perl 6 and Ruby stuff irrelevant to Python’s niche, as Python might be carving out new territory for itself. On the other hand, I have a hard time imagining it doing much toward holding off its own obsolescence other than converging on Ruby, plus significant whitespace and minus flexible syntax. Maybe I just lack imagination, though.

13 Comments

  1. Good. I particularly agree with the point that master knows when to break the rules. I have witnessed cases where a goto (gasp) is the most elegant solution, even in languages that disdain (but provide) goto’s.

    I haven’t looked at Python yet, although I did meet its author (Guido van Rossum) at adjoining urinals during a conference one time. I guess sometime I’ll have to investigate out of pure curiousity, but you’ve given me the feeling that I wouldn’t want to actually use it for anything.

    Comment by Sterling Camden — 11 March 2006 @ 11:55

  2. Let me anticipate one of your future posts with Assaf’s view on everything that’s wrong with Java.

    Can’t wait to see what you’ll have to say about what’s wrong with Ruby.

    Comment by Sterling Camden — 11 March 2006 @ 09:13

  3. it gives up a great deal of usability for many, many more programmers who don’t think exactly like everyone else in the Python community.

    This kind of comment could only come from someone historically ignorant of programming languages other than the upstart scripting language, Perl. Why do you need 5 different ways to write an if statement? In nearly every other language, besides Perl, there’s only one way to do things because only one way needs to be remembered, thus simplifying the mnemonic load on the brain of the programmer and reducing the likelihood of errors and cruft in the core interpreter.

    Perl has so many different ways of doing things that it takes years to become familiar with all of the different syntactic conventions and it’s difficult to read other people’s code because they use different conventions than you’re used to.

    And speaking of rigidity, all of the different ways of doing things in Perl has meant a lot of ugly hackery has gone into the core language which means that it’s very rigid and difficult to add new features too, and when Perl 6 finally comes out, because they’ve had to rewrite so many of the internals from scratch, Perl 5 users will likely have to relearn vast swaths of the language in order to use the new version.

    The Whitespace Problem. Indentation has a single Right Way in Python

    Python does have a serious whitespace problem, but it’s not about the “Right way”, it’s that differences in whitespace characters that aren’t visible can be important. You can use 2 space indentation, 3 space indentation, 10 space indentation, tab indentation, whatever you want, as long as all items at the same indent level have the same characters in the indentation.

    This is in violation of Unix tradition, but the benefit is that it encourages programmers to use consistent indentation and good programming style in an area that is often one of the simplest things that an experienced programmer can do to make their code more understandable to those less familiar with the language. Believe it or not, you actually can use a semi-colon as a statement separator in Python and put two statements on one line.

    I still agree with you that the white space thing can be pretty annoying.

    If you don’t like the way something is generally done in Python, you’re Wrong, and not only are you Wrong but your Wrong Way of doing things often won’t work, period.

    That’s the case with any non-ambiguous language. If you violate the language syntax, it shouldn’t execute or the behavior will be nondeterministic (i.e. it probably won’t do what you were expecting it to do, but you may not realize it until something gets very screwed up).

    Python lambdas, on the other hand, do work similarly, but are (arbitrarily) limited to a single statement. Because of the rigidity of the community and core developers’ attitudes, that’s unlikely to change any time soon.

    Python lambdas are admittedly not that great. But, in the last two years, I think I’ve only used them just twice; they just aren’t an important part of the language. It is my understanding that there is a current discussion among the core developers about how to fix them. Lambasting the community and core developers about rigidity on this issue is a completely undeserved ad hominem attack.

    As with Perl, it would be nice if there were a binary executable compilation option for Python, but that’s not really endemic to the language.

    Like Java, Python modules are compiled into bytecode to speed execution. Unlike Java it happens automatically. If you had even a modicum of experience with Python, you would know this.

    I’m sorry, but your diatribe is, at best, full of misrepresentation. Your arguments about rigidity (even when your points-in-case are by themselves valid objections to the language) is not something that’s unique to Python, and in most non-Perl circles is not viewed as a detriment to the language, but a good thing. It helps programmers avoid unexpected behavior from unclear syntax while at the same time reducing the mnemonic load of learning the language and eliminating unnecessary cruft from the language internals.

    If you have felt a “chill” from the Python community, it’s because your are vocal about your dislike of Python, your criticisms are mostly about trivialities and show that you do not really understand what you are talking about, you misrepresent the real issues, and when considering your stance about the main alternative, Perl, and how wonderful and amazing it is even when it suffers from some of the same problems, you come across as a hypocrite.

    I like you for a number of reasons, but your tendency to lash out against Python gets tiresome.

    Comment by scoth — 13 March 2006 @ 03:47

  4. scoth — (note: I fixed a markup typo in your comment. Hope you don’t mind.)

    This kind of comment could only come from someone historically ignorant of programming languages other than the upstart scripting language, Perl.
    Actually, I’m fully aware that most languages have fewer conditional forms than Perl. I have at least a little familiarity with a number of other languages (certainly more than Python), including C/C++, Basic, and Ruby.

    Why do you need 5 different ways to write an if statement?
    I don’t really, but I for one like having the options. You’re entirely welcome to ignore four out of five. The point is not to memorize the entire Perl language (even Larry Wall hasn’t done that), but to use the bits with which you’re comfortable and, at any given moment, use the bits that best suit your needs. As one grows more familiar with the language, one can more effectively use more of it. One of the things I like about Perl is that it has a reasonably shallow learning curve, but the curve extends onward effectively forever. There is no plateau.

    the likelihood of errors and cruft in the core interpreter.
    And yet, perl is one of the faster and more reliable parsers/interpreters/compilers available.

    it’s difficult to read other people’s code because they use different conventions than you’re used to.
    There’s certainly some truth in that, though it’s not as bad as you seem (to me) to make it sound. I probably should have included a comment to that effect in my entry titled The Problem With Perl.

    Your commentary about the “rigidity” of the Perl internals bears some truth as well, though “rigidity” isn’t the term I’d have used to describe it.

    Python does have a serious whitespace problem, but it’s not about the “Right way”, it’s that differences in whitespace characters that aren’t visible can be important.
    Tomayto, tomahto.

    This is in violation of Unix tradition, but the benefit is that it encourages programmers to use consistent indentation and good programming style
    Ruby “encourages” indentation and “good” style. Python mandates it. Perl doesn’t care. I prefer encouragement over either of the other two approaches, thanks.

    That’s the case with any non-ambiguous language. If you violate the language syntax, it shouldn’t execute or the behavior will be nondeterministic
    On the other hand, very few languages cover such minutiae within the realm of “syntax”. It seems gratuitously inclusive in that sense and, thus, gratuitously rigid. Of course, the reason it seems that way to me is largely that I don’t think like a Python programmer (see above re: thinking like a Python programmer).

    Python lambdas are admittedly not that great. But, in the last two years, I think I’ve only used them just twice; they just aren’t an important part of the language.
    I’m sure part of the reason you don’t use them much is the simple fact that they kinda suck.

    Lambasting the community and core developers about rigidity on this issue is a completely undeserved ad hominem attack.
    It may be born of some ignorance of what’s going on in the Python community, but I hardly think it’s completely undeserved, and since I was addressing issues with cultural rigidity it’s not simply an ad hominem argument. It is, strictly speaking, “ad hominem” in that it addresses the people, but it does not suffer as an ad hominem fallacy because the people (in a general sense) are relevant to the topic.

    Are you trying to tell me that Python programmers aren’t, as a community, more resistant to linguistic change than (for instance) Perl programmers? If so, I’d like to hear some more to support that position.

    Like Java, Python modules are compiled into bytecode to speed execution. Unlike Java it happens automatically. If you had even a modicum of experience with Python, you would know this.
    Four words: Not The Same Thing. Perl actually undergoes binary compilation when it’s run, rather than being interpreted (even as bytecode), though this is reportedly going to change with Perl 6. It still doesn’t render persistent binary executables. The same is true of Python’s bytecode compilation and subsequent interpretation. Thus, my comments on the subject.

    I’m sorry, but your diatribe is, at best, full of misrepresentation.
    It’s not any more a diatribe than my previous entry titled The Problem With Perl. I don’t think it’s really misrepresentative so much as simply written from the perspective of someone not particularly enamored with Python. While there may be biases (and I’ve tried to make them clear without devoting half the essay to disclaimers), I don’t think I’ve actually said anything untrue.

    in most non-Perl circles is not viewed as a detriment to the language
    And? I’m sure non-Perl users can benefit from the occasional bit of Perl perspective, just as Perl users can benefit from the occasional bit of non-Perl perspective (such as Python-user perspective). The fact that some people never stop to consider whether a lack of flexibility might occasionally be detrimental doesn’t mean it’s not sometimes detrimental. There are a lot of C and Java programmers who consider Python’s various flexibilities to be Bad Things, and Python programmers who consider C and Java rigidities that don’t exist in Python to be Bad Things as well. Both sides have their relevant points that should be made.

    the mnemonic load of learning the language
    I don’t see how learning the entire language is necessarily relevant to its use.

    unnecessary cruft from the language internals.
    I don’t think “cruft” is really an entirely appropriate term here. For the most part, the language’s internals seem to be important and good for providing a productive, beneficial tool for the programmer. The cruft that exists seems to mostly arise from attempts to overcome historical rigidities in the language’s design (such as the fact that arrays and hashes can only be passed in scalar context by way of reference). Sure, as has been remarked elsewhere, the language internals look like exploded whale guts, but you can make a lot of very useful things from exploded whale guts — like perfume.

    If you have felt a “chill” from the Python community, it’s because your are vocal about your dislike of Python
    I haven’t personally encountered that chill, really. I’ve mostly watched it directed at others. It’s something I’ve learned from observation far more than personal experience. As such, I don’t think anything I’ve said or done has prompted it very much.

    My personal experience seems to be that Python enthusiasts seem to have a problem recognizing when someone is trying to be even-handed without coddling, as I’m doing here. I notice you didn’t tear into me for daring to question Perl’s shortcomings. I have yet to see a Python enthusiast admit to anything less than perfect about the language aside from details they themselves describe as insignificant (as you’ve done with the matter of lambdas). I think that ties in pretty well with the community rigidity, wherein there’s a Python Way and a Wrong Way, and that’s all there (generally) is to it.

    I think that, if you ignore any clear references to my personal preferences in both Python and Perl, you’d find that this entry and the previous would both come across as about equally critical — and I hardly think statements of personal preferences qualify me as a hypocrite. They do, however, probably incline one to believe I’m being harsher about one language than the other.

    Comment by apotheon — 13 March 2006 @ 07:40

  5. I apologize, that came across much more harshly worded than I intended. Normally I wouldn’t have posted it, but I thought that you might respect a strongly worded opinionated reply because I think that you appreciate conflict. I do not think that you are ignorant or a hypocrite, and I enjoy reading your strongly opinionated pieces, even when they make me mad ;-) The fact that they can make me mad or react emotionally in any way is a testament to your writing ability.

    I think you’re getting a lot closer to a strong and valid critique of Python, rather than “it just makes my eyes bleed”, but your starting premise of rigidity probably won’t work well because rigidity a very common trait of programming languages. The concept of “There’s only only one Right way to do it” was invented by the Python community as a way to tease Perl users about what is arguably one of Perl’s nicest and simultaneously most annoying features, “that there’s more than one way to do it”. When you argue that way, you’re starting with an argument that is designed to be hostile to your point of view.

    There are a few other things that Python got wrong, but I personally feel that there are fewer of these than with Perl. I think that if you seriously tried to use Python for a month or two, you could rapidly come to accurate conclusions about what’s wrong with it (heck, you might even decide that you don’t hate it as much as you thought) and you’d also develop a finer understanding of what’s wrong with Perl. But there’s no rush, I think you’re trying to work more with Ruby right now, which will also provide you with good perspective, even if it get’s a few things wrong in the same way that Perl does ;-)

    Thanks for fixing my bad italics close tag(s) in the last comment.

    Comment by scoth — 13 March 2006 @ 07:59

  6. I don’t so much like the conflict as I like having my ideas challenged effectively. It helps with growth. I also appreciate direct and bluntly honest responses to what I say, whether one agrees or not, and I appreciate your commentary.

    I absolutely agree that learning more about Python would give me better perspective on both Perl and programming in general. I don’t think I have enough to time to learn everything, though, and Python keeps getting pushed further down the priority list by other things (like Ruby) that are less uncomfortable for me to learn. Maybe I should go back at some point to learn more Pascal and Object Pascal, and use that as a way to “trick” myself into getting more acclimatized to the things about Python that I don’t like so that I can more readily encourage myself to learn it. Before I do that, though, I’m sure to return to C and spend some time on Scheme.

    The “makes my eyes bleed” thing about Python is mostly what I say when I don’t want to try to get into a discussion of what I dislike about Python with people who have a vested interest in convincing me it’s kewl. That complaint is flippant and very much a personal issue, and thus doesn’t invite “corrections” of my critiques. When I’m more in the mood to discuss it (and feel better prepared), I’ll start in on something like this entry.

    Python, I’m sure, has fewer language-specific problems than Perl. That’s pretty much going to be a given when comparing a simpler design (Python) with a more complex design (Perl) in any case. Of course, that simpler design’s form is, in my estimation, itself symptomatic of the major problem with Python.

    re: italics No problemo. I make the same sort of typo all too often, and sympathize. It was pretty clear to me, immediately upon laying eyes upon your commentary, what you’d meant to do.

    Comment by apotheon — 13 March 2006 @ 08:34

  7. Couple more quick things. I may come back with more later, but I’ve already spent far too long replying instead of working today ;-)

    “It’s difficult to read other people’s code because they use different conventions than you’re used to.”

    There’s certainly some truth in that, though it’s not as bad as you seem (to me) to make it sound.

    Readability is actually the BIGGEST reason why I prefer Python over Perl. I think it’s pretty significant. Most of the programming tasks that I do mostly relate to reading other people’s code or revisiting my code several months after it’s been written. With Python the time it takes to understand what’s going on in unfamiliar code is significantly shorter than it is with Perl. Often, even non-programmers and people who have never seen Python code before can read code and submit “patches”.

    Four words: Not The Same Thing. Perl actually undergoes binary compilation when it’s run, rather than being interpreted (even as bytecode), though this is reportedly going to change with Perl 6. It still doesn’t render persistent binary executables. The same is true of Python’s bytecode compilation and subsequent interpretation. Thus, my comments on the subject.

    Its true that Python doesn’t render persistant binary executables, but it does render persistent bytecode executables (.pyc) out of files called as modules, which means that it doesn’t have to re-generate the bytecode every-time it’s run. The bytecode can then actually be redistributed and run without source. This IS significantly different from Perl. No, it’s not the same thing as a binary executable, but it helps. And it’s not too bad to tie C code directly into Python programs, so the incentive to do more optimization is fairly low.

    My personal experience seems to be that Python enthusiasts seem to have a problem recognizing when someone is trying to be even-handed without coddling, as I’m doing here. I notice you didn’t tear into me for daring to question Perl’s shortcomings. I have yet to see a Python enthusiast admit to anything less than perfect about the language aside from details they themselves describe as insignificant (as you’ve done with the matter of lambdas). I think that ties in pretty well with the community rigidity, wherein there’s a Python Way and a Wrong Way, and that’s all there (generally) is to it.

    I never claimed that Python was without problems, and I’m sure I could come up with a list of both Python and Perl’s shortcomings, and what’s good about each. As someone who has used both languages for several years, I think I’m fairly qualified to do so. I so prefer Python, so I’m sure you can imagine which would have a better ratio of good-to-bad.

    Now, here are some of my biggest complaints about Python:

    One of the things that bothers me most about Python is the effects of the enforced indentation rules (especially when combined with the lack of a case statement) actually overly discourage programmers from making complicated logic rules because the indentation can get out of control. This isn’t necessarily a bad thing in itself, because rethinking the logic ofen leads to a more elegant approach (very few if-then-else statements from hell), however it also encourages the use of uncessary break statements within loops which makes tracing program execution more difficult. Perl has even more ways to do multiple exits points out of a block of code, but they aren’t quite as commonplace in general usage. I’d say that Python and Perl tie on this.

    One of the things I really miss about Perl is the conciseness of it’s regular expression syntax, by comparison, Python’s takes a lot more work, and search and replace is plain bad. As a Perl beginner, the equals tilde and bang tilde syntax was really confusing so I can see why they did it that way. Still the verdict is that Perl wins hands down.

    The other thing I miss about Perl is the availability of libraries and the CPAN repository. Perl partially makes up for this amazing resource by having almost no limit on what can be added to the repository resulting in some pretty poor code, but there are definately lots of gems in there. There is already some of the start of this type of repository in Python, and as the language grows in popularity I think that the amount of libraries will grow significantly. I give the edge to Perl, but Python is making strides to bridge the gap.

    Perl’s debugger is much nicer than Python’s. With Perl code, you can step through statements and get the values that variables are set to pretty easily. However, Python’s error traceback messages are so much better than Perl’s errors and warnings, that I didn’t miss the Perl debugger after the first month or so with Python. As a side note, Python’s interactive mode is really helpful in debugging, and Python has a really nice code profiler that making sure that you’re optimizing the right thing when you do need to optimize. I give the advantage to Python.

    Python one-liners aren’t nearly as good as Perl one-liners. While you can do fairly simple one-liners with Python, anything that requires more than one level of logic (due to enforced indentation) isn’t really possible. Python’s nice inteteractive mode makes one-liners much less important, but there are few things quite as cool or beautiful as a well written Perl one-liner. I give the advantage to Perl.

    I haven’t mentioned these before because you never asked. If you’re interested in my biggest gripes about Perl beyond those that I’ve mentioned, I’d be happy to tell you about those too (the fact that you manually have to parse variables passed to subroutines is pretty close to the top if you’re curious).

    I think you’re misrepresenting the rigidity of the language much beyond the syntax. The nature of programming is such that there are always more than one way to do things no matter what language that you’re using. I have never found Python inhibitive in any way of my ability to write an algorithm in severl different forms. There is a tiny bit of carry-over in the community from the syntax to other aspects of the language, but it’s never anything that I’ve had problems with.

    I never considered learning the syntax rules more burdonsome than learning any other programming language (including Perl, C/C++, Java, PHP, Lisp, Prolog or Fortran), in fact the simplicity of the syntax rules made it the easiest of those languages to learn. Well, IIRC, Prolog was pretty simple too, since it was so similar to boolean logic that I already knew most of it.

    Ruby “encourages” indentation and “good” style. Python mandates it. Perl doesn’t care. I prefer encouragement over either of the other two approaches, thanks.

    I do too. As I’ve said, the enforced indentation does present a problem, but for me it’s for different reasons than what you’ve presented. Your reasoning mostly sound like you’re not actually weighing the costs and benefits of a different approaches, but dismissing the Python approach off-handedly because it is somehow limiting your personal individuality. I don’t find that a compelling argument.

    I’m sure non-Perl users can benefit from the occasional bit of Perl perspective, just as Perl users can benefit from the occasional bit of non-Perl perspective (such as Python-user perspective).

    Actually, my antecdotal experience leads me to believe that the vast majority of Python users are former Perl users. Trying to convince Python users with Perl-engendered points of view is like beating a dead horse. That’s not to say that Python programmers shouldn’t be reminded of Perl’s strengths from time to time, but usually, in the minds of Python programmers, the issue has already been decided. I used Perl for several years and by the time I was introduced to Python, I was pretty good with even some of the more obscure bits of Perl objects, references, coding styles and was able to read most of the code from the CPAN repositories, even when I wasn’t familiar with the writing convetions being used by the author. It takes a darn long time to get to that point with Perl though. I was probably to the same level of comfort with Python after less than 6 months. Sometimes I like reading Perl, and I’m even half tempted to write more of it so that I retain more of what I know, but I would never voluntarily switch back to Perl 5 now, and Perl 6 is probably out of the question too.

    I think that you would have a better argument if you used a less Perl-centric approach, especially as I stated in my previous post, if you forgo the argument that the Python community came up with as flame-bait to Perl users.

    Comment by scoth — 13 March 2006 @ 09:54

  8. Python, I’m sure, has fewer language-specific problems than Perl. That’s pretty much going to be a given when comparing a simpler design (Python) with a more complex design (Perl) in any case. Of course, that simpler design’s form is, in my estimation, itself symptomatic of the major problem with Python.

    And I have just the opposite view. We both agree that Python has a simple design, but I think that Perl is less designed and more grown and cobbled together through feature-creep. I therefore find Python the more elegant of the two.

    Python keeps getting pushed further down the priority list by other things (like Ruby) that are less uncomfortable for me to learn.

    That’s perfectly understandable. If I had to give up Python, Ruby would probably be first on my list. I’m really looking forward to what you have to say about it, even if you judge it strictly based on it’s differences to Perl.

    I don’t honestly care what your language of choice is, whatever works for you works for you. But it seems that you’re Python-bashing based on arguments that the Perl and Python communities have gone back and forth over for years, mostly for reasons that don’t show a deep understanding of the language.

    Comment by scoth — 13 March 2006 @ 10:36

  9. scoth: Rather than respond directly, here, to your last couple of posts about Python, I’ve decided to create yet another entry in the main weblog. Check out A Serpent in Ruby’s Garden for details. It’s more an explanation of my perspective on Python as compared with Ruby than a more general view of the points you brought up, but it does address several of your points.

    Comment by apotheon — 14 March 2006 @ 02:38

  10. Just a quick note… Perl 6 was mentioned, repeatedly, as if it’s relevant. But it lacks one essential feature that Ruby and Python both have — existence.

    The idea of Perl 6 has been in development for 7 years now, without a release yet. That puts it squarely in vaporware valhalla along with luminaries like Duke Nukem Forever and Paul Graham’s Arc.

    It may be released someday, but it’s not really relevant until then.

    Comment by ToyKeeper — 23 March 2006 @ 12:37

  11. Okay, I’m replying to the blog posts in reverse order. Oops. I started with a long response to the most recent, A Serpent in Ruby’s Garden, and now I’ve gone backward to this Problem With Python article.

    BTW, I’ve been enjoying this discussion, even if it does distract me from work and occasionally get me to say things which might be rude. Your comment about this is reassuring, though:

    I don’t so much like the conflict as I like having my ideas challenged effectively. It helps with growth. I also appreciate direct and bluntly honest responses to what I say, whether one agrees or not, and I appreciate your commentary.

    This is reassuring, but please do let me know if I get too abrasive. I really don’t want to insult or anger anyone; I just want to discuss a topic I’m passionately interested in.

    One of the marks of a true master is that (s)he knows when to break the “rules”

    Yup. But I don’t get the impression that you’re to that point yet. I know I’m not. I still do break the rules sometimes, when I simply can’t figure out a better way of doing things, but it usually gives me a nagging feeling that I’m missing something obvious.

    Also keep in mind that when the true masters break the rules, they often end up making new rules (by way of later imitation). Well-maintained programming languages will change their rules over time, to incorporate these improvements. For proof or examples, look at the history of features in Python and Ruby — both of which have quickly gobbled up new ideas for years.

    If you don’t like the way something is generally done in Python, you’re Wrong, and not only are you Wrong but your Wrong Way of doing things often won’t work, period.

    Syntactically, yes. This is true for all computer languages.

    Stylistically, no. Python will let you program as if you’re using Visual BASIC, if you want to. It will just take longer to write programs, and you’ll end up with larger, slower, less concise code. Feel free, though, to use loops and counters and long algorithms when you could use a list comprehension; or to use lengthy conditional flow logic where a simple hash lookup would suffice. Python doesn’t care.

    However, Visual BASIC won’t let you program using Pythonic methods. And to a lesser extent, neither will Perl. They simply don’t have enough expressive power to be capable of handling a lot of Python’s features. Similarly, Python won’t let you do a lot of things you can do in Lisp, because it’s lacking some of Lisp’s basic features. Ruby is a good match for Python, though. As far as I can tell, they have a mutual 95% feature overlap.

    The second type of rigidity screwing up Python is community rigidity,

    The community, frankly, is sick of hearing complaints based on surface-level evaluations of the language. If you bitch to them about whitespace, they’ll stereotype you as yet another person who dismisses their work without even understanding it, and ignore you. I can’t say I blame them; it gets old. It’s like saying there’s nothing good about lisp because it has so many damn parenthesis, and what the hell is “cadr” supposed to mean anyway?

    On a related note, one of my biggest pet peeves about Linux is that, as a rule, almost every Linux distro review focuses entirely on the installer and the default desktop. So, as a rule, I find those reviews useless. I don’t really care whether it takes 30 minutes or an hour to install, whether the installer has icons and a mouse pointer, or what theme the widgets use. But I do care how well the distro works after installation. Will it help me get things done, or hinder me? Will I need to reinstall it every six months, or can I just upgrade as necessary without any traumatic rebuilds? Does it provide the packages I want, or do I have to build them myself? If I were to choose a distro based on surface-level reviews instead of deeper features, I’d end up with something I hate.

    I mention this mostly as a plea, not necessarily to you, but to all writers out there. Please don’t write surface-level comparisons, without being explicit about it. Don’t review a book based on its cover. Anyone can do that. Give us readers something with more meat.

    Ruby is [has] … Perl’s syntactical ease, …

    That’s funny.

    It’s like saying Java is almost as concise as COBOL.

    Why do you need 5 different ways to write an if statement?
    I don’t really, but I for one like having the options. You’re entirely welcome to ignore four out of five.

    No, actually, I’m not. If I need to work with other programmers, which almost every paid programmer does, I’m going to be reading a lot of code. And if I don’t know 80% of the syntactic options in a language, I’m not going to be able to understand other peoples’ code.

    That’s one of the main reasons Perl is notoriously hard to read.

    The point is not to memorize the entire Perl language (even Larry Wall hasn’t done that),

    You’re not helping your case. If even the author doesn’t know the entire language, how can we mortals expect to use it?

    I don’t expect to need all of a language’s libraries, but I’m probably going to need most of the languages innate features. It’s important to distinguish between the two… unless, of course, you’re using lisp, where libraries routinely implement new syntax.

    One of the things I like about Perl is that it has a reasonably shallow learning curve, but the curve extends onward effectively forever. There is no plateau. … I don’t see how learning the entire language is necessarily relevant to its use.

    I think what you’ve described is a good quality in terms of programming concepts; language theory and information theory. But it’s a very bad thing for an individual language. Yes, you’re going to keep learning new tricks and concepts over the years. But those things will be independent of any given language. The language is merely a medium for the concepts.

    By way of analogy, consider English. Even as complex and inconsistent as it is, most people pretty much know how to use it by the time they’re eight years old. They don’t stop learning, of course, but once they know the basics, the stuff they learn is a different type of knowledge. They learn new words and phrases, much like learning new add-on libraries in Ruby. They learn how to use metaphors, examples, and other techniques. This is much like figuring out how to use common algorithms like quicksort or a Schwartz transform. They learn how to structure an essay, or a book, which is about like figuring out how to organize functions/classes/modules. These things are all independent of the language. If you know how to write a good essay in English, it’s not hard to do so in German. The fine-grained details change, but the overall essay can be almost the same. If you write a good program in Perl, it’s pretty easy to port it to Ruby or Python or any other language with sufficient expressive power.

    I guess what I’m getting at is that most people who already know a few programming languages can pick up new ones in a matter of days. But that’s not generally the case with Perl. It takes a long time to learn even if you know what you’re doing, because it has so many exceptions and variations and obscure, quirky options. Most of those oddball ways of doing things are great for writing perl poetry, but they’re not actually very useful and can even inhibit productivity.

    Python does have a serious whitespace problem, but it?s not about the “Right way”, it?s that differences in whitespace characters that aren’t visible can be important.
    Tomayto, tomahto.

    Not really the same thing. If I understood correctly, your complaint was that Python requires you to indent in exactly one Right way, and anything else is Wrong. But that’s not true. You can indent however you like… the only thing Python requires is that it’s not ambiguous. You don’t even have to be consistent… indent this block by one space, and that block by three, and over here we’ll use two tabs. But each group of sibling statements must be indented the same amount, and it must be greater than that of its parents.

    If Python tells you you’ve indented Wrong, it’s because it genuinely is unclear, and the interpreter can’t objectively figure out what you mean.

    Are you trying to tell me that Python programmers aren’t, as a community, more resistant to linguistic change than (for instance) Perl programmers? If so, I?d like to hear some more to support that position.

    Yes.

    Look at the changelog for Python, and then look at the changelog for Perl. Seriously.

    Python has had a lot of new features and language concepts added in the past 7 years. They were added because the community wanted the features. If you want a feature, create a PEP (Python Extension Proposal) and submit it. If it’s good, and a lot of other people agree that it’s good, it’ll probably be incorporated into the language.

    In the span of time mentioned, Python has gone through several major revisions, including 1.4, 1.5, 2.0, 2.1, 2.2, 2.3, and 2.4. OTOH, Perl has gone from 5.7 to 5.8, and received no significant conceptual changes.

    BTW, I chose 7 years because that’s how long ago they started on Perl 6, at least according to my quick slashdot search. And from what I can tell, Perl 6 will have about as much in common with Perl 5 as Java does with C. It’s not the same language, and I think it is misleading to think of it as a “new version”. So, since Perl is currently Perl 5, which is totally stagnant, I’d say the Perl (5) community is pretty resistant to change.

    Four words: Not The Same Thing. Perl actually undergoes binary compilation when it’s run, rather than being interpreted (even as bytecode), though this is reportedly going to change with Perl 6. It still doesn?t render persistent binary executables. The same is true of Python’s bytecode compilation and subsequent interpretation. Thus, my comments on the subject.

    It’s much easier to add a JIT compiler into a language which isn’t changing any more. I don’t actually know the status of Python’s optimization code, but I haven’t (subjectively) found Python programs to be significantly faster or slower than Perl. I do know, though, that it’s fairly easy to implement bottleneck sections in C and then call the optimized version from Python. This lets you speed things up when it matters, and the result will be far faster than anything the interpreter could do on its own.

    I don’t think I’ve actually said anything untrue.

    I think that’s why he chose “misrepresentative” instead of “false”.

    Unfortunately, making fair, accurate, and meaningful evaluations requires a pretty hefty amount of research. The message I got from Scoth’s comment was “do your research before you post”.

    [rigid community, “chill”, etc…]

    I have, unfortunately, encountered harsh reactions from nearly every large community I’ve looked into. Particularly on IRC, it seems that the primary channel (whether it’s #python, #ruby, #perl, or whatever) inevitably seems to consist of lurkers, newbies asking RTFM questions, bitter old “experts” who LART the newbies, and an occasional reasonable question which gets blasted out of the water by one of the resident geezers.

    Most of the time, anyone who even mentions a similar/competing project gets beaten and dragged away bloody before anyone even has a chance to hear what they were going to say.

    Of course, IRC isn’t a great example. Mailing lists are usually much less uncivil, and the in-person meetings I’ve had were downright friendly. But what I’m getting at is that any large community has an awful lot of annoyances to fend off, and it can be difficult to get in far enough that anyone will listen to you.

    The “makes my eyes bleed” thing about Python is mostly what I say when I don”t want to try to get into a discussion

    That’s good, because it will make sure nobody listens to you unless they already agree with you.

    I think that, if you ignore any clear references to my personal preferences in both Python and Perl, you’d find that this entry and the previous would both come across as about equally critical — and I hardly think statements of personal preferences qualify me as a hypocrite. They do, however, probably incline one to believe I’m being harsher about one language than the other.

    I don’t think it’s so much a matter of preference or bias as a matter of accurately representing how well you understand something alongside the conclusions you make about it.

    Your writing style is quite good, and makes you sound like an expert. And, if I didn’t know that you’re not, or I didn’t recognize the various bits of misleading data, I’d probably think “Wow, this guy just saved me a lot of trouble — I should stay away from Python.” But if you were to represent yourself as relatively new to the language, I’d receive a totally different message.

    And, like I mentioned in IM, I wouldn’t give you such a hard time if you didn’t write for a living. :)

    Comment by ToyKeeper — 24 March 2006 @ 12:35

  12. Syntactically, yes. This is true for all computer languages.

    Er, except HTML. And look at the problems that particular mess has inflicted…

    Comment by ToyKeeper — 24 March 2006 @ 12:40

  13. One of the marks of a true master is that (s)he knows when to break the “rules”

    Yup. But I don’t get the impression that you’re to that point yet. I know I’m not. I still do break the rules sometimes, when I simply can’t figure out a better way of doing things, but it usually gives me a nagging feeling that I’m missing something obvious.

    You’re right: I’m not to that point yet. I sometimes break the rules because I’ve run up against a wall as well, and similarly tend to feel like I’m missing something obvious. That doesn’t change the fact that allowing greater flexibility while encouraging greater conformance to common “good practice” strikes me as a better approach than simply making it “impossible” to violate guidelines of common good practice. The reference to the master knowing when to break the rules is simply an example of why that greater flexibility is desirable.

    If you bitch to them about whitespace, they’ll stereotype you as yet another person who dismisses their work without even understanding it, and ignore you.

    On the other hand, as long as members of the Python community keep dismissing people as “wrong” for disliking Python’s whitespace problem, they’ll get stereotyped as well, and the more they’ll hear complaints about it as well when they talk about how “readable” Python’s whitespace rules make Python code.

    Ruby is [has] … Perl’s syntactical ease, …

    That’s funny.

    It’s like saying Java is almost as concise as COBOL.
    I disagree rather severely. For one thing, Java is more concise than COBOL by quite a bit, so saying it’s “almost as concise” isn’t even vaguely analogous to what I said. For another, when I talk about Perl’s syntactical ease, I’m clearly talking about something other than the Canonical Holy Writ Of Python Declaring Perl Unreadable. Obviously.

    Why do you need 5 different ways to write an if statement?

    I don’t really, but I for one like having the options. You’re entirely welcome to ignore four out of five.

    No, actually, I’m not. If I need to work with other programmers, which almost every paid programmer does, I’m going to be reading a lot of code. And if I don’t know 80% of the syntactic options in a language, I’m not going to be able to understand other peoples’ code.

    Let’s just get rid of all the rest of the syntactic sugar in the language, then. We’ll only use .add for addition operations in Python. We’ll ditch all that great looping stuff and use GOTO instead. Hell, let’s just go back to writing assembly language, or maybe adopt Brainfuck as our language of choice from now on.

    I like being able to use || and unless as variants on if conditionals, just as I like being able to use + as the syntax for a method name and while instead of complex procedures with GOTO statements.

    The point is not to memorize the entire Perl language (even Larry Wall hasn’t done that),

    You’re not helping your case. If even the author doesn’t know the entire language, how can we mortals expect to use it?

    I might agree, except that you seem to have missed the bit where the point is not to memorize the entire language. Perhaps you should go back to read the rest of my sentence, rather than take something out of context as an indictment of Perl.

    By way of analogy, consider English. Even as complex and inconsistent as it is, most people pretty much know how to use it by the time they’re eight years old.

    I “pretty much know how to use” Perl, too. I also know where to look up stuff I don’t know how to use yet, just as I know where to find an English language dictionary.

    since Perl is currently Perl 5, which is totally stagnant, I’d say the Perl (5) community is pretty resistant to change.

    . . . or maybe Perl 5 has the form it needs, for the most part, and only minor variations are being proposed. Really, I’ve never heard of anyone proposing major changes to the Perl language in recent years that didn’t consist of something equivalent to making Perl into Python. Would you be resistant to someone effectively suggesting that Python should be turned into Perl?

    When something reaches a certain point of maturity, you have two options, generally: don’t change it much for a while, or change everything. Perl seems to be doing both simultaneously.

    I have, unfortunately, encountered harsh reactions from nearly every large community I’ve looked into. Particularly on IRC

    I haven’t had that experience with the Ruby community at all, with one exception: there seems to be some kind of religious canon as regards how to explain Ruby’s :symbols, and daring to question it can get some pretty chilly responses. Specifically, if your explanation of symbols consists of anything more useful than “a symbol is just a name”, you’re Wrong. Anything else about the language (even in the IRC channel) seems to be fair game for discussion, even by way of comparison with other languages, as long as you don’t come in with some kind of “my language is better than your language” axe to grind.

    Furthermore, in the PerlMonks community (where all the wise old experts have been known to hang out, including Wall, Schwartz, Ovid, Phoenix, Christiansen, and others), I recently saw someone come in with a bizarre campaign to get Perl programmers to abandon the language in favor of PHP because the Evil O’Reilly Conspiracy was taking over the language and doing Bad Things to it. The reaction to this was initially very kind, I thought, and eventually reached a point where some of the reaction is still trying to be understanding and helpful, though of course a great many responding comments have been dismissive or even directly harsh.

    From my experience, the Ruby community is about as friendly as you can get, accepting of pretty much anyone and anything; the Perl community is very tolerant of different ways of doing things (TIMTOWTDI, after all), and always willing to offer advice though never willing to help spammers and people who want you to do their homework for them; the Python community has a Right Way, and woe betide those who have a different perspective, even when that different perspective is “I’d rather use Perl, thanks.” The best reaction I’ve ever seen from a group of Pythonistas to a desire to use Perl or Ruby instead is silence. The best reaction I’ve seen from a group of Rubyists to a desire to use Perl or Python is “It sounds like [Perl|Python] would be a better fit for you, all things considered. I also use [Perl|Python], and think it’s a great language.” Maybe I’ve just been lucky, though, in my encounters.

    Individuals in the Python community, when found alone, tend to be much nicer about things.

    Comment by apotheon — 24 March 2006 @ 05:24

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License