more cowbell
 
 


graciously hosted by neverblock
http://www.neverblock.com/

blog.josephhall.com


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.

7 Comments:

Anonymous matt harrison said...

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

8/29/2008 9:06 AM

 
Blogger Levi Pearson said...

Back many years ago, I had a programming problem that, in my mind, needed some nested data structures. I was a complete newbie to both perl and python, but I decided I'd give perl a shot first.

Since I was new, I didn't know how to navigate the perl documentation, and I never came across the stuff that explains how you do arrays of arrays and such, and doing what seemed obvious to me didn't work. So, I tossed perl aside and tried python.

Pretty much right away, I was able to figure out enough of the language to solve my problem. Nested data structures worked in the obvious way, and so I focused some more time in learning Python and found it to be a really fun language to work in.

I don't use it a whole lot anymore, but I have used it for a fairly important task at work. I wrote a program that parses a csv file that contains information about sensors, then generates C code that adds those sensors to an embedded sensor monitoring system. I'm sure Perl would have worked great for it too, and in fact my coworker wrote a similar code generator for a different subsystem in Perl.

When it comes down to it, when you learn them both, the differences are small enough such that it doesn't really matter which one you choose, but it's worth taking a bit of time to learn Python well enough to read it in case you ever need to get ideas from a Python program.

8/29/2008 9:38 AM

 
Blogger Joseph said...

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.

8/29/2008 9:51 AM

 
Blogger Matt said...

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?)

8/29/2008 10:21 AM

 
Blogger Joseph said...

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.

8/29/2008 10:32 AM

 
Blogger Janne Morén said...

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.

8/29/2008 9:16 PM

 
Blogger David Goodger said...

See Marko Samastur's blog post at http://markos.gaivo.net/blog/?p=126 . Excerpt:

A: I don’t like Python because of significant whitespace.
B: Do you indent your code?
A: Yes, of course.
B: And the problem is?

Python's designer (Guido van Rossum, who built on the design of Python's predecessor ABC) simply decided to take advantage of good practice. Python replaces explicit begin/end markers (braces, BEGIN/END, etc.) with indentation. They're just two different ways of conveying the same information. But you're going to indent anyway, right? (If not, why not?!?) So why the redundancy of both?

Python doesn't force any specific style of indentation; you can use any number of spaces (or tabs, but don't mix them up because that's ambiguous). Python only requires local consistency. The standard is 4 spaces per level, no tabs, but that's just a recommendation. Google uses 2 spaces to conserve horizontal space (their code is highly nested).

I could turn the argument around and ask why Perl (and C and ...) force explicit begin/end markers? Indentation is necessary in Python because begin/end markers were deemed unnecessary. It was a design choice.

All Turing-complete languages are essentially equivalent. Most mature languages have extensive libraries. In the end, it comes down to aesthetics, which is a highly personal choice.

(BTW, I'm an ex-Perler. Used Perl intensively for 3 years, on large projects. I hope never to have to read another Perl program again! I got burned out on the line noise, and Python was like a breath of fresh air. But that's me. (-: )

9/04/2008 9:25 AM

 

Post a Comment

<< Home