Why Perl Didn't Win • Hacker News Board

Re: Why Perl Didn't Win

#141

Post by mst » Mon, Jun 09, 2014, 8:05 PM UTC

amenbrother wrote: post #105

mst wrote: post #79

Earlier quoted context omitted.

I guess you've never written any bash either, wherein the exact same problem exists except that == and eq are the other way around, for reasons I can't quite remember. Plus, of course, if you'd enabled perl's warnings system, via 'use warnings;', it would have complained at the use of == on a non-numeric value. If you don't enable the compiler features that catch problems, then, yes, you can run into problems. Welcom…

Thanks for the 'use warnings;' suggestion. Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule and the work is often done by programmers with incomplete knowledge and no patience for explanations. For maintenance you want KISS, not TMTOWTDI. I'm no big fan of bash but at least bash gets the common case right here without any special settings . For example,…

Equally, bash requires 'set -x' to not ignore errors.

In both cases, the reasoning is significantly to do with backcompat, I believe.

So, yeah, things that have been around a long time often require a setting to be safe in cases that we, ten or twenty or whatever years on, consider common.

Also: I did keep that in mind. That's why I started off suggesting using warnings, rather than (as I normally do for new code) making them fatal :)

Re: Why Perl Didn't Win

#142

Post by yellowapple » Mon, Jun 09, 2014, 9:15 PM UTC

mamcx wrote: post #138

mst wrote: post #82

Earlier quoted context omitted.

