Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

Post reply on HN
Print view View original

11–20 of 157 posts

Re: Why Perl Didn't Win

#11

Post by rustyconover »

The same things could be argued as for why, why C didn't win, or C++ didn't win, or even really PASCAL/Smalltalk/Lisp didn't win. "Winning" is temporary and not the end goal of any language and is best left to be declared by Charlie Sheen like pundits trying to demonstrate their language bigotry.

Is Perl the first tool that some of us think of when solving a problem? It might not be for you but it is frequently for me. Ruby might be your first choice, and really that's fine.

You're not a lesser or better programmer than anyone else if you choose something besides Perl either. Honestly, if you can solve the problems that you need to solve and you can work with your team, that's the only thing that matters. Not that you're using some language that isn't "winning".

As for Perl not having support for recent things like Stripe, that's just silly to argue (the author really should have searched the CPAN). Perl has many new modules, Dancer, Catalyst, Moose, Plack, Starman, Net::Stripe (maintained by me), and full support of AWS's offerings. And, yes modules written in 1999 do get used today, just look at all of LWP.

"Winning" isn't everything. Admittedly, Perl 6 isn't out or even moving forward visibly but doesn't mean that the language is irrelevant. Just watch https://metacpan.org/recent to see the pulse of the community and the new modules released and updated daily.

Re: Why Perl Didn't Win

#13

Post by [deleted] »

EdwardDiego wrote: post #9
Roboprog wrote: post #6

Earlier quoted context omitted.

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.

[deleted]

Re: Why Perl Didn't Win

#14

Post by jmacdotorg »

Articles which critique Perl as a whole by focusing on Perl 6 always strike me as a bit strange. As someone who works professionally with Perl every day, and starts several new projects using Moose-centric modern Perl techniques every year, the amount of time I or any of my colleagues spend thinking about Perl 6 is negligible.

The modern Perl movement, as far as I can tell, arose in part from Perl hackers who started to treat the wandering Perl 6 project — rife with neat ideas, if not with release engineering — as a skunkworks for Perl 5 extensions. In the gap between the middle-aughts and 2014 that this writer waves away with “is anyone still paying attention?” due to no Perl 6 release, the active Perl world adopted Moose, and many Perl-based Moose-driven technologies — Catalyst, DBIC, and so on.

These technologies, and the communities around them, have thrived on their own ever since. Nowadays when I think about Perl 6, it is often because I am at a Perl conference and Larry Wall is literally at the podium talking about it and I am like “Well. You go, Larry Wall.”

Perl really has reinvented itself in the last handful of years, at least in the eyes of those who make a living inventing new things with it. I can’t call this writer wrong — their perspective is their own. I suppose I can only learn to appreciate the notion that, to hackerly folks who aren’t as ensconced within the modern Perl community as I, the language is this thing from the 1990s that kicked the bucket through one bad decision in the summer of 2000, leaving behind acres of legacy code that’s still being scraped away.

To be fair: this indeed describes a lot of what I am hired to do. It’s just that I replace it all with newer and better Perl…

Re: Why Perl Didn't Win

#15

Post by amenbrother »

bane wrote: post #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…

I was recently asked to add some trivial code to the end of an existing unmaintained Perl script written long ago. Something along the lines of

  $x = `cat FOO 2>/dev/null`;
  if ($x == "foo") {
      system("BAR");
  }
When I tested it I found BAR was executed no matter what FOO contained without any errors or warnings. WTF? After a little more searching I found the problem was that I should have written

  $x = `cat FOO 2>/dev/null`;
  if ($x eq "foo") {
      system("BAR");
  }
I have absolutely no patience for this kind of crap, but I don't have time to replace the whole thing right now so I just suck it up and move on. I can understand how Perl may never die completely but I'm never going to use it for anything new.

Re: Why Perl Didn't Win

#17

Post by ww520 »

Perl lost because PHP took its place on the web development front.

Perl lost because Python/Ruby took its place on admin front.

Perl lost because the new version took forever to get ready and broke compatibility with the old code.

Re: Why Perl Didn't Win

#18

Post by ghshephard »

I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product).

And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then.

There were two personal reasons why I left Perl.

First - I would write some code, it would do what I wanted, but then I would come back in a week (or even a few days) and have no idea how it worked. This is code that I wrote. Yes, I know this is a personal failing (I said these were personal reasons) - but, on the flipside, I've never had anything I've written in Python that I didn't completely understand how it worked any time in the future. Perl just let me write code that was too complex for my brain to comprehend. I blame implicit variables. [edit - and perhaps an over reliance on regex.]

Second, If I hadn't used them for a month or so, I used to struggle with Arrays of Hashes and Hashes of Arrays. Once I eyeballed my template, it all came back, but the syntax imposed enough cognitive overhead that I struggled with that data structure (which is one that you use a lot).

On the flip side - the very first day I was learning Python, I thought to myself, "What if I just drop an array (list) as an object in this hash (dict), or a dict in this list? Will this work?

And it did. Close to zero cognitive overhead.

So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.

Re: Why Perl Didn't Win

#19

Post by stcredzero »

How does a language win? By being compelling enough to be used for new things. It's not solely a technical concern; it's a concern of the language community and ecosystem.

One of the most valuable 4 sentence paragraphs I've read from an HN post in awhile. (Perhaps 3, but the semicolon really separates 2 sentences.)

Re: Why Perl Didn't Win

#20

Post by gsteinb88 »

mattzito wrote: post #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…

But as was mentioned in another comment, what you mention as a key appeal for sysadmins is exactly why I can't stand perl. In particular "extremely flexible syntax" makes taking over the sysadmin job from another person, or joining a team, a ridiculous amount of effort. I can't begin to tally the number of hours I've spent with perl code open in one window, and a web browser open to various different perl guides, the documentation, etc. trying to figure out what tricks some script is using that makes it completely incomprehensible to me.

Is it fun? Sometimes, except never when a key service is down and you have users breathing down your neck. Or your website is down. Or really, trying to do any kind of maintenance work. And guess what happens? More crazy patches, probably written in an entirely different style! So now there are $n+1$ different styles in that script, and my successor is going to be even more frustrated with me than I am with my predecessors.

On the flip side, it's been a great education on the difference between maintaining code for your own use and code in an organization...

Post reply on HN