Perl: Love it, or hate it, but don't ignore it | Hacker News Reader

Perl: Love it, or hate it, but don't ignore it

blog.newint.org

72 pointsfogus101 comments

The phrase "love me, or hate me, but don't ignore me" is a serious marketing mistake, in any context. It's a transparently selfish cry for attention. Rather than offering something great to the audience, you're trying to win pity points by subtly accusing them of poor judgement: You should be paying attention to X, but you aren't!

Believe me, if people wanted to pay attention to your project, they would find a way to do so. And if your project is being politely but firmly ignored, and you're not getting the message, it is not the audience's problem. They've responded to your message. That response is somehow not getting through to you.

Perl needs no more criticism. Even the criticism of Perl is old news. Yegge's essay, cited elsewhere on this thread, is five years old. I suspect he has little to add to it, and neither do I. I'm glad Perl's users are happy and productive, I was really grateful for it ten years ago, and I have seen nothing that makes me regret my decision to stop using it.

Actually guilt works as a marketing device, but only for the short term. Guilt marketing might force someone to buy a particular brand, but it doesn't change one's attitudes toward the brand overall.

http://www.sciencedirect.com/science/article/B6V7S-45K1JKH-B... (Abstract, article behind pay-wall.)

The phrase "love me, or hate me, but don't ignore me" is a serious marketing mistake, in any context.

OK, but don't think that one blog is the voice of the Perl community. One blog shows the opinion of one blogger; nothing more. Amazingly, "the Perl community" does not have one single voice, as it consists of tens of thousands of people all over the world.

(Also, if blog noise was a good measure of langauge popularity, it would be clear that the most popular programming language right now is Go.)

One thing I've learned from social news sites is that this is not correct. People mostly want to find ways to justify their insecurities. If they don't know very much about programming, but pick language X, they will hang around people that like language X and that say good things about language X. Then they feel smart by association, and since they have lots of friends saying lots of good things about language X, they can feel good for "making the right decision". Being down on language Y and language Z also help reinforce that feeling. If language X is unpopular, then they're clearly in the so-much-smarter-than-everyone-else majority. If language X is popular, then it's clear that it's the best. If it weren't good, why would it have so many users?

And so on.

These are not technical arguments, they are just emotion. Confusing them with technical arguments is quite silly.

Yegge's essay, cited elsewhere on this thread, is five years old. I suspect he has little to add to it, and neither do I.

It's worth noting that Perl has changed significantly in five years. All of that criticism has resulted in many major changes in how people use Perl, such that the criticism is probably no longer valid.

But of course, people like to recycle that criticism because They Picked Something Else, and drunken rants from five years ago make them believe that Something Else is the right choice.

