Friday, August 29, 2008

Perl vs Python

I've been trying to learn Python lately. Yesterday I attended Matt Harrison's "90% of the Python you need to know" at the Utah Open Source Conference. Unfortunately, he was expecting to have 90 minutes and he ended up having about 60, so he said he would be able to cover 55% of the Python you need to know. He still tried to fit in as much as possible, and as a result he went really, really fast. I started out taking notes and trying out his examples as he lectured, and eventually gave up, hoping that I could get access to his slides and a recording of his talk later.

Still, I did get a good feel for a few things in Python. By the time he hit classes I was totally lost, but I better understand things like whitespace, a few basic commands, and kind of the whole idea behind Python. In fact, it was summed up pretty well in a command in the Python shell:

jhall@bourdain ~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

Later on I was looking for something inside the man pages, and I found myself in the man page for Perl. The first paragraph of that file also sums up that language really well, I think:

Perl is a language optimized for scanning arbitrary text files,
extracting information from those text files, and printing reports
based on that information. It’s also a good language for many
system management tasks. The language is intended to be practical
(easy to use, efficient, complete) rather than beautiful (tiny,
elegant, minimal).

Granted, I'm not the best programmer in the world, and I certainly don't know enough Python just yet to make a lot of observations on the language itself (though I have made some). But based on what the users of those languages are trying to tell me, in addition to my own limited observations here's what I'm ending up with:

Python values form over function, while Perl values function over form.

I'm not saying (at the moment) that Python is a bad language. I'm just saying that it has a different focus than Perl. A lot of Python programmers have done a lot of really good work in their language, but I'm not sure I like the amount of energy they put into not just making their code look pretty, but also forcing users to make their code look pretty. Apparently forcing users doesn't work, however. I've also had more than one Python programmer (including Matt) tell me that they've seen some really bad Python code.

Pretty much anybody that's worked in Perl has also seen (and probably written) some really bad code. A lot of early Perl hackers seem to forget that readability does count, and that just because it's awesome that you can do so much with a single line of code doesn't mean you shouldn't break it out into 4 or 5 lines of code.

One thought that occured to me several times yesterday was an ice cream analogy. Perl and Python are two different brands of exactly the same flavor of ice cream. Probably not vanilla, neither language should ever be accused of that. Maybe rocky road or tin roof sundae. The point is, Perl feels to me like the ice cream that somebody would make at home, while Python feels more like the ice cream that one would buy at the store. There is some really bad homemade ice cream out there, but there's also some really good stuff. And homemade ice cream, unless you have access to things like commercial stabilizers like me, generally only has a few ingredients, and they all have words that we can pronounce. And the taste may vary wildly, depending on the cook. Python, at the moment, feels like that commercial ice cream that I guy at the grocery store because I don't have the time or inclination to do it myself. The flavor is consistent, to the point where it almost tastes chemically clean. Right now I don't understand all of the ingredients, but I know some people that do, and they assure me that they're perfectly safe, and good.

That's how I'm feeling about the languages right now. That's subject to change as I learn more Python. I don't know that I'll ever switch to writing Python for production use, but when I'm done hopefully I can intelligently consider it, and whether or not it's appropriate for the situation. We'll see how it goes.

5 comments:

  1. Joseph-

    Thanks for your comments. I apologize for the speed. I really feel bad if you gave up, because the talk was aimed at people like you who program in other languages. Did you get a handout (that has all the correct/working examples)? If not, they are on my blog. I will post slides on my blog. What confused you about classes? "self"? I'll try to post an update on my blog and finish the last 45%, but more feedback would be great.

    Re: spending time forcing your code to look pretty, that is really something I do in any language (perl/java/c/js/shell) (ie, indent consistently). Is that a bad practice or is there something else that is painful about it? (I'm not trying to flame here, I'm serious, because I'm at a loss to understand the comment).

    </end biting tongue to say anything about other languages.... ;)>

    ReplyDelete
  2. Matt: I'm not saying that pretty or readable code is a bad thing. I'm just saying that forcing people to do it doesn't work. Re: Classes. I think if I had time to sit down with the material and go at my own pace I might be okay. It was just too much at once is all.

    Levi: My primary goal with Python is to be able to read and understand it, like you said. I have a lot of fun with Perl, and at the moment I don't see a reason to write most of my code in anything else. By this point I think it comes down to a matter of what I'm comfortable in.

    ReplyDelete
  3. Why doesn't forcing people to indent consistently work? Thousands of python programmers might be considered proof that it does...

    (again I'm seriously wondering. what is bad about forced indentation?)

    ReplyDelete
  4. Matt: I'm not saying indentation is bad. I'm a big proponant of proper indendation in Perl. But thousands of Python programmers is only proof of popularity. Thousands of Python programmers all writing nothing but good code would be proof. My problem with forced indentation is that it should be unnecessary. Forcing people to do something like that seems to me as if the people in charge have decided that people will inherently write poor code unless forced to do otherwise.

    When it comes down to it though, spacing is not my biggest issue. I don't like it, but oh well. Fact is, I have a lot of fun with Perl, it does what I want, and I'm not ready to give that up for another language that seems to do the same thing, and feels uncomfortable to me.

    ReplyDelete
  5. I'm a (mostly) former Perl programmer that considered Python and gave up on it. I think it's a matter of self-selection to some degree: the kind of people who feel right at home with Perl will tend not to appreciate Python and vice versa. They originate from different perspectives on how things should be done and their design, culture and advocates reflect that. Not good or bad, just different.

    Ruby is a different thing again. It's a completely separate language of course, but its conceptual origins are fairly similar to Perl, which means a lot of Perl programmers tend to take to Ruby quite easily. A good number of people (me included) have found Ruby to be "Perl done right" in concept and culture.

    I kept having conceptual problems with using Python - not because I found anything bad with it; it just kept wanting me to do things different from how I want to do them - while I felt at home in Ruby right away. As I said, it's a cultural matter, not one of relative goodness.

    ReplyDelete

Comments for posts over 14 days are moderated

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