Hacker News Reader

Comment by jrockway | Hacker News Reader

Well, is Perl really a problem? Anything you can do in Python you can do in Perl just as easily; Perl actually has more abstractions available for the programmer than Python. (Grammars in regexes, real closures, coroutines, a metaobject system, etc.)

Also, last time I checked the programming language shootout, Perl 5.10 is slightly faster than Python 3.

So with that in mind, the logical "step up" from Perl would be something like Haskell. Python is pretty much Perl with different syntax, less features, and the impression that it's "cleaner" because nobody ever bothered using it for "quick and dirty" scripting.

View on HN

"Anything you can do in Python you can do in Perl just as easily"

I can't read my Perl code from six months ago like I can read my Python code ages ago.

There are far too many ways to do the same thing in Perl, not every one of them obvious. And I disagree with my past self a lot.

I'm always a bit puzzled by these claims of unreadable perl. Go find me perl I can't read: http://search.cpan.org/ . Where is it?

"I'm always a bit puzzled by these claims of unreadable perl."

unreadable for the claimants not for you.

"Go find me perl I can't read .. Where is it?"

Any language, no matter how obscure, will have some practitioners who can read any code written in it.

I am sure someone can say this about APL "What do you mean APL is unreadable? I can read any APL code fragment".

To repeat, they are saying they can't read it not that you can't. Don't take it personally. Use what works for you.

It's a totally bogus claim. The only people that can't read their own Perl after 6 months are the people that don't really know Perl. And by "know" I just mean they read and understood most of Programming Perl/Objected Oriented Perl.

Anyone who has studied those two books can understand 99%+ of the code on the CPAN.

A lot of people have made a few halfhearted attempts at using Perl and were so put off by the scary looking sigils that they gave up. Then they blame Perl to comfort themselves. It's not them that's too lazy to look past a new kind of syntax, it's the language's fault!

"The only people that can't read their own Perl after 6 months are the people that don't really know Perl."

again replace "perl" with "APL" or "BrainFuck" (or any language with baroque syntax) and the above sentence is as (in)valid. This comes close to the "No True Scotsman" fallacy. If you really knew perl you would have no problems with reading it. Sure, but that applies to anything, no matter how convoluted.

It doesn't matter whether you think their claims are "bogus" or not, or whether they meet your standards of "really" knowing perl.

Some people find that they can read their own code in other languages easier than their own code in perl after 6 months. You might think this "bogus", that doesn't matter. For them, that is a reality they have to deal with. And many deal with it by shifting to other languages and leaving perl to its aficionados. This is as it should be. Everyone should use the language they like and not use languages they dislike (irrespective of my or your stances on what they should like or whether their claimed reasons for dislike is "bogus").

Nobody is compelling you to abandon perl. So what's your problem with them not using perl?

A language is a UI for programmers. Some people find some UIs hard. Telling them that their discomfort is "bogus" is not very useful.

I use a lot of Haskell. Many people say they find its type system, monads etc "too hard". That isn't a "bogus claim". And "If they really knew Haskell they wouldn't find it hard" (where I define the "really knew") is a useless statement.

I use Haskell, they don't. Everyone is happy.

Live and let live. There are enough languages for all of us.

Perl requires that you learn a bit before you can be comfortable reading/writing it naturally. Like Japanese Katakana characters or the Cyrillic alphabet, a little investment goes a very long way. It's not nearly as alien as it appears at first glance.

Some people think Perl is a good deal more expressive and powerful for them. A whole lot more people would if they managed to get past their initial reaction.

Python probably owes most of its success to its simplistic syntax. That is definitely a feature when you're learning. When you're going to spend years with a tool though it's often worth investing some time into new concepts.

More people should probably learn Haskell if they want to be better programmers. I think more should learn Perl too.

"Perl requires that you learn a bit before you can be comfortable reading/writing it naturally. Like Japanese Katakana characters or the Cyrillic alphabet, a little investment goes a very long way. It's not nearly as alien as it appears at first glance."

This is, no doubt, true. But if people find that for a lesser investment (in say Python or Ruby) they can get all the (or almost all the) benefits of learning perl, it is natural they prefer those languages.

If a hypothetical English speaker were to be given the choice of learning French or Japanese and if he could get his work done with either language equally well (this is where programming languages differ from spoken languages) why is it a problem that someone chooses to learn French (an English speaker could be fluent in french in year or so, Japanese would take years) instead of Japanese? A Chinese speaker might prefer to learn Japanese vs French and that's fine too.

Focussing on perl specifically, unless I am maintaining a legacy codebase or I have a situation where libraries I need exist only in perl (and not, say in Python) why should I learn perl in preference to (say) Python?

