Live data from Hacker News

Why Perl?

bits.shutterstock.com

71–80 of 118 posts

Re: Why Perl?

#71
post #69
post #60

Earlier quoted context omitted.

> proper function arguments my ($a, $b, $c) = @_; # this works Or I can do things like my ($first, @rest) = @_; giving me features which require all manner of annoying syntax in Python. > exceptions http://search.cpan.org/~nilsonsfj/Error-TryCatch-0.07/lib/Er... or just eval and see what the output is. > objects Edit: I was being an asshole Perl has a decent object system out of the box and Moose for those times when…

> giving me features which require all manner of annoying syntax in Python def foo(first, *rest): vs sub foo{ my ($first, @rest) = @_; ?

use Method::Signatures;

func set (Str $key, Int $val) {

Re: Why Perl?

#72
So if I compile a busybox-like crunched binary with a variety of "do one thing well" UNIX utilities, including sh itself, and then I write a shell function that only calls this single binary it its various incantations and uses pipes and temporary files residing on tmpfs or mfs (instead of reading entire files into memory the way perl does), and this binary used like this can do all that Perl can do, why should I use Perl?

That's my question.

Re: Why Perl?

#73
Honestly, I am completely unsure why we are discussing this article, or why it showed up in a place like HN. It is clearly based on shutterstock's agenda in acquiring perl developers.

I coded perl full-time for a year, straight up, for 10+ hours a day -- using it as the glue to hold a rudimentary distributed system together.

To show that I myself am not biased, I will admit Perl has a lot of nice things, but it also has a lot of undesirable things. This article only concentrates on the former (and doesn't even focus on what could arguably be the right nice things to speak of).

Re: Why Perl?

#75
post #69
post #60

Earlier quoted context omitted.

> proper function arguments my ($a, $b, $c) = @_; # this works Or I can do things like my ($first, @rest) = @_; giving me features which require all manner of annoying syntax in Python. > exceptions http://search.cpan.org/~nilsonsfj/Error-TryCatch-0.07/lib/Er... or just eval and see what the output is. > objects Edit: I was being an asshole Perl has a decent object system out of the box and Moose for those times when…

> giving me features which require all manner of annoying syntax in Python def foo(first, *rest): vs sub foo{ my ($first, @rest) = @_; ?

  >>> def foo(first, *rest):
  ...  print first
  ...  print rest
  
  >>> foo([1,2,3])
  [1,2,3]
  ()
*

  sub foo {
    my ($first,@rest) = @_;
    print $first . "\n"; 
    print @rest;
  }

  foo (1,2,3);

  1
  23
*

It's probably my Python deficiency. My claim that Python's syntax was going to be uglier is probably wrong, but I think the claim that Perl's is appreciably worse is also wrong. We can all get along!

Re: Why Perl?

#76

Earlier quoted context omitted.

> The great downfall of Perl is that it's slow: What about Perl6 and LLVM? My personal experience with Perl5: - It has incomparable expressiveness. Only APL is more expressive. But more expressiveness makes source code less readable. - Perl's regexp engine is the best - no doubt about it. - I would never use Perl for big projects. Its odd syntax ($, sometimes %,... before variable names etc.) is terrible for long ter…

What about [Perl 6] and LLVM? No Perl 6 implementation is mature enough to use for practical purposes. LLVM probably won't help Perl 5, because Perl 5 lacks sufficient type information, and because LLVM's design really seems to want static languages. See also the JVM and the CLR. Its odd syntax ... is terrible for long term maintainability. I would never attempt to maintain code written in a language I don't know.

> I would never attempt to maintain code written in a language I don't know.

I know Perl 5 well enough but will my successors also? Is Perl still rising? I don't think so.

Re: Why Perl?

#77
post #50

Earlier quoted context omitted.

yes, but the point is if the utility provided by these "dists" would be mostly useless for other languages, then it's hardly honest to use said feature to promote CPAN (and therefore perl) against other languages. the review system is a questionable advantage too, as I don't want to go digging through 16 SMTP packages to find the best one, and especially as I suspect most people install CPAN modules through the comma…

> yes, but the point is if the utility provided by these "dists" would be mostly useless for other languages, then it's hardly honest to use said feature to promote CPAN (and therefore perl) against other languages. Jeeze, you're barely making any sense. I have to wonder if you're trolling here. My point was about the utility of the ecosystem, which is useful for any language. The dists i mentioned are just examples…

Maybe I can put this arguement to rest.

It doesn't matter how competant your product is (CPAN) if you aren't delivering what the market wants.

Yes, CPAN provides a utility in the ecosystem, but most users do not use the extra features that CPAN provides over something like PyPi.

And even in the cases where there is a feature overlap (e.g. repository storage and breath), after a certain point things are "good enough" and theres a marginal return for adding more.

Does it matter if there are 17 SHA1 implementations on CPAN and 3 on PyPi? Not really, since you only need 1 good implementation. In fact it could be argued that having more implementations is worse due to paradox of choice.

Re: Why Perl?

#78

Earlier quoted context omitted.

What about [Perl 6] and LLVM? No Perl 6 implementation is mature enough to use for practical purposes. LLVM probably won't help Perl 5, because Perl 5 lacks sufficient type information, and because LLVM's design really seems to want static languages. See also the JVM and the CLR. Its odd syntax ... is terrible for long term maintainability. I would never attempt to maintain code written in a language I don't know.

> I would never attempt to maintain code written in a language I don't know. I know Perl 5 well enough but will my successors also? Is Perl still rising? I don't think so.

I know Perl 5 well enough but will my successors also?

That sounds like a hiring and training question.

Re: Why Perl?

#79

Earlier quoted context omitted.

> yes, but the point is if the utility provided by these "dists" would be mostly useless for other languages, then it's hardly honest to use said feature to promote CPAN (and therefore perl) against other languages. Jeeze, you're barely making any sense. I have to wonder if you're trolling here. My point was about the utility of the ecosystem, which is useful for any language. The dists i mentioned are just examples…

Maybe I can put this arguement to rest. It doesn't matter how competant your product is (CPAN) if you aren't delivering what the market wants. Yes, CPAN provides a utility in the ecosystem, but most users do not use the extra features that CPAN provides over something like PyPi. And even in the cases where there is a feature overlap (e.g. repository storage and breath), after a certain point things are "good enough"…

> Yes, CPAN provides a utility in the ecosystem, but most users do not use the extra features that CPAN provides over something like PyPi.

How do you know that?

Re: Why Perl?

#80

Earlier quoted context omitted.

> I would never attempt to maintain code written in a language I don't know. I know Perl 5 well enough but will my successors also? Is Perl still rising? I don't think so.

I know Perl 5 well enough but will my successors also? That sounds like a hiring and training question.

> That sounds like a hiring and training question.

Yes, Fortran, APL and Ada had the same questions.

Post reply on HN