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

151–157 of 157 posts

Re: Why Perl Didn't Win

#151

Post by Roboprog »

Poiesis wrote: post #56
[deleted] wrote: post #37

Earlier quoted context omitted.

[deleted]

So, I actually have no love for Java, and am greatly enjoying the higher proportion of scripting irb been up to lately. But I had to comment on a couple things: > Why only that library...? I've seen it all when a Perl developer is calling out a Java developer regarding TMTOWTDI. Nice library though. >I would like to execute some shell commands Not sure comparing to a language with an explicit complicit compilation st…

FWIW, I do more Java than Perl at work, though a fair amount of both. I guess I have written both "in anger", depending on the situation.

I guess the thing that gets under my skin about Java is that it is the mandatory one true language at so many workplaces.

Re: Why Perl Didn't Win

#152

Post by sharyanto »

kephra wrote: post #67

> You need large absolute numbers of users to grow a library. That's why library ecosystems like that of Python, Ruby, and Node.js have grown large in recent years. Thats where the author missed an important point. None of those library archives have the culture of PAUSE+CPAN to constrain a minimal code quality when it comes to configuration, documentation, regression test and installation. This minimal code quality…

To be fair, CPAN is also full of junk. And Acme::* :)

Re: Why Perl Didn't Win

#153

Post by steveklabnik »

mst wrote: post #148
steveklabnik wrote: post #129

Earlier quoted context omitted.

Moose came out five or six years after I made the move, so I'm not super familiar. Can you expand on some of this? I very, very rarely need 'boilerplate' in Ruby...

Two examples. Note that I'm going to write the boilerplate-ish version in perl as well, because I think it'll be equivalent and that's probably more likely than not screwing up the ruby code. Please correct me if it isn't equivalent. Most of my object attributes look like one of - has foo => (is => 'ro', required => 1); has bar => (is => 'lazy', builder => sub { Some::Logic::here() }); which translates through to, in…

First of all, thank you so much for writing this out.

> I'd still have to write the bar() lazy/build accessor,

Yes, in Plain Ruby

> and an initialize() method to do the equivalent of '_init' - and name _build_bar by hand,

There's a 'trick' involving Struct that some people use to handle this. If you asked Rubyists, they'd probably say 50/50: http://blog.steveklabnik.com/posts/2012-09-01-random-ruby-tr...

> I'm unaware of any ruby equivalent for the Class::Method::Modifiers CPAN module,

Rails offers this in controllers as {before,after,around}_action, and actions are just methods. You'd have to write it yourself, though, you're right, or use a gem.

> I'm open to being told I'm doing it completely wrong

Naw, though I will say that I very rarely need to do things like this, or when I do, the boilerplate doesn't bother me enough to justify the metaprogramming required to do it in a mega generic way. :)

Re: Why Perl Didn't Win

#154

Post by schmonz »

I recently spent 4.5 years at a big bank developing identity-management tools. They were written in Perl. The first thing I did was screw up in production: http://www.schmonz.com/2014/06/01/tdd-in-context-1-keeping-m...

So I started carefully making the code testable, then gradually adding tests and refactoring under them, and gradually adopting and taking advantage of Moose, shipping every month all the while. There was never a second screwup.