I can imagine making a case for learning Haskell in preference to Python (or vice versa!) but perl Python and Ruby are largely equivalent in practice and at least to some people Python is easier to read than perl.

"Some people think Perl is a good deal more expressive and powerful for them. A whole lot more people would if they managed to get past their initial reaction."

I agree. The counterpoint is that there are equally powerful and expressive languages where I don't need to get past the initial reaction. To some people aesthetics matter. And aesthetics is subjective.

I don't really disagree that Ruby/Perl/Python are roughly in the same league of power. I do think some people may find that Perl is a good deal more productive/expressive/powerful for them. The Moose object system, CPAN, Catalyst, DBIx::Class. Perl has some amazingly awesome stuff going for it now and I think it's a shame that many people never discover that because of the stigma surrounding Perl's syntax.

It's tiresome seeing the same old superficial argument about Perl's sigils. I'd like to see more discussion about how much more powerful and advanced Perl's Moose object system is than Python's :-)

"I'd like to see more discussion about how much more powerful and advanced Perl's Moose object system is than Python's :-)"

:-) I agree this would be a fruitful line of discussion. I know next to nothing about Perl and while (as of now) I have no intention of learning Perl, it would be great if someone (you? :-D ) were to write (or submit) such a post to HN

"Some people think Perl is a good deal more expressive and powerful for them. A whole lot more people would if they managed to get past their initial reaction."

Don't shoot me, but I also observe a similar symptom with high-priced and/or hard-to-move-away-from "corporate" (as in "boring") products. The more your company invested in said product, the more successful the enterprise will show up on internal communications, with little or no correlation however badly it failed.

People get attached to their investments, be they money, time or self-esteem. Or, in the corporate case, the jobs of the people who signed the check.

As for Python, as a long time pythonista, I can tell you there are many steps to Python-zen, exactly like what happens with Perl (I did a lot of Perl between 95 and 2002). The simplistic syntax hides a lot of power that elude the newbie. When I review my early code, I see it as childish and crude.

If someone wants to learn new languages, I always advise them to learn something as different and "alien" from his/her comfort zone as possible. Haskell is a good choice, a Lisp like Clojure or Scheme is another. And by learn I mean taking a couple years as a side hobby to do increasingly difficult problems, perhaps some you already took with your comfortable-set. It _has_ to be an enlightening experience or it loses the purpose.

No language should require people to 'advocate' it to other people, a language should stand on its own merits, the free choices made by people that have those choices available to them are all that matters.

The more vocal the advocates the more the it feels as if the choice is no longer free, that will be reflected in a resistance to observe the language objectively, some of the feeling has already been spoiled by the abrasive attitude of the proponents. Erlang suffered quite a bit from that when people started spamming HN with Erlang articles to flood other items off the new page. It could be an excellent language, but in the eyes of some it is a language associated with anti-social behaviour.

If perl were easier to learn it would lose some of its power, so maybe it is not possible to have a language that fits the bill for everybody.

These trade-offs are to be expected and are in no way a detraction, that is why we have many different programming languages in the first place. One size does not fit all.

