[macosxnerd101]

Quote

Last week I dug into a fairly sensitive topic in some circles: the decline in Perl's popularity in favor of other languages. I received the expected response from Perl diehards, which essentially boiled down to "No, it's not!" with much saltier language.

Somewhat surprisingly, however, as I read comments about my post here and in various places around the Internet, I found that some stalwarts are admitting they see this happening as well. It might be a few large-scale Perl projects that have been rewritten in Python or Java, or a noticeable trend of new projects begun in other languages. One comment on Reddit sums this up well, particularly a key line: "We've got cancer, and denying it just means we can't work to fight it."

http://www.infoworld...ase-perl-212077

[jon.kiparsky]

Quote

I don't have an action plan or any available magic that could restore Perl to its former glory.

Larry Wall didn't write perl to "restore sed and awk to their former glory", he wanted to make a language that would kick ass at text processing.
Perl is a great language, but one of the best things about it is that it pushed so many languages to be even greater, and that work is done. It was probably the first language with first-class functions for a generation of programmers, it pretty much invented dynamic web programming, and of course everybody's regex package is based on perl's - but those things have already been done.
What does perl offer now? It's the best unix power tool available, and the worst applications language this side of brainfuck, and nobody runs their site off scripts in the cgi-bin anymore.

[baavgai]

There's something in business called the Peter Principal: "Employees tend to rise to their level of incompetence." It also seems to work for software.

If you're using standard unixy tools to string together shell scripts from hell, perl will save you. In the arena of the *nix sysadmin scripter, there was nothing better.

Then perl 5 added objects. This is when perl "jumped the shark" and validated the Peter principal. Perl OO is dreadful. Perl is a craptastic application platform. By trying to make it an Object Oriented programming panacea the language essentially eviscerated itself. It's been circling the drain ever since.

It didn't die completely on it's own: bash, python, and several others are stomping on its head. There have been times when I thought, "this is a job for perl!" After a few minutes of nostalgic self abuse I just do it in python.

[jon.kiparsky]

"Nostalgic self-abuse"? That usually means thinking fondly about old girlfriends, doesnt it? (... which might be about right considering the topic at hand ...)

EDIT: um, so to speak...

This post has been edited by jon.kiparsky: 04 February 2013 - 11:27 AM

[dsherohman]

jon.kiparsky, on 04 February 2013 - 06:51 PM, said:

...and the worst applications language this side of brainfuck...

Care to elaborate? The rest of your post sounds like you have some experience with and respect for Perl, but this is straight-up anti-Perl FUD.

jon.kiparsky, on 04 February 2013 - 06:51 PM, said:

...and nobody runs their site off scripts in the cgi-bin anymore.

Indeed. Not even Perl programmers. Perl has several excellent web application frameworks these days and the vast majority of the Perl community uses them when they do web work. Granted, there are still a lot of 20-year-old tutorials out there telling beginners to write unmaintainable scripts in cgi-bin, but, unfortunately, the net never forgets, so instead you've got people like me, on sites like this, trying to do damage control.

baavgai, on 04 February 2013 - 07:22 PM, said:

Then perl 5 added objects. This is when perl "jumped the shark" and validated the Peter principal. Perl OO is dreadful.

Personally, I've never had a problem with Perl OO. I actually like unrolling @_ for myself and being able to see the underlying structure of how it actually works. Most people in the Perl community disagree with me on that, though, and so they created Moose, an object system for Perl which is solid enough that other languages are building systems which sit on top of their native object system and emulate it, such as Javascript's Joose, which "is based in large part on the Moose system".

baavgai, on 04 February 2013 - 07:22 PM, said:

There have been times when I thought, "this is a job for perl!" After a few minutes of nostalgic self abuse I just do it in python.

I'm glad to hear that you've found a language that works better for you, but that doesn't mean that languages which don't fit you as well are necessarily inferior.

I've tried Python and didn't care for it. I've also read (and occasionally participated in...) a lot of Perl vs. Python language wars. From what I've seen, there's very little distinction between them in substance, only in taste. The main difference seems to be that the languages' stated philosophies of "there's more than one way to do it" vs. "there should be one—and preferably only one—obvious way to do it" have a tendency to carry over into their users' feelings about language choice as well.

[baavgai]

Excellent! Imagine finding a perl evangelist in 2013. Thanks for the comments.

The fact is, I'll use any language. I used perl when it simply beat the crap out of awk / sed scripts. I used awk when it was easier to deal with than available shells. Tools are tools and it's good to be open to which ones fit which context. I recall someone actually wrote a chess analyzer in awk; context fail.