I don't want the popularity we once had. The same people who wrote unreadable, unmaintainable perl went on to do the same sort of damage in PHP, then python, then ruby/rails, and now node.js/go. They were never a net positive to the community, and I'm not sorry to see them causing problems for somebody else. (and before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code tha…

With python is not the same. Even if the developers is truly bad and do a mess, is a decipherable mess. Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

> Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

Last I checked, the whole "if it was hard for me to write, it should be hard for others to understand" was still a mockery, not a seriously-interpreted excuse. It ignores the fact that the programmer's future self will eventually need to maintain that code. The developer might have skill, but one who writes unmaintainable messes as anything other than a Perl-golf-style mental exercise probably lacks wisdom. :)

Re: Why Perl Didn't Win

#143

Post by yellowapple » Mon, Jun 09, 2014, 9:17 PM UTC

esaym wrote: post #121

mst wrote: post #82

Earlier quoted context omitted.

I don't want the popularity we once had. The same people who wrote unreadable, unmaintainable perl went on to do the same sort of damage in PHP, then python, then ruby/rails, and now node.js/go. They were never a net positive to the community, and I'm not sorry to see them causing problems for somebody else. (and before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code tha…

I was thinking the same thing. Didn't say anything because I didn't want to be rude to the "lets cut and paste code from google searches" coders... If someone really wants to use a language, there is no excuse for not reading a book for that language first.

And when it comes to a "book for that language", Programming Perl really does take the cake.

Re: Why Perl Didn't Win

#144

Post by yellowapple » Mon, Jun 09, 2014, 9:28 PM UTC

EdwardDiego wrote: post #24

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…

> But it's a rotten language to maintain. I've been diving into some of our legacy Perl and man, the learning curve of the various sigils and implicit variables. Even working with collections was challenging. I'm working to make it better Perl (I have a copy of Modern Perl on my desk), but that's solely to make it understandable so that we can rewrite it / replace it with something like Salt.

If you don't enjoy Perl code that looks like a cartoonish string of censored profanities, you could always try including 'use English' in your program, which aliases more descriptive names to all those punctuation-mark special variables. See here: http://perldoc.perl.org/English.html

Re: Why Perl Didn't Win

#145

Post by yellowapple » Mon, Jun 09, 2014, 9:42 PM UTC

overgard wrote: post #25

Perl is sort of like trying to read someone else's brain (in this case Larry Wall's). You get themes and kind of the gist of where it's going, but it never quite adds up to some sort of coherent whole. The defense has always been that Perl is designed more like natural language than programming language, ok, but: natural languages are a LOT harder to learn than programming languages. Put me in a room with Haskell and…

The idea behind Perl being designed akin to a natural language isn't for its ease of learning, per se, but for its ease of expressiveness. English is probably significantly harder to learn than Python, for example, yet it's likely much easier to write a novel in the former than it is to write one in the latter.

Re: Why Perl Didn't Win

#146

Post by kbenson » Mon, Jun 09, 2014, 10:25 PM UTC

raiph wrote: post #140

The domain outspeaking.com is owned by chromatic's company. Afaict chromatic was the first to promote the article with a tweet shortly after it was published and shortly before it appeared here on HN and reddit. When someone noted this connection on reddit and said they thought chromatic wrote it his response was "I'm not the only person with access to the server. Anonymous wrote that article." http://www.reddit.com/…

My understanding is that chromatic is not the only person at that company that knows Perl, not that has had experience with Perl 6 and/or Parrot. I think it's appropriate to judge the article on it's merits and how well it covers the issue, not the specific views of people that may be associated with it.

Truth be told, I was thinking while reading it that it sounded quite a bit like chromatic but with tones down criticism, and said as much to a friend I fowarded it to. I wrote this "Sounds a lot like chromatic when he was disillusioned, but not yet bitter. Which is to say harsh, but definitely constructive." That it's from the company he's involved in doesn't surprise me. If he wrote it and wants to keep it as aonymous, I think that's perfectly acceptable. If someone else there wrote it, that wouldn't surprise me either; I doubt all of his thoughts and opinions happen in a vacuum.

Re: Why Perl Didn't Win

#147

Post by mamcx » Mon, Jun 09, 2014, 10:57 PM UTC

mamcx wrote: post #138

mst wrote: post #82

Earlier quoted context omitted.

I don't want the popularity we once had. The same people who wrote unreadable, unmaintainable perl went on to do the same sort of damage in PHP, then python, then ruby/rails, and now node.js/go. They were never a net positive to the community, and I'm not sorry to see them causing problems for somebody else. (and before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code tha…

With python is not the same. Even if the developers is truly bad and do a mess, is a decipherable mess. Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

Could provide a example on python of non-intentional bad code, like the kind that could be write by a perl coder, that make them not understand it a week later?

Because that is the issue I was talking about is rare in python. Is true that is possible to write bad in any language, but certainly is harder in some of them

Re: Why Perl Didn't Win

#148

Post by mst » Tue, Jun 10, 2014, 12:31 AM UTC

steveklabnik wrote: post #129

mst wrote: post #90

Earlier quoted context omitted.

ruby is awesome until I want OO ... then I get about an hour in and find that I've got to write 5x as much boilerplate as I would under Moose/Moo, and there's no proper trait/role system, and then I get annoyed and go back to perl. If ruby had OO as good as Moose, I'd seriously consider switching. Sadly the projects to port Moose to ruby never seem to get finished.

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 old-school perl style,

    sub new {
      my ($class, $args) = @_;
      my $new = bless({}, $class);
      $new->_init($args);
      return $new;
    }

    sub _init {
      my ($new, $args) = @_;
      die "foo is required" unless exists $args->{foo};
      $new->{foo} = $args->{foo};
      if (exists $args->{bar}) {
        $new->{bar} = $args->{bar};
      }
    }

    sub foo { $_[0]->{foo} }
    sub bar {
      my ($self) = @_;
      unless (exists $self->{bar}) {
        $self->{bar} = $self->_build_bar;
      }
      return $self->{bar}
    }

    sub _build_bar {
      Some::Logic::here();
    }

So far as I'm aware, ruby provides 'attr_reader' which would generate the 'foo' method for me, and of course the above 'new' is built-in.

However, again so far as I'm aware, I'd still have to write the bar() lazy/build accessor, and an initialize() method to do the equivalent of '_init' - and name _build_bar by hand, which is less of a big deal but turns out to be really quite nice.

Plus I'm unaware of any ruby equivalent for the Class::Method::Modifiers CPAN module, although I'd imagine that's pretty easy to write and wouldn't be surprised if there's a gem somewhere that I've missed.

In fact, there's a MooseX gem that brings some of this syntax to ruby already, which suggests that it isn't already there anywhere else or at least that that gem's author didn't find it either; next time I play with ruby I intend to do so with the assistance of said gem and maybe that'll solve my problem, but I'm open to being told I'm doing it completely wrong - this isn't me harshing on ruby so much as complaining that an otherwise rather pretty language isn't something I can enjoy writing and I'd like to fix that.

Re: Why Perl Didn't Win

#149

Post by ghshephard » Tue, Jun 10, 2014, 2:57 AM UTC

kbenson wrote: post #135

ghshephard wrote: post #132

Earlier quoted context omitted.

It's an interesting perspective, but, seriously - for the life of me, I struggled every time I wanted to declare/parse/initialize an AoH or HoA on perl. And I'm not engaging in hyperbole when I said that my code was basically completely foreign to me a week after writing it. Obviously developers (which I am not), and people with more discipline and structure, and write eminently readable and maintainable perl code -…

That's interesting, because defining an AoH or HoA in Perl is almost identical to how you would do it in Javascript, which is to say it looks a lot like JSON. If it was the access and assignment semantics, the normal case is also fairly straightforward; use curly braces for hash/dict keys, square brackets for array indices. E.g. my %data = ( foo => [ { bar => 10, baz => 12 }, { bar => 20, baz => 13 }, { bar => 30, ba…

I'll admit to not having looked at it for about 12 years, and, of course, I'm not saying I couldn't figure out after 2-3 minutes over looking over the pattern, but it just never flowed the way it did with Python for me.

   data ={}
   data['foo']= [
      {'bar':10,'baz':12},
      {'bar':20,'baz':13},
      {'bar':30,'baz':14}
   ]
   print data['foo'][2]['bar']
   data['foo'].append({'bar':40,'baz':15})

   for x in data['foo']:
      print x['bar']

Maybe it had something to do with indices always being [] brackets and {} only being used to define the dict structure. Or maybe it got easier sometime in the last 12 years? Or, maybe you could onto something, and having come pre-primed with knowledge hashes/arrays, I just picked up python more quickly.

Anyways, it was just a personal story told as well as I could remember it.

Re: Why Perl Didn't Win

#150

Post by TheMiller » Tue, Jun 10, 2014, 3:36 AM UTC

sillysaurus3 wrote: post #48

TheMiller wrote: post #39

Earlier quoted context omitted.

Ahd in Common Lisp, EQ, EQL, EQUAL, and EQUALP. See http://www.nhplace.com/kent/PS/EQUAL.html for an explanation of why.

Mistakes from other languages are still mistakes. One could try to call them tradeoffs rather than mistakes, but then you'd have to explain why the programmer benefits from such circuitous thinking.

They're not mistakes; read the article. "Equality" is not the singular, unambiguous concept that many programmers think it is.