A language should stand on its own merits, but many of the practitioners of programming are not in a position to make an informed evaluation. They are happy if they can remember the difference between an object and a class. The difference between type systems, meta object protocols, syntax extension mechanisms, and so on are going to be lost on them. They don't care, and they don't care to care. (So it's not an issue of "I haven't learned that yet", it's "I never plan to learn more".)

With this in mind, some advocacy is necessary to steer the field in a direction that is pleasing to those that know more. The advocates are just trying to help these people get more out of programming than they are going to get from $simple_language (Java, PHP).

The problem, however, is that many of the advocates are advocating because they randomly picked programming language $foo, think it's good enough, and have never tried anything else. Their advocacy is designed to recruit other followers to justify their own decisions. And that is very silly.

It is especially amusing when this type of advocate attacks the first kind of advocate. The argument is always, "well, but my code works". "Erlang works for phone switches!" "PHP can talk to a MySQL database!" Well, OK, but are you positive those things couldn't be done better in a different language? (The answer is usually, "uh, well, no...", but I digress.)

That's a good point, plenty of advocacy seems to stem from 'it is what I use so therefore it must be good, if not the best'.

There seems to be an awful lot of that happening.

> The only people that can't read their own Perl after 6 months are the people that don't really know Perl. And by "know" I just mean they read and understood most of Programming Perl/Objected Oriented Perl.

Python taught me that there's no excuse for a language to have a learning curve like Perl's.

So no language should use any syntax/concepts that aren't familiar to someone who only knows Java/C?

No; no [programming] language should require two books and several months to be fluent in.

That's actually almost exactly the same thing as claiming that no language should be very different to everything else that has come before it.

I'm really not a Perl fan, but I really don't buy readability arguments. I'm a functional programmer, and the exact same feeble criticisms are leveled against ML and Haskell and Lisp and Scheme and whatever else. People say "ugh! It's so unreadable!", when they really mean "I can't read that having spent 2 days learning this new language, but I find it very easy to read C/PHP/Java/whatever, which I've been doing for several years".

It can take a very, very long time to actually become fluent in a programming language and paradigm to the point where you actually have a mental model of its semantics that is aligned with reality. This is why rookie programmers tend to get things wrong.

I spent almost 6 months learning Prolog. If I went and tried to write prolog now, I doubt I could remember very much at all. I've done C for more like 10 years, and I can still write C reliably despite not having touched it for 2 or 3 years.

So I don't buy it. I'm really not a Perl fan (nor a Python fan), but the idea that it's worse than python because it requires more intellectual effort to learn is bullshit, unless you're having a programming-for-people-of-limited-intelligence competition.

Scheme can indeed be learned in a day, if you understand the programming model.

And my standards for a programming language's learning curve applies to experienced programmers. It's just a happy coincidence that python offers a gentle learning curve for new programmers as well.

And wrestling alligators can be learned in five minutes if you already know how to wrestle crocodiles.

> if you understand the programming model

Right, learning the syntax of a programming is easy and quick, if you already understand the programming model.

I argue that it is difficult to learn new programming models in general.

> Right, learning the syntax of a programming is easy and quick, if you already understand the programming model.

Or at least, it should be. Hence my criticism of Perl.

> Any language, no matter how obscure, will have some practitioners who can read any code written in it.

So you haven't seen the Malbolge language, then? http://www.lscheffer.com/malbolge.shtml

While APL has its problems, baroque syntax is certainly not among them! You can write an APL parser on a napkin. With a felt-tip marker.

Python 3 smokes Perl.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

And most people are using 2.x which is even faster.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

> Python 3 smokes Perl.

Are those Perl programs written to use multiple cores?

> And most people are using 2.x which is even faster.

All the 1/1 and 1 make them seem pretty much the same.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

That is not "smoking", that is "pretty much the same".

If you want to see Python being smoked: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

That's winning at the special olympics. They are both so slow you'd never use either for cpu constrained tasks.

That is plain offensive. The special olympics are an even greater achievement of the human body as a machine, since it must push itself with far lesser degrees of freedom.

As I saw, it was not meant to be offensive. Special olympics are for special people. They are not the best among all competitors. Most interpreted languages are not comparable to compiled languages.

Neither Perl nor Python are interpreted. They are both just slow.

Why not? NumPy offloads all the heavy lifting to LAPACK and BLAS which is some of the most optimized code on the planet. Numeric work in Python is bread-and-butter for many people.

Agreed. I have a bunch of pretty CPU intensive stuff written in C that was optimized as much as I could, given the time I had to write the code.

I re-wrote the same code using python on a lark to see how bad it would be, colour me very surprised when it actually beat the original code by a considerable margin!

Perl has all these same libraries and more. We were talking about code in the actual language.

Perl itself is not the problem. According to my friend, the problem comes from available tools: the ones he needs already exist for python but not for perl.

As for quick and dirty scripting in python: I do it all the time. Hell I just made a little "framework" [1] in python to do this better. I missed the while <> construct from perl for doing filters, so I made it easier to do in python. The funny thing is, many of my quick and dirty python scripts end up looking like more thought was put into them, and being more flexible, than they were ever intended to be.

[1] http://pypi.python.org/pypi?name=pyCLiFF&version=0.1&...

Thats funny. I could say the same thing about the perl scripts I write. For that matter I could say the same thing The point is language and syntax for some of us at least has little bearing on how clear the code is. And like jrockway said perl is expressive enough that you can do far more abstraction in it. The only languages I've seen so far that can beat perl for expressive power are lisp and haskell.

As long as Python continues to not utilize multi-line lambdas. Then Perl and Ruby will continue to be a usable Lisp. But I don't think that's a bad thing. Python is Python and that's that.

> the ones he needs already exist for python but not for perl

Rather unlikely.

No really, hence the saying "only Perl can parse Perl". Despite its dynamic typing, Python is quite amenable to tool support because of its regularity.

"Perl with different syntax" is a prolix way of saying "better". ;)

Sometimes taking out features is more important than having them. Python fans usually like it because every feature is exceptionally well-thought-out, not because there are a lot of features.

I have never heard anyone refer to Python's lambdas as "exceptionally well-thought-out" before.

Python, like any programming language, is not perfect. There's simply less to not be perfect.

Agreed not everything in Python is well thought out. Lambdas and .join comes to mind.

Reply on news.ycombinator.com