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

91–100 of 157 posts

Re: Why Perl Didn't Win

#91

Post by mst »

mantrax5 wrote: post #29

In one of the WWDC sessions an Apple engineer was adamant one should never choose terseness over clarity, because every line of code is written once by one person, but read many times by many people. And funny enough Objective-C is taking this quite seriously, being a very verbose language (the new Swift language also keep the verbose method names, enums and properties). While Perl is exactly the opposite. There's a…

Most of the modern perl ecosystem is libraries built by substantial teams - it's a lot different now than a decade or so ago.

The Modern Perl dialect is basically what came out of the new wave of CPAN (Enlightened Perl) movement which is all about using perl's flexibility in a way that scales to larger teams.

Sadly, every attempt to explain this to people not already writing it results in a deluge of 'write-only' jokes and nobody bothering to actually look at the code, so while the technical capacity is there, the pop culture nature of programming language choice means people generally never realise.

Re: Why Perl Didn't Win

#92

Post by scrollaway »

mst wrote: post #79
amenbrother wrote: post #15

Earlier quoted context omitted.

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/nu…

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…

I did not downvote you, but comparing a language to Bash is certainly in no way flattering, and I would definitely not put it in the "good defense analogy" category.

Re: Why Perl Didn't Win

#93

Post by mst »

EdwardDiego wrote: post #58
Roboprog wrote: post #45

Earlier quoted context omitted.

I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier. No final "right" or "wrong" choice for all use cases.

> I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier. I would agree. It's the same issue Scala faces IMO - it doesn't have to be a complex maze of types and implicit conversions and implicit values, you can, if disciplined, write very understandable and clear Scal…

With great power comes great capacity to write overly clever unmaintainable crap.

Re: Why Perl Didn't Win

#94

Post by mst »

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

I did not downvote you, but comparing a language to Bash is certainly in no way flattering, and I would definitely not put it in the "good defense analogy" category.

Comparing a final conditional in a systems-style script that is then calling another program, shell-style, to bash, which is the most common language where you'd execute a conditional then call another program, seems reasonable.

Maybe not flattering, maybe not a good defense, but I think under the circumstances an acceptable comparison.

Re: Why Perl Didn't Win

#95

Post by mercurial »

cubancigar11 wrote: post #66
amenbrother wrote: post #47

Earlier quoted context omitted.

Those languages are far more maintainable and their communities have far more respect for practices which prevent programming errors. I don't particularly care how many forms of equality or comparison a language has as long as the compiler or runtime is capable of telling me the particular one I'm using is probably wrong. If == can't be used with strings the damn interpreter should tell me so instead of silently and…

You should have used strict and warnings. RTFM, I know. Btw, Java will silently compare references instead of value. Learning a language != increasing vocabulary.

Tell me about it. At least Python can make the difference between equality and identity, while a non-overriden equals() in Java actually means "is X Y?" instead of "is X equal to Y?".

Re: Why Perl Didn't Win

#96

Post by amenbrother »

aphexairlines wrote: post #78
amenbrother wrote: post #47

Earlier quoted context omitted.

Those languages are far more maintainable and their communities have far more respect for practices which prevent programming errors. I don't particularly care how many forms of equality or comparison a language has as long as the compiler or runtime is capable of telling me the particular one I'm using is probably wrong. If == can't be used with strings the damn interpreter should tell me so instead of silently and…

The interpreter does tell you. $ perl -e 'use warnings; use strict; print "content" == "foo", "\n"' Argument "foo" isn't numeric in numeric eq (==) at -e line 1. Argument "content" isn't numeric in numeric eq (==) at -e line 1. 1

Thanks - I'll try to remember that if I ever have to touch perl again.

Re: Why Perl Didn't Win

#97

Post by spacemanmatt »

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…

I have been so very burned by CPAN module quality in the past. Claims to CPAN 'minimal code quality' ring hollow with me. Apache's collection of Java code is MUCH higher quality on average.

Re: Why Perl Didn't Win

#98

Post by spacemanmatt »

oalders wrote: post #21
jacques_chester wrote: post #5

The final section, which I was anticipating for the whole article, was essentially this: http://en.wikipedia.org/wiki/Osborne_effect What killed Perl? An imaginary Perl did.

>> What Killed Perl? The article is entitled "Why Perl Didn't Win", not "Why Perl is Dead". Perl hasn't been killed.

It's dead to me.

Re: Why Perl Didn't Win

#99

Post by pnathan »

Another perspective: Perl lost because the culture of internet software development moved away from hackers who grokked humor and cleverness towards team-driven business application developers who preferred synergistic framework solutions.

Re: Why Perl Didn't Win

#100

Post by nly »

unexistance wrote: post #64
ww520 wrote: post #17

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.

1. True 2. Linux Admin? maybe. UNIX admin? I'd say Perl still on, as it's installed by default (yeah not popular anymore, but a LOT of legacy system still run) 3. cannot comment, as never used new Perl, since UNIX still shipped with old-ish Perl maybe, just maybe it's not just winning & losing :D every language will find it's place eventually.

On 2: Still 193 unique files in /usr/bin on my system containing the string '/usr/bin/perl'. Only 51 containing '/usr/bin/python'.
Post reply on HN