Why Perl Didn't Win
outspeaking.com
Why Perl Didn't Win
1–10 of 157 posts
Re: Why Perl Didn't Win
#2I 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
#3Re: Why Perl Didn't Win
#4I 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…
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
#5http://en.wikipedia.org/wiki/Osborne_effect
What killed Perl? An imaginary Perl did.
Re: Why Perl Didn't Win
#6Write once, read never.
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
#7Sure, 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
#8The 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
#9Write 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…
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.
Re: Why Perl Didn't Win
#10Write once, read never.
YALT -- yet another languagewar troll.