(I am not sure how valid it was five years ago, actually. It was more a criticism of Amazon's hiring practices, or perhaps a note about how poorly managed the programmers were. I would love to write an essay about how bad Python is, because I have seen some absolutely horrible Python code... but I realize that it's bad because it was written by someone who didn't know how to program, not because Python is intrinsically bad.)

Have a look at MooseX::Declare and MooseX::MultiMethod then - the ability to add syntax to the language combined with a stunningly flexible, extensible metaprotocol is a huge win.

About the only object system I can pull similarly beautiful tricks in is CLOS. python and ruby don't even come close.

Oh, and before somebody yells "but but it's a library", that's a good thing - it means the syntax and semantics can be changed without needing to produce a new incompatible interpreter version. Ruby 1.9 and Python 3 have both run into adoptions problems because of compatibility issues, whereas the Perl5 language v10 (and soon v12) don't/won't have nearly the same adoption problems because we focus on enabling libraries to improve the language rather than on baking in additional features.

Not that there aren't advantages to shoving things into the compiler and VM directly, but I'm not sure I believe that in this case they outweigh the advantages of keeping things as libraries.

Please stop using Perl.

Perl has been my startups' secret weapon, and I'd rather the competition didn't know about it. Perl let us deal with large volumes of data, at high throughput (there are several ISPs, Universities, and fortune 500 which use our product to protect their mail infrastructure from DDoS and Spam). At a former company it let us collect, parse, store, audit, and make predictions against millions of web hits per day, in close to real time, with cheap infrastructure. Perl has been solidly stable - it just runs - keeping our ecommerce infrastructure making money.

It has had few security issues over the years. It has had few backwards incompatibilities between versions over the years. As a component of our products, it's given me relatively little pain in performance, reliability and security. Development wise, I can't count the amount of time we've saved over the years thanks to not having to reimplement something because it's on CPAN, with a sensible license, with doumentation, tests, and in an easy to find and search location. As for code quality, Perl has great support for testing, support for automating code review (Perl::Critic), and a community of developers that are constantly making things better - but without breaking things that worked in the past (Moose has done amazing things for refactoring ugly OOP code, and you can use it with any of the other older OOP stuff).

I use it because it works well, seldom breaks, and causes me less hassle than anything else I've tried (C, Java, Python, PHP, Ruby). I've spent serious time with this language; I've maintained ugly old code from 10 years ago, and giant million++ line projects written in it. It has warts, sure, but what doesn't? I don't care; it's reliable. Big jobs, little jobs - it gets the job done. And that, to me, is more important than high minded ideals about aesthetics and purity.

Almost all Wall Street firms code in Perl including my favorite http://www.moneybookers.com/app/

Is that Wall Street on the Thames?

Registered in England and Wales under Company No 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH.

Sorry for my bad English. I meant

    Wall Street Firms + http://www.moneybookers.com/ (my favorite payment processing vendor)

Strangely, the investment bank I used to work at relied heavily on Perl, without most people even realising it. A huge volume of live rates information formed the basis for a large number of Seriously Enterprise Applications, all with architecture groups and best practice gurus and all that stuff. What was ironic was how the rates got into the bank: six instances of a single Perl script that almost noone knew about, connected to the Reuters Market Data System. And the reason that it was so poorly known was simple: it was cronned to start and stop at particular times during the day, and in the four years that I was there, it went down once, when the box it was on suffered a hardware failure.

Funnily enough, a few more people knew about it after that, whereupon I got funding and contingency hardware thrown at me until I could confidently tell the powers that be that a box failure would be followed up by immediate failover and a whole bunch of alerts being generated.

Overall, I think that's where Perl does a really good job: in holding stuff together. While the Rubyists and Pythonistas are arguing over who's got the better language, Perl hackers are just getting stuff done.

This thread gives me serious deja vu. It seems like every time someone says they like Perl, the exact same arguments usually show up in duplicate. Someone posts Yegge's "I hate Perl" article. Three or four clever souls post something like, "I ditched Perl 100 years ago and never looked back". Then chromatic comes along and says something not-negative about Perl, and someone else asks him for conclusive proof.

Anyway, I can't find words intense enough to describe how I am feeling right now, but it seriously disturbs me. It feels like the Universe is recursing on itself, and I am in two of the Universes at the same time. I had to check the date on the comment three times before I believed that it was real. Then I had to do some tests to make sure I was not dreaming. I can't breathe under water right now, so I figure I must be awake. But I can't believe it. This. Again.

I agree that a lot of Perl bashing is thoughtless. And ideology when it comes to programming languages is just stupid.

I'm sure there are plenty of cases where Perl is the best tool for the job. I know it's very good for large quantities of string parsing, for one.

You seem to know a thing or three about Perl- do you have advice on other cases where it's the best tool to use? I think that might be the most effective form of countering the arguments you dislike, and it would be very practically useful too.

mod_perl2 is really difficult to beat if you need to dig into the guts of Apache. DBIx::Class is a huge win if you need/want an ORM but you've been given a really weird pre-existing DB schema. POE has been around forever, and makes really stable long running daemons that don't have to be babied. CPAN has stupid amount of tools for automating sysadmin tasks, all of which you'll probably end up using once, putting in a cronjob somewhere and forgetting about because it will just work. Any time you need to deal with something old, or weird, or both there's probably a CPAN module for that, you can find it via search, and it probably has tests and docs. Template Toolkit for creating uglyass text is both nice to use and full featured (if you don't want to go down the XSLT hole). I've also found that Perl handles I18N, unicode and uglier things (like shift-jis) fairly well. Almost every payment processor has a module, and they all have a standard(ish) API, so they're mostly interchangeable. Likewise crypto stuff is fairly standardized and pretty complete. In general, if you have to tie something to something else that's weird, Perl is a good bet (because someone has probably done it, put it on CPAN, and documented it).

That's a few of the problems I think it stands out as a great tool for.

mod_perl2 is a brilliant tool for writing apache modules.

Catalyst is a far better web framework. So's HTTP::Engine.

And with the PSGI standard and Plack reference implementation, the lighter weight stuff is starting to standardise too - my new toy, Web::Simple, leverages Plack to provide Catalyst::Engine-like functionality but in a very lightweight manner and very shareable between different frameworks with different philosophies.

I remember showing DBIx::Class to Simon Willison at a LugRadio Live - he looked at some of the complex queries chained resultsets and easily build and his jaw dropped. We were going to try and get round to me helping him fix Django's ORM to have more of the capabilities of DBIx::Class in return for him helping me build a django-admin-interface-like piece of code for Catalyst but we never quite got to it, sadly. Happily, our respective communities seem to have already done similar things without us :)

I Absolutely agree with regards to web frameworks. But there's a time and a place for apache modules, and mod_perl is definitely the tool for that job.

I think I have too much to say about this for a HN comment, but I will try to condense.

Perl is okay for parsers; but I think other languages have better parsing libraries and other languages run faster. I tend to prefer Haskell these days. It runs quickly, it has good libraries, and it's easy to get it right. (Most of the stuff I have been paid to write is Perl, though. It does get the job done, and it's certainly easier to get right than C or C++.)

Where I think Perl is really really great, though, is for building large applications. Applications are often a lot of pieces that need to be glued together, and this is were being a "glue language" really shines. The "language", of course, is CPAN. There is a library that gives you a good abstraction over almost any task you would ever need to perform.

If you are writing a large application, you don't want to have to implement boring things like HTTP header parsers or HTML templating engines. You want to write your application. Perl lets you do this to whatever extent you like; you can have libraries that make all the choices for you, or you can write everything yourself. (Most people choose some combination of this.) The language itself is fine for this, and the libraries support it. (One time, I wrote a web application without a web framework -- but I used many parts of other web frameworks from the CPAN. So even though I was writing something fairly obvious from scratch; I could still use libraries for the parts I didn't really care about doing My Way.)

