Live data from Hacker News

Why Perl?

bits.shutterstock.com

81–90 of 118 posts

Re: Why Perl?

#81
post #75
post #69

Earlier quoted context omitted.

> 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!

Exactly, it's a trade-off. Making the other side of the fence not impossible to reach, you just have to hop a little. Perl can easily be made nicer and Python can surely with ease be made more flexible.

Re: Why Perl?

#82

Earlier quoted context omitted.

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.

If only they had a CPAN growth rate to measure.

Re: Why Perl?

#83

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"…

In short, you're arguing against the long tail...

Let me add also mine anecdotal experience from yesterday:

I looked for a good SQL parser/evaluator in Python (which I partly use at work). There might be one, but I didn't find any. It is easy to find on CPAN. (And this is hardly an unusual request.)

Re: Why Perl?

#84
post #75
post #69

Earlier quoted context omitted.

> 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!

Not sure I follow you. Your python example is very explicitly passing a _single_ arguement, a list of three items. If you call it the same way you call the perl code, you'd have the same result.

Re: Why Perl?

#85

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…

* [If] ... this binary used like this can do all that Perl can do...*

If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.

Re: Why Perl?

#86

Earlier quoted context omitted.

> That sounds like a hiring and training question. Yes, Fortran, APL and Ada had the same questions.

If only they had a CPAN growth rate to measure.

"compilable perl" has been "on the horizon" for 15 years. I suggest you not measure it by that rate.

Re: Why Perl?

#87

Earlier quoted context omitted.

If only they had a CPAN growth rate to measure.

"compilable perl" has been "on the horizon" for 15 years. I suggest you not measure it by that rate.

I don't know what "compilable Perl" has to do with the CPAN. "Compilation" suggests some sort of execution and distribution strategy, while the CPAN is an archive of resuable code and the surrounding ecosystem of dependency management, documentation, bug tracking, history, annotation, and comprehensive testing around it.

I'm suggesting that if you measure the amount of code submitted to the CPAN, the number of authors, the frequency of updates, and the freshness of versions, you'll see that Perl 5 is far from stagnant.

Re: Why Perl?

#88

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…

* [If] ... this binary used like this can do all that Perl can do...* If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.

It's actually a very small job.

The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it.

If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise.

I want to learn Perl. But I just cannot find the motivation because I never need more than what UNIX gives me.

Re: Why Perl?

#89

Earlier quoted context omitted.

* [If] ... this binary used like this can do all that Perl can do...* If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.

It's actually a very small job. The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it. If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities be…

You wrote a website with only the shell and unix utilities?

Re: Why Perl?

#90

Earlier quoted context omitted.

It's actually a very small job. The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it. If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities be…

You wrote a website with only the shell and unix utilities?

I write small, simple shell functions using a single busybox-like binary that do the same things as Perl modules. I store the shell functions in a local repository and load/unload them as needed. I make "programs" by combining different functions.
Post reply on HN