Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

1–10 of 157 posts

Re: Why Perl Didn't Win

#2
I have two programming tattoos: a Perl camel and a Ruby ruby. That basically tells the story of why Perl didn't win for me: As soon as I started learning Ruby, I thought, "Oh, a cleaned-up Perl" and never really wrote any Perl code again.

I love Perl's personality, its quirkiness, and its massive amount of libraries. Perl was _massively_ influential on me as a young programmer. But I'm pretty sure that I won't be writing any Perl ever again.

Re: Why Perl Didn't Win

#4

I have two programming tattoos: a Perl camel and a Ruby ruby. That basically tells the story of why Perl didn't win for me: As soon as I started learning Ruby, I thought, "Oh, a cleaned-up Perl" and never really wrote any Perl code again. I love Perl's personality, its quirkiness, and its massive amount of libraries. Perl was _massively_ influential on me as a young programmer. But I'm pretty sure that I won't be wri…

Exactly. Perl 6 was forever delayed, and along came Ruby. Or rather, out from the shadows came Ruby, which was already there before the Perl 6 debacle, and just needed promotion. The Pragmatic Programmer books were pretty good at pointing to this cool replacement for Perl that you never knew was already there (as well as all the buzz from the RoR folks for those of us who weren't in on the beginning)

I don't really think that the people who left perl all went to PHP.

Now if only there was a "Ruby lite" that ran more like Perl 5 (skipping the GC for reference counting and a few other performance shortcuts)

Re: Why Perl Didn't Win

#6

Write once, read never.

Speak for yourself! (or maybe, for annoying coworkers???)

It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though.

For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstraction, and just shove all the details in-line. In which case, the language of mandate doesn't matter much.

Re: Why Perl Didn't Win

#7
Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain.

Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to work on without too much fuss) and you can create some coding standards and stick to them, and write perfectly maintainable code. But Perl is a bit like C++ in the sense that everybody has different standards and those standards change and "non-standard" bits of the language start leaking into your code and you spend as much time unmessing things as you do writing code.

I don't think Perl will ever really die, it's too convenient, but it's definitely never going to enjoy the dominance it once had. It'll fall back to a very good one-off system admin and log processing language with some extra bits, but it's simply a language that the rest of the world has surpassed and Perl 6 just isn't a realistic offering, after a very loooong wait (nor does it fix the issues non-Perlers have with the language -- it's basically fan service).

Re: Why Perl Didn't Win

#8
I think there's some good points in this article - and I relate to it, 'cause this is exactly how I learned Perl.

The one other item that I'll add is that some of the characteristics that make Perl awesome for sysadmins, like extremely flexible syntax and the ability to freely access data sturctures in a variety of contexts, can make it more difficult to build proper software development projects.

Maybe it's just my limited experience, but it seems like Perl organizations spend a lot more time on mandating coding styles and debating best practices compared with more structured languages like Ruby or Python.

Re: Why Perl Didn't Win

#9
post #6

Write once, read never.

Speak for yourself! (or maybe, for annoying coworkers???) It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though. For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstra…

> For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though.

Great straw-man there. I didn't realise that javac required 500 line methods before compilation.

> In which case, the language of mandate doesn't matter much.

It's a lot easier to pass two collections to a method in Java than to a sub in Perl.

Post reply on HN