(Will big banks keep choosing Perl for new projects? Yes, for a long time. It's firmly entrenched. It didn't win, but it'll probably never lose either.)

Would I choose Perl for a new project? That depends. For programmers with taste, discernment, and discipline, Perl-the-language + Perl-the-CPAN can be incredibly and sustainably productive. For other programmers, it's enough rope to quickly cut off bloodflow to your foot, which you can then use Perl to amputate.

In other words, Perl is at the high end of the risk/reward curve. If I could mitigate the risk -- say, by convincing myself that I'll always be in a position to hire great programmers or nobody -- then I'd absolutely want the reward of developing a new system in Perl.

Re: Why Perl Didn't Win

#155

Post by mst »

steveklabnik wrote: post #153
mst wrote: post #148

Earlier quoted context omitted.

Two examples. Note that I'm going to write the boilerplate-ish version in perl as well, because I think it'll be equivalent and that's probably more likely than not screwing up the ruby code. Please correct me if it isn't equivalent. Most of my object attributes look like one of - has foo => (is => 'ro', required => 1); has bar => (is => 'lazy', builder => sub { Some::Logic::here() }); which translates through to, in…

First of all, thank you so much for writing this out. > I'd still have to write the bar() lazy/build accessor, Yes, in Plain Ruby > and an initialize() method to do the equivalent of '_init' - and name _build_bar by hand, There's a 'trick' involving Struct that some people use to handle this. If you asked Rubyists, they'd probably say 50/50: http://blog.steveklabnik.com/posts/2012-09-01-random-ruby-tr... > I'm unawar…

The Struct thing is neat except that I really, really, really hate positional constructor parameters as opposed to named.

Plus it misses out the whole "I can have required and optional parameters and it just works" part of what I was showing you.

> Naw, though I will say that I very rarely need to do things like this, or when I do, the boilerplate doesn't bother me enough to justify the metaprogramming required to do it in a mega generic way.

Right. Thing is ... you know how people often say "I didn't really find perl that kludgy until I used ruby for a while, and then going back to perl was heinous"? After a couple of years of using Moose, I found going back to anything that couldn't do all of that easily to be heinous.

The last time somebody I knew who writes both perl and ruby tried to port some of my perl code to ruby, they ended up with 3x or 4x as much code per class because I lean more heavily on this stuff than you'd think if you weren't already using it, and got bored about three classes in and decided to wait for somebody to port Moo/Moose to ruby before trying again.

Which is a shame, because I was really hoping they'd finish, stare at the boilerplate, and then find a more rubyish way of writing the whole thing that made it not have boilerplate ... but the fun ran out before any of it ran.

The thing is, my gut feeling is that rubyists probably design their classes -just- differently enough to me that they don't need what they don't have, but I can't figure out how to devise an experiment to figure that out.

If you come up with such an idea, I'd love to hear it, since some sort of comparison that shows how the idioms fall out differently in the two languages would be really nice, but I can't think of one that wouldn't be either trivial or more work than its worth.

Thanks for responding; it's really quite pleasant to have this sort of conversation without getting derailed into language wars :)

Re: Why Perl Didn't Win

#156

Post by steveklabnik »

mst wrote: post #155
steveklabnik wrote: post #153

Earlier quoted context omitted.

First of all, thank you so much for writing this out. > I'd still have to write the bar() lazy/build accessor, Yes, in Plain Ruby > and an initialize() method to do the equivalent of '_init' - and name _build_bar by hand, There's a 'trick' involving Struct that some people use to handle this. If you asked Rubyists, they'd probably say 50/50: http://blog.steveklabnik.com/posts/2012-09-01-random-ruby-tr... > I'm unawar…

The Struct thing is neat except that I really, really, really hate positional constructor parameters as opposed to named. Plus it misses out the whole "I can have required and optional parameters and it just works" part of what I was showing you. > Naw, though I will say that I very rarely need to do things like this, or when I do, the boilerplate doesn't bother me enough to justify the metaprogramming required to do…

> Right. Thing is ...

Absolutely. :)

> I can't think of one that wouldn't be either trivial or more work than its worth.

This is the hardest part about finding examples.

> Thanks for responding; it's really quite pleasant to have this sort of conversation without getting derailed into language wars :)

Agreed. Thank _you_!

Re: Why Perl Didn't Win

#157

Post by BenGoldberg »

rdtsc wrote: post #57
autarch wrote: post #36

I suspect that all the languages that are "winning" right now will have "lost" 10-20 years from now too. What's the longest lived language out there right now that's actually still in heavy use? I'd say C. But C has clearly fallen from its position of complete dominance when every new project was written in C (because it was much easier than writing assembly). C++ had its day as well and lives on in many places, but…

So maybe winning is more like winning for a time period. PERL did win. It won up until early 2000s, then lost. I am guessing it is not getting picked much for new, greenfield projects. I think that is a cut-off metric. One way get there is to find a niche. Maybe it isn't the new use-for-everything language. But at least can become the "ok, use for this one area" language. C -- still winning in that respect. It is use…

One might even say that Fortran is still winning!
Post reply on HN