Comment by smacktoward | Hacker News Reader

Comment by smacktoward | Hacker News Reader

> I first heard of Perl when I was in middle school in the early 2000s.

Welp, now I officially feel old. Thanks!

In seriousness, though, this is not a very informative article. It essentially boils down to "I learned a little Perl after college, but didn't like the syntax. Then I went to grad school and found that everyone there was using Python, so I switched to that instead. Also, where's Perl 6 amirite lol."

Which is fine, as far as it goes, but it tells you more about the author's career path than it does about either language. And by doing so, it leaves out important elements of the story. Writing an article about "the fall of Perl" that only incidentally mentions PHP, for instance, is a big omission. Insofar as Perl has fallen, what it fell from is the position of leading language for building Web applications. PHP is what pushed it out of that position, not Python or Ruby. If you want to write an article about the fall of Perl you have to explain how that happened and why, but this article attempts neither.

I think the root of the problem is that the author is incorrectly generalizing from his own experiences. He mentions working in scientific computing these days; if you work in that field, and entered the workforce within the last decade, I can totally understand how it might look like The Story Of Programming Languages goes "once there was Perl, now there is Python, The End." But step outside that niche or that time window, and things look very different.

I disagree. A long list of the things that replaced Perl in various applications obscures things rather than revealing the basic trend.

The overall trend is Perl died everywhere.

I personally think Perl's death was proper.

During Perl's upswing, it's various absurdities were all touted as virtues. The weird symbols and the ability to do amazing things with a single line were both proof that Perl was the language for the people who knew more than us. At the certain point, the emperor's cloth just faded and people wanted languages to accomplish things rather than to prove they were smart.

Perl has positives, Perl's weirdnesses have positives. But once it lost it's cachet, none of the tradeoffs between obscurity and power look good. And yeah, other powerful interpreted languages arose. But which still doesn't matter which one won because once the "magic", the reality distortion field, was gone, every other good interpreted language looked better.

> The overall trend is Perl died everywhere.

Huh? Is that offering a false choice between total dominance and death?

> Perl has positives, Perl's weirdnesses have positives.

I am not going to generally argue for one language over another. Most languages have good and bad, and a learning curve to doing things right. Perl has a learning curve too, and while there is more than one way to do it, that doesn't mean that every way is equally maintainable over time.

When I look at languages I can do interesting things with, Perl is at the top of my list along with Lisp, Rebol, and Red. These languages have a degree of mutability in the language which allows you to do things that might otherwise not be particularly possible. There's a strong lisp heritage that runs through the entire set.

Now consider something like this:

     package My::class;
     use PGObject::Util::DBMethod;

     use Moo;
     with 'My::PGObject::SimpleRoleWrapper';

     has foo => (is => 'ro', required => 1);
     has bar => (is => 'rw', required => 0);

     dbmethod foobar => (funcname => 'foobar',
                       funcschema => 'myclass');

     dbmethod save_new => (funcname => 'save', 
                         funcprefix => 'foobar_',
                         funcshema  => 'public',
                       strict_args  => { bar => undef });

What this would do is create a class with two properties (foo and bar), and two methods. The methods are delegated to stored procedures, and properties mapped into procedural arguments by name (the second example overwrites $self->bar with undef). I have created a class that does something with only declarative code. The code is neat, clean, understandable, and predictable. Again I could build something like this in Rebol or (once there is Pg support) Red, and this sort of thing could be done in Lisp too.

This gives Perl a lot of power, and once the framework is done, learning to code Perl in the framework (with or without Perl knowledge) has an easy learning curve. The code is easily maintainable and it is robust.

Oh, when did Perl die?

I missed the camel's obituary.

I recently wrote a program in Perl which had to be delivered in two weeks. I don't think I could have delivered it on time with C or Python.

Saying Perl is dead, is like saying AWK is dead. I still write AWK programs sometimes.

Whatever's the right tool for the job.

> The overall trend is Perl died everywhere.

Far from the truth, Perl is everywhere, what died is the hype.

If the life of a language can be measured in how many people are learning it for any reason other than to maintain an existing code base written in it (an arbitrary definition, but I think a common one), then Perl is roughly dead-as-a-doornail, in precisely the same sense as, say, COBOL is dead.

(Note that under this definition, FORTRAN isn't dead—people still write new code in it, every once in a while, due to its mathematics libraries. Perl is "more dead than FORTRAN.")

Are you talking about new people learning language, as you state, or people writing new code in a language, as your example implies?

Without revision to clarify your point, it looks somewhat like you had a statement you wanted to make (Perl is "more dead than FORTRAN.") and had to reach for some assertions to support it.

The intersection of the two sets: new people learning the language, who are learning the language in order to write new code in the language.

New people learn COBOL still, but they only do that if-and-when someone with an existing COBOL codebase has a problem with it, for which they're willing to hire and train up new programmers in COBOL.

For example, banks who needed their batch-processing code updated for Y2K-compliance trained a good few people in COBOL. But they weren't learning COBOL wIth the intent of writing new code in the language—just with the intent of maintaining old code. Effectively, they were treating the COBOL codebase as a Ball of Mud (http://laputan.org/mud/), where old components could be patched, but any new component should be written for a living platform, communicating with the Ball of Mud over an API instead of being sucked into it.

I'm asserting, here, that Perl is such a language—that the only reason new people learn Perl is to maintain a Ball of Mud written in Perl. From there, they may go on to become productive Perl programmers—but because they were only "born" into the Perl community because some company who had Perl-ers lost them and needed new ones, the language's adoption rate is effectively "below replacement," like a birth rate below 2.0.

In living languages, at least some people will learn the language on their own, because they think it will be useful for some task they'd like to accomplish. Perl is not one of these languages.

Under this definition, other dead languages include sh-derivative shell scripting (people only learn it because shell scripts that already exist must be modified), and anything to do with SOAP (it was stillborn; people only ever learned about it to deal with codebases that used it. Then, horrifyingly, they ended up creating more of those codebases.)

>>The overall trend is Perl died everywhere.

I've been hearing that same thing repeatedly since the past 10-12 years.

Yet that is never so.

PHP is what pushed it out of that position, not Python or Ruby

Exactly true. PHP was the thing to use in 2001. At that time Ruby was rarely used for web purposes, and most Ruby libraries, while extensively documented, were mostly documented in Japanese with a tiny, incomplete English version with horrible grammar. And Python? Well, there was no Django, Flask, WSGI, SQLAlchemy, Pyramid or other frameworks/utilities that Python programmers enjoy today, and Python was rarely used in a web context.

Reply on news.ycombinator.com