Perl isn't inferior to anything and I'm sorry if I gave that impression. If I found myself on an old *nix box with a few gigs of logs to search through and some logic more complex than grep, it would be the first tool I'd want. For many other tasks in that domain, I might use Python.

But it's not Python vs. Perl. If I wanted a simple web page, I'd grab PHP. If I needed some enterprise web portal I'd choose Java. If I was in Windows land instead, I'd use ASP.NET for the web stuff. I'd use Powershell or even VBScript for the domains that perl and friends fit on the *nix box.

Yes, I can actually use perl hooks in Win32 to do that same stuff as Powershell and VBScript. I can use Python, PHP, and Java on Windows as well. However, in the context of windows, there are better choices.

It's all about the solution domain. Perl, as a general language, can do anything. It comes down to how well other available tools in that domain do the same job.

[jon.kiparsky]

Quote

Care to elaborate?

The language is not designed to communicate intent. Larry Wall made a great language with a lot of flexibility, but all of the flexibility makes it very hard to maintain a large project across multiple programmers. The "write-only" canard actually has some teeth to it: it's possible to write maintainable perl, but it's more difficult, to the point where it trades away the advantages of the language.

It turns out that "there's more than one way to do it" is either a bug or a feature, and the crossover comes when the length of the code goes past a few screens. "There's one or two right ways to do it" is much better for a large project, because you want to be able to write idiomatically. You want a competent programmer to be able to read your code without having to decipher it, and that's made much more difficult if there's half a dozen ways to take each individual step of a routine.

Just to drive the point home, imagine trying to write JAPHs in any other language. A language that has an infinite number of ways to generate a particular literal string has a lot of beauty and a lot of power and a lot of problems.

Quote

The rest of your post sounds like you have some experience with and respect for Perl, but this is straight-up anti-Perl FUD

Oh, please. I'm a programmer. Being anti-perl is like being a carpenter and being anti-hammer.
I've been using Perl for close to twenty years, and I love using it when it's the right thing to use, but I can't imagine why you would want to write anything large in it - just as I can't imagine why you'd want to use Java for file-fiddling or C for web development.

baavgai, on 05 February 2013 - 07:06 AM, said:

I'd use Powershell

Oh, ick.

baavgai, on 05 February 2013 - 07:06 AM, said:

I'd use Powershell

Oh, ick.

[dsherohman]

baavgai, on 05 February 2013 - 01:06 PM, said:

Excellent! Imagine finding a perl evangelist in 2013. Thanks for the comments.

I don't think I've ever been called a "Perl evangelist" before. Thanks!

baavgai, on 05 February 2013 - 01:06 PM, said:

Perl isn't inferior to anything and I'm sorry if I gave that impression. If I found myself on an old *nix box with a few gigs of logs to search through and some logic more complex than grep, it would be the first tool I'd want. For many other tasks in that domain, I might use Python.

That definitely is a common type of misunderstanding online. Sorry if I jumped the gun there.

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

The language is not designed to communicate intent. Larry Wall made a great language with a lot of flexibility, but all of the flexibility makes it very hard to maintain a large project across multiple programmers. The "write-only" canard actually has some teeth to it: it's possible to write maintainable perl, but it's more difficult, to the point where it trades away the advantages of the language.

Interesting. I've seen the "too flexible for large and/or multi-programmer projects" criticism before, but the suggestion that writing maintainable Perl trades away the language's advantages is a new one to me. What are the advantages that you think are lost in maintainable code?

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

Just to drive the point home, imagine trying to write JAPHs in any other language. A language that has an infinite number of ways to generate a particular literal string has a lot of beauty and a lot of power and a lot of problems.

Indeed! But, then, I don't think I've seen anyone who's active in the Perl community and believes that JAPH/golfing/obfuscation techniques have any place in production code.

In today's Perl community, use strict; use warnings; is generally the first piece of advice given to beginners (even if it's completely irrelevant to their question/problem...) and most common tasks either have widely-used idioms or CPAN modules addressing them. Bringing beginners into the community and making them aware of these idioms/modules is definitely an issue, and it's made an order of magnitude worse by all the ancient books and tutorials teaching deprecated ways of coding, but experienced Perl programmers do tend to write mutually-intelligible code with very similar structures. Really, I think we're getting to the point where the bigger problem may be one of redundant modules on CPAN with no clear way to determine which is the best option in any given case rather than the multiple ways of writing new code in the core language.

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

