Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

31–40 of 157 posts

Re: Why Perl Didn't Win

#32
post #28

I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product). And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then. There were two personal reasons why…

[deleted]

Regexes are actually a great example of a tool that makes it easy to write code that is difficult for you to fully understand later.

Re: Why Perl Didn't Win

#33
post #13

Earlier quoted context omitted.

> For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Great straw-man there. I didn't realise that javac required 500 line methods before compilation. > In which case, the language of mandate doesn't matter much. It's a lot easier to pass two collections to a method in Java than to a sub in Perl.

[deleted]

Your reply makes no sense to me I'm afraid.

> And I didn't realize the well written Perl code compiles equally better.

Equally better?

> And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class.

Come on, seriously. Here's how I open files in Java:

    import com.google.common.io.Files;

    List lines = Files.readLines(new File("/foo"), Charset.UTF8);
Why do you insist on straw-men to back up your arguments?

Re: Why Perl Didn't Win

#34
post #6

Earlier quoted context omitted.

Speak for yourself! (or maybe, for annoying coworkers???) It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though. For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstra…

> For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Great straw-man there. I didn't realise that javac required 500 line methods before compilation. > In which case, the language of mandate doesn't matter much. It's a lot easier to pass two collections to a method in Java than to a sub in Perl.

--- Java ---

List aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably missing some more type stuff in

Map aMap = new HashMap ();

aMap.put( "name", "Joe");

aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la Groovy...

doSomething( aList, aMap);

...

void doSomething( List aList, Map aMap) {

System.out.println( "First: " + aList.get( 0) + ", Name: " + aMap.get( "name") );

}

--- Perl ---

&do_something( [ 1, 3, 5 ], { 'name' => 'Joe', 'ID' => '42 });

...

sub do_something {

my( $list_ref, $hash_ref) = @_;

printf "First: %d, Name: %s\n", ${ $list_ref }[ 0 ], ${ $hash_ref }{ 'name' };

}

------

I'm not seeing that much of a difference in parameter passing, other than the explicit reference/dereference syntax.

Of course Java doesn't require 500 line methods. But the bondage and discipline imposed is independent of whether or not readable code will be produced.

I actually like strongly typed languages for larger programs, but prefer something more fast and loose for smaller ones. TMTOWTDI!

Re: Why Perl Didn't Win

#35
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…

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…

This sort of distinction exists in other languages though: Java has == and equals. OCaml has = and == etc. (Not that Perl doesn't have its issues; but this is very low in that list imho)

Re: Why Perl Didn't Win

#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 again, it's no longer the go to language for projects where C isn't the right choice.

How about Java? It was hot stuff in the 90s and it's still huge today, but it clearly didn't "win".

PHP? We'll be living with legacy PHP code bases for at least 10-20 years but does anyone honestly think this will be the language that the startups of 2025 use?

Programming is both incredibly faddish and incredibly fast paced. Today's new hotness is tomorrow's "dead" language.

Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect we'll see a "Why Ruby Didn't Win" in 10-15 years too.

Re: Why Perl Didn't Win

#37
post #13

Earlier quoted context omitted.

[deleted]

Your reply makes no sense to me I'm afraid. > And I didn't realize the well written Perl code compiles equally better. Equally better? > And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class. Come on, seriously. Here's how I open files in Java: import com.google.common.io.Files; List lines = Files.readLines(new File…

[deleted]

Re: Why Perl Didn't Win

#38
post #6

Write once, read never.

Speak for yourself! (or maybe, for annoying coworkers???) It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though. For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstra…

I can read Perl, but the only way you'll get me to read it is to write a script with bugs in it and force me to debug it. It's fun in a masochistic sort of way. Anyway, Python and Haskell are my languages of choice now.

Re: Why Perl Didn't Win

#39

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…

This sort of distinction exists in other languages though: Java has == and equals. OCaml has = and == etc. (Not that Perl doesn't have its issues; but this is very low in that list imho)

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

Re: Why Perl Didn't Win

#40
post #13

Earlier quoted context omitted.

[deleted]

Your reply makes no sense to me I'm afraid. > And I didn't realize the well written Perl code compiles equally better. Equally better? > And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class. Come on, seriously. Here's how I open files in Java: import com.google.common.io.Files; List lines = Files.readLines(new File…

On the one hand, that's a pretty cool library. (with a function to emulate back-tick into an array)

On the other hand, now I have to go to the Enterprise Committee with a Permission To Install Library Form to get it, since it's not part of the base language. It might well be worth it to use Google's jar, but it's a delaying nuisance.

Post reply on HN