I know people are going to say, "well, my language has a library for xxx", but they are kind of missing the point. CPAN has really good libraries for popular tasks, and At Least Has Something for relatively unpopular tasks. But it also has libraries for things other than "tasks"; you can change Perl itself with libraries, and there are libraries for very small programming problems. (Things that you probably wouldn't think you need a library for, like finding the largest element of a list.)

It is just hard to explain this to people that haven't used Perl. They think the only library they will ever need is Ruby on Rails, but there is so much more to library use than huge frameworks.

Anyway...

Perl also makes metaprogramming very easy. This means I can quickly implement some abstraction that's higher-level than "raw Perl", and then implement my application in terms of that abstraction. This makes the application code easier to read and understand, and it makes the application easier to write. As I hinted at above, there are a lot of libraries for this; so metaprogramming isn't some magical thing that only wizards can do -- it's something accessible to every user of the language that can imagine an abstraction.

My blog is currently dead (due to my general disinterest in system administration)... but I wrote a long article a few weeks ago about the sorts of abstractions that the Moose object system lets you build. If you care to read it, I think it's still on the planet.perl.org main page. Search for my name :)

I have to vote this blog post up so I have a reference back. :-)

I love CGI, DBI. I can write my own SQL. I don't need an ORM. What modules do you suggest for developing web apps using Perl. Mason or Template Tool kit or something else.

My general rule of thumb is:

Perl5+MooseX::Declare+lots of CPAN for general purpose programming (web apps, network daemons, automation code)

Old school scripting style Perl5 for when shell gets clumsy

Shell for simple scripting

C for bit twiddling either due to hardware level madness or for performance

whichever lisp REPL I have handy for reasoning about high level logic

