Hacker News Reader

Comment by hoodoof | Hacker News Reader

For me the essence of it is this:

Perl says "there's more than one way to do it"

Python, by contrast, says "There should be one-- and preferably only one --obvious way to do it."

The practical outcome of the Perl philosophy is that Perl code can be extremely varied to get the same thing done and therefore much harder for different programmers to understand and maintain. Python programmers are more likely to quickly understand the intent of a chunk of code regardless who the author is.

Perl at its worst can also be pretty arcane and I've heard it described as "executable line noise". That doesn't make for maintainability.

View on HN

This was the best thing about my move from Perl 5ish to Python. My colleagues were a mixed bag. Some knew Perl really well and wrote tight and efficient code. The rather baroque syntax and density of the language made it nigh unreadable but it worked well and they could be relied upon to maintain and refactor it. Most of my co-workers didn't know it that well and wrote crappy code using really horrible conventions that made the project a nightmare to maintain (e.g. a 5000 line script with a 3000 line function called "run", lack of local variables because no one properly understood scoping etc.). It was all I could do to keep my parts of the code clean.

I moved to Python for a later project (a custom CI system) and while there were people of varying skill working on it, the code looked the same because of the "only one way to do it" philosophy. Similar formatting, same idioms, readable code etc. This alone justified moving to Python for me. I could fix a problem in about a tenth of the time I needed to fix a similar bug in the perl codebase.

A huge part of this is due to the bad coding practices and relative inexperience of the programmers on the perl project. However, my feeling is that, perl is forgiving when it comes to style. It allows a skilled used to create really beautiful programs but pays the price by allowing terrible programs by bad programmers to run sufficiently well. We compared it to English. Very flexible, very forgiving when it comes to grammar and syntax if your intention is just to convey meaning.

Aside: what stops chumps from making 3000 line Python "run" functions?

(as far as I know, Python doesn't give you an error message when your function gets up to 66 lines, or whatever, long)

Nothing at all.

But, in my experience, because of the limitations on how flexible the language is, a 3000 line python function which is edited by multiple people is usually more readable than a 3000 line perl one.

Semantic whitespace makes it increasingly unwieldy to write huge python functions - you need to see where you're unindenting to, you can't just match parent.

Code review or linters. There's a few linters out there, and they're widely known in the community with loads of documentation/examples. I believe there's Perl::Critic, but I've never seen it used on the few Perl projects I've worked on.

(As an aside, you can make it more horrible because you don't even need a "run" function - just stuff it into the *.py file and it'll get executed :) )

Whatever reason it is, people don't do that often. They also don't write those often in Ruby, Java, C, and many other languages.

Maybe a better question is: what makes 3000 lines single-function code so prevalent in Perl?

There's something to say about Perl 5 making function arguments difficult. But I don't think it ends there, because other languages attract the same kind of code.

Luck of the draw. I have not seen the huge Perl funcs, only a few times in C (literally thousands of lines). But that's just the crowd I happen to have worked with.

YMMV, as they say.

I guess another way of seeing that would be "fewer chumps use Python" :-)

That is in the lama book (http://shop.oreilly.com/product/9780596001322.do).

> Yes, sometimes Perl looks like line noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line noise with a mission in life.

edit: formatting

I think this is one case where humility goes wrong. The Perl philosophy is to enable the end user ( the programmer ) to find his own way to solve problems. This has some advantages, like being able to pick up programming on one's own time. If you are self-taught, more often than not you will stumble upon some non-obvious way to do something. Perl enables you to get some task done. This gives you that positive feedback early on to encourage you to keep going.

This attitude is not very good in corporate environments where all code produced must be uniform so that new people can come and go and the software keeps churning out money.

Contrast this to Python which is a much more enterprise-y language, which is the reason for its success.

> Python, by contrast, says "There should be one-- and preferably only one --obvious way to do it."

you mean, like string interpolation? :)

Practicality beats purity

you mean, like print and print() ?

Reply on news.ycombinator.com