Quote

The rest of your post sounds like you have some experience with and respect for Perl, but this is straight-up anti-Perl FUD

Oh, please. I'm a programmer. Being anti-perl is like being a carpenter and being anti-hammer.

I have a hard time reading "worst applications language this side of Brainfuck" as anything other than anti-hammer. Again, I gathered from the rest of your post that you probably weren't anti-Perl overall, but I stand by my characterization of that one specific statement as being anti-Perl FUD.

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

I've been using Perl for close to twenty years, and I love using it when it's the right thing to use, but I can't imagine why you would want to write anything large in it - just as I can't imagine why you'd want to use Java for file-fiddling or C for web development.

I've used C for (more-or-less) web development... It was under protest, but the CTO insisted that our "use apache to pull text out of a database and return it as text/plain" back-end had to be as screamingly fast as possible, so C was the only acceptable option. That was far more painful than any new development I've done in Perl.

Maintaining existing Perl is, admittedly, a completely different story. Poorly-written Perl is, by far, the greatest horror I've had to face professionally. Well-written Perl, on the other hand, isn't all that different from well-written code in any other language.

[dsherohman]

baavgai, on 05 February 2013 - 01:06 PM, said:

Excellent! Imagine finding a perl evangelist in 2013. Thanks for the comments.

I don't think I've ever been called a "Perl evangelist" before. Thanks!

baavgai, on 05 February 2013 - 01:06 PM, said:

Perl isn't inferior to anything and I'm sorry if I gave that impression. If I found myself on an old *nix box with a few gigs of logs to search through and some logic more complex than grep, it would be the first tool I'd want. For many other tasks in that domain, I might use Python.

That definitely is a common type of misunderstanding online. Sorry if I jumped the gun there.

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

The language is not designed to communicate intent. Larry Wall made a great language with a lot of flexibility, but all of the flexibility makes it very hard to maintain a large project across multiple programmers. The "write-only" canard actually has some teeth to it: it's possible to write maintainable perl, but it's more difficult, to the point where it trades away the advantages of the language.

Interesting. I've seen the "too flexible for large and/or multi-programmer projects" criticism before, but the suggestion that writing maintainable Perl trades away the language's advantages is a new one to me. What are the advantages that you think are lost in maintainable code?

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

Just to drive the point home, imagine trying to write JAPHs in any other language. A language that has an infinite number of ways to generate a particular literal string has a lot of beauty and a lot of power and a lot of problems.

Indeed! But, then, I don't think I've seen anyone who's active in the Perl community and believes that JAPH/golfing/obfuscation techniques have any place in production code.

In today's Perl community, use strict; use warnings; is generally the first piece of advice given to beginners (even if it's completely irrelevant to their question/problem...) and most common tasks either have widely-used idioms or CPAN modules addressing them. Bringing beginners into the community and making them aware of these idioms/modules is definitely an issue, and it's made an order of magnitude worse by all the ancient books and tutorials teaching deprecated ways of coding, but experienced Perl programmers do tend to write mutually-intelligible code with very similar structures. Really, I think we're getting to the point where the bigger problem may be one of redundant modules on CPAN with no clear way to determine which is the best option in any given case rather than the multiple ways of writing new code in the core language.

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

Quote

The rest of your post sounds like you have some experience with and respect for Perl, but this is straight-up anti-Perl FUD

Oh, please. I'm a programmer. Being anti-perl is like being a carpenter and being anti-hammer.

I have a hard time reading "worst applications language this side of Brainfuck" as anything other than anti-hammer. Again, I gathered from the rest of your post that you probably weren't anti-Perl overall, but I stand by my characterization of that one specific statement as being anti-Perl FUD.

jon.kiparsky, on 05 February 2013 - 03:51 PM, said:

I've been using Perl for close to twenty years, and I love using it when it's the right thing to use, but I can't imagine why you would want to write anything large in it - just as I can't imagine why you'd want to use Java for file-fiddling or C for web development.

I've used C for (more-or-less) web development... It was under protest, but the CTO insisted that our "use apache to pull text out of a database and return it as text/plain" back-end had to be as screamingly fast as possible, so C was the only acceptable option. That was far more painful than any new development I've done in Perl.

Maintaining existing Perl is, admittedly, a completely different story. Poorly-written Perl is, by far, the greatest horror I've had to face professionally. Well-written Perl, on the other hand, isn't all that different from well-written code in any other language.

[Aries86]

It's lovely. Thanks for showing the steps of how it was created.


_____________________________
Aires86