I don't write GUI apps so I have absolutely no idea what I'd use for that if I did. Probably ObjC on OS X and Perl5 for cross platform (easier to learn Wxperl than to do without CPAN when I'm not aiming for mac-quality polish, I suspect, though that could easily be familiarity bias on my part).

And ... that doesn't really say what Perl5 is best for - it says what I choose to use it for - my general purpose mid range programming language in one configuration, and my primary scripting tool in another.

I actually quite like python (and I hear wonderful things about their wx libs so I'd definitely look before starting on a GUI app) but I like being able to extend my language up towards the problem lisp-style and it doesn't want to let me do that to the same extent as Perl5.

I don't mind ruby but their decision to inflict the single-inheritance smalltalk object model on me rather than the more flexible approached both Perl5 and python allow leads me to discount it for any project where I know I'm going to be heavily object oriented - if I wanted bondage and discipline in my OO I'd be looking at statically typed languages instead.

I'm not sure any of the above really answers your question, but hopefully it explains to you why I don't have a better answer at least :)

Your life moves forward one second at a time. And if a project is part of your life -- if you visit it every day, and follow it closely -- it also moves one second at a time.

But to the general public, the apparent flow of project time is defined by its managers. Time is measured in milestones. Major book releases. Major new adopters of the project. Major upgrades. If you want time to move forward, you need to clearly define and communicate your milestones, to give the community something to rally around and synchronize on, to provide news hooks and talking points and historical points of reference. If your project has fuzzy milestones, it will feel stuck in time.

It's storytelling. People don't want stories to move in real time. They want plot points. Time moves nonlinearly in a story. Nobody has the time to actually live through every single minute of somebody else's life.

This is why companies issue press releases, novelists and filmmakers put out sequels (a sequel helps sell more copies of the original), and software publishers keep releasing upgrades (each upgrade bumps up sales, if only because it gives news agencies and potential customers a reason to check out the product again.)

If Perl feels like it's stuck in time, it's because the community stopped time nearly a decade ago. They blocked future major releases of Perl 5 by assigning the name "Perl 6" to something else, a move that makes the invention of New Coke look like marketing genius, and which perhaps explains why -- although Perl 5 is said to "be much better than it was five years ago" -- none of the featured books on books.perl.org are much less than five years old, and many of them are nine or ten. New ideas are sold by new books, and new books are sold by version upgrades. Just ask the Pragmatic Programmers, who will presumably come out with the fourth edition of Agile Web Development with Rails in five years when Rails 3 ships. If Rails 3 doesn't ship, nobody will bother to revise the books, because the revisions won't sell well -- not as well as they will when they are coordinated with the news push around Rails 3.

Anywa, back to Perl. Perl 6 was announced in 2000. Then it didn't ship. Then it didn't ship some more. And now it looks as if the whole idea of shipping Perl 6 on a specific date is being deprecated:

http://darkeside.blogspot.com/2009/08/perl-6-gets-release-da...

Big news from the current Perl conference YAPC Europe 2009 here in Lisbon is that Rakudo (star) will be released in spring 2010. Rakudo is Perl 6 on Parrot, which is an equivalent to the JVM or CLI.

Is that an official Perl 6 release? Well, it is the nearest to official that you will see. The Perl 6 team are keen to point out that there will be no such thing as a official version, just different implementations

So perhaps Perl 6 will never officially begin, just as the Perl 5 described by the Camel Book (last revised nine years ago) will never officially end. And so I fear it will be deja vu all over again.

>>If Perl feels like it's stuck in time, it's because the community stopped time nearly a decade ago.

Uh... jrockway, chromatic mst etc have listed cool new developments over just the last few years.

Are you doing language wars, or can you motivate why all that is wrong?

>>looks as if the whole idea of shipping Perl 6 on a specific date is being deprecated

What you quote says (afaik) -- Perl6 has a specification, so there will be multiple implementations. None will be the "official" one. That is a feature.

I'm sorry, but you seem to not know what you're talking about? Have I been trolled?

Edit: "A decade"? That was even before testing took over the Perl world, iirc... Damn, I must have been trolled. (Fixed simple grammar, made a sentence clearer.)

I loved perl for a long time before I started using python and, quite frankly, I don't intend nor see the need for ever having to use perl again. I respect perl for what it is and what it has enabled me to do, but when better tools come along I don't hesitate to move on.

Perl6 would make you love Perl for being a better tool again ^_^

It has all the features python has over Perl5, except for the syntactical whitespace strictness. And that's totally subjective.

Python has a killer feature by comparison, actually. It has a living, widely used implementation.

Which one, Python 2.x, or Python 3000?

And several faster but less-complete implementations; PyPy, Unladen Swallow, Psyco, etc.

Wow, just like Perl 6.

So does Perl5. And with a little help from CPAN, the same feature set. In fact, I'd argue that the Moose metaprotocol is substantially more powerful than the one available in python - though if there's a python library that provides the same sort of level of capabilities, I'd love to hear about it - maybe we can steal some good ideas from them :)

Moose is far more powerful than Python's model.

Python seems to think it knows what's best for the programmer.

Perl tends to think the programmer knows what's best for it.

AFAIK there are no packages for Python yet that implement roles, multi-methods, and the like... yet.

But Perl is already ahead of the curve in this arena.

(I'm one of the rare few apparently who can speak Python and Perl fluently. I actually like both languages for entirely different reasons.)

Forgive my cynicism but when exactly is Perl 6 coming out? Python 3 is already out and it was a concerted effort to clean the things that began to pollute the language. Perl 6 is supposedly doing the same thing...but the need to throw everything out makes its delivery rather questionable...I think our sun may become a red giant before Perl 6 shows up.

I'm a Perl5 programmer so I don't really care (though the Rakudo implementation of Perl6 should be at least worth a test drive sometime next year from what I hear from the other camp).

v12 of the runtime for -my- language of choice should be out in the next couple of months, complete with pluggable keyword support blessed in core and a whole bunch of other goodies. And Perl5 is being cleaned up over time - strict and warnings going on by default if you ask for a new enough version of the VM, old and weird misfeatures going through deprecation cycles, etc.

Perl5 and Perl6 are two different languages from the same family, not a "next version" and "previous version" like python is - the confusing naming is a historical accident from before Larry turned Perl5 over to its community and we got the chance to pick up development again.

> ... when exactly is Perl 6 coming out?

Rakudo releases a new version on third Thursday of every month, as it has since December 2007.

Which does not mean it's complete in any way - they simply release what they've got at that point: http://rakudo.org/status

"Common things that are known to have problems or not work in Rakudo (As of 2009-02-28.)" list contains "variables in regexes". It doesn't really matter how often they release in that case...

That's "as of february this year" and still open in november.

> Which does not mean it's complete in any way....

No one claimed otherwise. Perl 5 is 15 years old and still not "complete".

This thread was about Perl5.

Perl6 is a separate language in the same family and not relevant to this conversation.

Of course, Perl5 now has most of the interesting features of Perl6 anyway, given things like MooseX::Declare - to the point where we're currently helping the Perl6 community steal things back from Perl5 based on our experience using the additional capabilities in production (i.e. "thanks Perl6 for letting us steal stuff, here's how it works out in the real world" - the Open Source way :)

Python is better than Perl because it runs slower, and has fewer features and third-party libraries?

Python produces more readable code, in my opinion, mostly because the sigils in Perl are too easy to get wrong. Also, the lack of some language features factors into this, too.

Speed-wise they seem to be pretty much a toss-up, at least for these benchmarks: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Admittedly I have much more experience with Python than Perl, which certainly factors into my "readability" assessment. But, thinking back, I definitely felt a lot happier about the first Python script I wrote vs. my first one in Perl.

Agreed on the 3rd-party libraries. Perl's pretty hard to beat there- although I don't think there's a Perl equivalent to scipy/numpy, is there?

Programmers produce code, not languages.

I think Python makes it hard to write readable code, because it forces unnatural constraints around your programming. If you want a two-line anonymous function; too bad -- you have to give it a name. If you think a closure would make more sense than a named class with named fields; too bad -- that's not supported.

With Python, you get a lot of code that looks the same. And that's good when the code that looks the same does the same thing. But if it's doing something different, you might miss the difference if all the code looks the same.

(The argument against TMTOWTDI is that similar things will look different, and that's bad. But the problem is that different things will look similar too, and that's also bad. It's simply a Property Of The Universe that There Is More Than One Way To Do It, and pretending that there's not is a fool's errand.)

My impression from using a little Python recently is that it could nicely be replaced by JavaScript. Both seem to have a similar amount of convenience syntax (just in different areas), but JS is more flexible.

> I don't think there's a Perl equivalent to scipy/numpy, is there?

There's PDL. Whether you prefer the Python equivalent to the Perl equivalent seems (to me, at least) to depend on what you think of Fortran.

I'd pay more attention to those frameworks if you'd say why they're interesting. I consider python/ruby/perl to be sibling languages. You only really need to know one as your primary language and then steal ideas from the other two. Node is interesting because it solves a problem: efficient long polling setup in a language I know.

Why Ruby over Perl then? The ruby peoples have great taste in designing mini languages: e.g. sass is amazing in a why-couldn't-I-think-of-that way so I pay attention to them. The best thing I know of coming out of the Perl community is the people (Michael Bayer is my hacking hero for SQLAlchemy).

SQLAlchemy's nice - wherever DBIx::Class and SQLAlchemy developers are gathered at the same conference, there will be beer, and there will probably be cursing other ORMs for not understanding what a database in. Later in the night, somebody will say "we should all use ActiveRecord instead - because it unlocks all the power of MyISAM on MySQL 3.23" and then we'll giggle incoherently for a few minutes before getting another round of drinks in.

SASS is absolutely beautiful. I think Perl5 with Devel::Declare is a better internal DSL host than ruby though - consider MooseX::Declare - you simply can't bend the ruby compiler sufficiently to do something like that to my knowledge (or Piers Cawley and others wouldn't have moved from ruby back to Perl5, I don't think ...)

Just adding another data point: Steve Yegge's essay [http://steve.yegge.googlepages.com/ancient-languages-perl] scared me off trying Perl.

Heh. Some other fun "anti-Perl" stuff: [the Python xkcd comic](http://xkcd.com/353/) and the [ESR rant](http://www.python.org/about/success/esr/).

That said, another satisfied Perl user here. :)

That's a real pity. I like Steve, but his essay demonstrates a severe lack of understanding of at least two fundamental features of Perl, namely context and lists.

Don't let others tell you what is good or not, find it out yourself.

If you have evidence that it's lack of understanding, rather than lack of liking (coupled with a snarky, hyperbolic style), perhaps you'd care to present it?

Here's a simple one: parentheses never create rvalue lists in Perl 5. They only perform expression grouping.

But that's exactly what he's complaining about: it simply doesn't make sense that you have to use parentheses, or crazy q// construct to create a list. At the same time they don't really "create a list", because it's flattened again. It requires remembering rules again, just like with the contexts. It just doesn't "make sense".

> ... it simply doesn't make sense...

It does if you bother to learn the language, rather than assuming that it's a pastiche of whatever features you bothered to osmose from a smörgåsbord of whichever other languages you might have encountered.

> It just doesn't "make sense".

The notion that a programming language both can and should be completely intuitive to novices who don't have to bother to learn an arbitrary list of syntax rules is absurd on its face.

Parentheses never create first-class lists in Perl. They only ever group expressions and disambiguate precedence.

Parentheses sometimes create first-class lists in Python and Ruby, for example. They also sometimes group expressions and disambiguate precedence. If you want an arbitrary set of rules to memorize, look at the languages which conflate various and orthogonal uses of the same punctuation character.

"Parentheses sometimes create first-class lists in Python"

No, they never do. (don't know about ruby) Square brackets are for that. No problems with syntax this way.

"They also sometimes group expressions and disambiguate precedence"

But it's obvious: "expr ( [expr ,]* expr)" is a call - always. "(expr)" is for precedence. "([expr,]+)" is a tuple. Same as in 99% (made up number) of languages you encounter.

OTOH, in Perl, you've got the same expression that creates a list in one case, but not in the other, which is simply confusing. To be honest, I don't know of any other language that does it. You can call my expectations to be appropriate for a pastiche of whatever other language - yes - all the other languages I know / heard of, work the way I expected... and don't force me to learn rules that work based on context. Similarity between languages is a "good thing".

If you like that syntax, good for you. But I fully understand people who'd rather not be surprised this way. To me it doesn't make sense to be that different. I think Steve Yegge knew exactly what () do when he was writing his blog - he was simply complaining about that unexpected behaviour.

Your "obvious" rules are as arbitrary as those of any other language.

What is the difference between a tuple and a list that's "obvious" to a novice programmer? (Yes, you may claim that I change my argument to talk about lists versus tuples, but if you want to press on this line of thinking, Python's syntax for list and list-of-list declaration is the same as Perl's syntax for anonymous array declaration.)

Which parts of the requirement for a trailing comma after the first element of a single-element tuple are "obvious" to a novice programmer?

Which of those "obvious" rules are obvious cognates with other programming languages?

(What's "obvious" about Smalltalk having a strict left-to-right evaluation order, ignoring "obvious" mathematical precedence rules which schoolchildren learn?)

> ... in Perl, you've got the same expression that creates a list in one case, but not in the other...

This is still not true. The comma operator creates lists in Perl.

His complaint about this part shows his cluelessness: @x = (1, 2, 3, (4, 5));

A serious perl developer would write this like: my $x = [ 1, 2, 3, [ 4, 5 ] ];

That right-side expression looks very much like how a serious Python developer would create a list of lists. Hm.

Not entirely sure what you're saying, but i touched python only once in my life and didn't like it a lot. :) (Still completed the task though.)

I'm merely pointing out that an honest complaint about the Perl syntax for creating nested arrays applies equally well to Python.

Where did Yegge claim that parentheses create rvalue lists?

Other commenters here seem to think you're referring to his complaint about (1,2,3,(4,5)) equalling (1,2,3,4,5), but I don't see how that complaint has anything to do with whether parens create lists. Rather, he's complaining that the comma operator is append instead of cons, kinda.

Note also that here he's talking about a bad decision made "very early on", back when Perl had no references; at that point the only way to make anything like nested lists was by giving names to all the sublists and using typeglobs or explicit calls to eval. That's a semantic point and has nothing to do with the syntactic role of parentheses in the grammar. Yes, nowadays you write [1,2,3,[4,5]] instead and make references everywhere, and that's better, but it's still not very nice because Perl references are ugly, and what Yegge's doing here is explaining how Perl came to need something so ugly.

And what pointers are.

That's OK though. What I really love about the Internet is that Perl sucks because it has pointers, but Haskell sucks because it doesn't. It's almost like people throw around the word "sucks" without actually understanding the concepts that they are discussing.

"Thinking is hard! Let's go whining!"

Which would be the same Steve Yegge who also said:

'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'

So if his essay on the state of the art in Perl5 years ago scared you off, presumably the fact he's now noticed that we're (a) moving forwards (b) a happy, pragmatic and effective community will make you go look at it now?

There's even a new www.perl.org recently released (next big project - improving learn. ...)

"Supposedly Perl Web searches are on the rise"

Fact check:

http://www.google.com/trends?q=perl&ctab=0&geo=all&#...

Perl has been losing ground, while Python and PHP gain ground, for almost ten years:

http://www.ohloh.net/languages/compare?commit=Update&l0=...

If you do Google Trends searches for "perl programming", "ruby programming", "python programming", and "php programming"; you'll notice that they all show a downwards trend.

So I think there is something deeper here than "everyone is moving away from Perl".

i see what's stealing their thunder... http://www.google.com/trends?q=perl+programming%2Cpython+pro...

Ohloh is a ... very web 2.0-y thing. Which means a lot of perl projects don't get registered, since we're not as whole an amazingly "woo! random social stuff! must register now!" community. I tried to redress the balance, discovered Ohloh's indexer had a bug that threw away half the history of my projects and thereby made them look much less actively developed, reported it twice, got ignored, and gave up.

Plus Perl5 generates a lot more search.cpan.org searches than google searches during normal use - we don't generally hit google very much because it doesn't have the information we need. So I could argue that CPAN's been getting better and Python and PHP have continued to fail at having an equivalent. And I'd be making just as much of an unfounded guess as both you and the article attuhor are by guessing web search volumes matter.

Of course, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... shows Perl5 and python and ruby all losing ground, but the other two significantly faster. I'm sure if I tried I could find you plenty more statistics that look good for Perl5 but don't really prove anything :)

You'll find a much better metric here: http://www.indeed.com/jobtrends?q=perl%2C+python%2C+php%2C+r...

Absolute number of jobs for each language.

I avoided Perl up until about six weeks ago, when one of the best coders I know selected it for something we're working on. If it was anyone else I would have overruled the choice, but it turns out he was right.

It's an unmitigated disaster of a language, as a whole, but if your needs are a "scaffolding language" that can script something together quickly and you're using a lot of regex, I have to admit, it's a great choice.

It's an unmitigated disaster if you use it wrong - or at least if you use out of date techniques.

This is also true of C - consider things like scanf and other chunks of stdio that are preserved for compatibility but no developer in his right mind would use for new code.

Applications Perl5 written using MooseX::Declare and friends (see Task::Kensho for a good start at "and friends") is a much different thing to the high speed line noise-ish scripting perl that was the commonest sort a decade ago.

An informative comment from a really knowledgeable guy downvoted.

The comment in question was polite to a newbie flame without supporting data. The flame was upvoted... like a large number of flames without arguments/motivations.

I feel sad for HN.

OTOH, some language communities are hilariously pathetic in their fanboyism... :-)

Any language that needs advocacy has already lost. Good languages are adopted by people because they solve problems better than other languages. It is a market place of sorts. As soon as you feel the need to advocate a language you are actually advocating what you use, instead of letting the language speak for itself.

The net effect of all this advocacy is possibly even negative, the more you try to ram a programming language down peoples throats the less inclined they are to give it a shot because they already have a negative experience before even trying it.

Languages with an open and welcoming, real-world problem solving oriented community tend to benefit from the people using it and talking about using it. Those that simply hawk a language as 'great' and keep on hammering on its strong points are missing the point here.

One of the reasons perl lost out not only to python but even to PHP is because it has a stigma attached to it of being (very) hard to maintain.

That may be more of a reflection on perl programmers than on perl though.

This is a bit unfair, most programming languages do get their share of advocacy.

I would agree if you say that Perl is getting the bad type of advocacy, or that those who are advocating Perl are not doing a good job!

Ruby get a lot of "good" advocacy, which sound like ... "Hey I did X in Ruby, Ruby is awesome, Ruby is teh SHIZNET!"

Python normally get this type of advocacy, "...hey look how you can do the same X in Python, but now its better"

Perl's advocacy, sounds like "...Perl is not dead!", which I agree sound like a scary statement to make!

But anyway, all languages get some sort of advocacy! Perl is actually late in the advocacy game, I guess this is why it so far gets the worst kind.

> Languages with an open and welcoming, real-world problem solving oriented community....

I think the CPAN applies very well here. Did you know that the CPAN Testers service records a million test results every three months?

The best advocacy is using the language. Someone pointed out earlier about the lack of a CPAN equivalent for other languages - CPAN is the best perl advocacy around. The biggest improvement in perl advocacy would simply be to let others know how much it is used, and why.

I just discovered that a Perl script has made it possible to view 44 channels of live British television. Incredible. http://www.myp2pforum.eu/live-tv/41045-british-tv.html

And a host of Perl makes it possible for the BBC to serve up its iPlayer content. Some of it is even modern MooseX::Declare based Perl.

Frankly, I found Simon Wilson’s response to my post more enlightening than most of this entire thread: http://simonwillison.net/2009/Nov/27/perl/

One thing I would like to know: why hasn't anyone else duplicated CPAN?

I don't know Perl, but I've had to pull things from CPAN to make a Perl script work and I was impressed.

At the moment I'm running parallel Python code on many different machines and it's a pain to make to sure that all the right packages are installed. I'm sure that something like CPAN would have helped.

CPAN is a community project, I doubt that anyone could create an equivalent for another language, it would almost certainly have to be grown as the original was.

Well... there's CTAN.

Oh, hang on, that came first didn't it? Forget I said anything.

I'm a non-perl guy working in a very Perl heavy company, so hatred of it is quite well justified, and based on discussions with many of my coworkers, it seems the Perl community doesn't want to understand why the rest of the world has moved on and has no interest in Perl anymore (resulting in this kind of bullshit "please, please, please pay attention to me!!!")

--The language sucks - yes it does. Usually the KISS principle is thought of as a good thing, except in the Perl language where nothing is ever simple or straightforward. There's 10 ways of doing every single little thing, and no two developers do it the same way. It is not a language welcoming of new developers, so as more schools and companies switch/abandon, I can only imagine it declining further.

-- it offers nothing new or exciting to most developers. If you're starting a new project or company and you already know another similar language (say, Python), Perl has nothing to offer. While it was innovative new 10-15 years ago, most of the good has long been assimilated in other languages.

-- real world perl sucks. a standard line amongst Perl monks is "you can do that in Perl!". Exceptions, objects, web frameworks, clean code, etc. You name it, you can do it in perl. Except in the real world, hardly anyone ever does, so Real World perl is as terrible as people fear. Python's strong community standards, OTOH, pretty much make sure you're almost always writing decent code.

As an example, I picked up both Django and Catalyst over the last year. With Django (python newbie), I immediately picked up decorators and started using them - both the built-in ones and my own. Its simple - just syntactic sugar for a function wrapper.

Catalyst OTOH, tries something vaguely similar using method attributes - except their are neither as powerful nor as simple/clear and despite many years of perl experience on the team, few people had seen them used, used them themselves, nor did they have a solid idea of how they work.

My point is, when you make something simple and accessible, it'll get used. When all you do is repeat "you can do that" and wave your hands about, you'll get ignored and eventually forgotten.

I work with this fellow so keep in mind there's history here between us on the subject. :)

"the language sucks" -- Is very much in the eye of the beholder. Perl works the way I think just as jQuery does. As for not being welcoming, I think you'll find perlmonks.org to be a huge welcoming community.

"it offers nothing new" -- I'm sorry, but if you already know Python or Ruby why would you switch anyhow? There's a big time investment in becoming really good at a language. No reason to switch when you have languages that can just get things done. I'm not even sure what you mean by "new". Perl is 22 years old now. Python and Ruby are both around 15. What's new here? I also find this "new" comment hilarious in light of the Python feature freeze. Things like Moose and Catalyst are new(ish) to the Perl community and they're doing great things. Further, CPAN is expanding at a huge rate, more than ever before. There's ALWAYS new stuff there.

"real world perl sucks" -- Real world code sucks period. And I do clean code. There are standards in Perl and they do evolve. You need to engage in the community a little as I think everyone should with their languages.

What is fairly obvious to me is that Python fits very well with how YOUR brain works. Perl fits very well with how MY brain works.

Just because it don't jive with you, doesn't mean it doesn't jive with others.

'Scuse me. I have a mod_perl2 handler to write.

"Perl works the way I think just as jQuery does"

Never ever say this again.

why not?

You're right. attributes are a bit weird if you don't know perl.

Which is why we've been working on http://search.cpan.org/perldoc?CatalystX::Declare.

The Perl5 community does try and listen to the rest of the world. Unfortunately many of the people we'd like to be listening to make the sort of comments you just did rather than providing constructive criticism that we can effectively address.

The reason for shouting "pay attention" is that many people aren't even bothering to look because they're still stuck with an image of Perl5 based on ten year old information, and we'd at least like to be hated for what we are now rather than what we were back at the end of the last century.

If that upsets you, you're welcome to continue to not pay attention - but we've been getting lots of useful feedback from the people who have and so far as I'm concerned that makes it all worth while.

I've successfully ignored it for a quarter century. It's an abomination.

If you've successfully ignored it, how do you know it's an abomination?

Because somebody told him so.

I've always been put off by the impression that the semantics of Perl consists mostly of edge cases. For example, the discussion of error handling here:

http://www.yosefk.com/blog/what-makes-cover-up-preferable-to...

Which is why, if you're starting a Perl project today, you turn on warnings and strict, you choose between TryCatch and Try::Tiny and you seriously consider adding autodie to the mix.

Why? I've been happily ignoring it for the last 10 years, and I think I can continue to do so ;)

That's why your Language Of Choice is missing many of Perl's features. But hey, at least it has a lot of smugness.

(Smugness solves 0% of my programming problems, but at least I feel good about not solving them.)

I use Python, and the only thing missing from it is ugliness.

You can. But the past decade has produced huge improvements. I've been happily not using python for 10 years but I keep an eye on the state of the art because they regularly come up with interesting ideas that hadn't occurred to me.

Of course, equally, there are lots of other fascinating places to spend your learning time - but discounting a language based on your knowledge of it a decade ago isn't something I'd consider a great idea, in general.

I have been loving Perl until I knew sound languages. Then I realized all the time it made me waste.

Would you care to share some of these realizations?

It's extremely easy to pick up poor practices in Perl5 that make the language appear to be unsound even though it can be used extremely elegantly.

You might want to have a look at the libraries that are part of Task::Kensho to get a better feel for how 21st century perl is supposed to be written - at the very least, you might find some ideas to steal for your "sound" language of choice :)

I hate it, and am happy to continue hating it. Cheers!

My most common use of Perl:

     $ someCommandChain | perl -pe 's/because sed regex sucks/'

Maybe I could spend some time learning a new regex dialect to avoid perl entirely, but for the time being this works for me.

Maybe I could spend some time learning a new regex dialect to avoid perl entirely

You should also cut off your nose. It would totally spite your face!

    >     $ someCommandChain | perl -pe 's/because sed regex sucks/'
    >
    > Maybe I could spend some time learning a new regex dialect

Maybe you should first learn the Perl regex dialect (the above regex doesn't parse in Perl).

If it wasn't obvious I just intended to write something informative in there, and couldn't come up with a clever substitution expression that would fit the sentence.

But ignoring Perl is my way of hating it. And it works.

Reply on news.ycombinator.com