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

111–120 of 157 posts

Re: Why Perl Didn't Win

#111

Post by Joeri »

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…

Sane defaults are a cornerstone of good language and framework design because for better or worse people don't read the manual before they start using something. If a compiler doesn't do the right thing by default (throwing errors on problems a new user is likely to cause), it's a bad compiler.

Re: Why Perl Didn't Win

#112

Post by oneeyedpigeon »

oneeyedpigeon wrote: post #84
kamaal wrote: post #60

Earlier quoted context omitted.

I think the definition of 'winning' people use around here is, if start ups think its a trendy technology to use. So you will see all these new companies stop using a particular language, and then when some conference happens you will see talks around the older technologies have dried out, while people are giving talks on the newer set of technologies. Its then when you see articles/rants/blog posts on the lines 'Wha…

Can you fix the bug in "$current_years - 5 years back", please - it's bothering me. If you're going to talk in code, at least get it right ;-)

Oh, come on downvoter - I put a ";-)" at the end of that. There's literally zero tolerance for anything lighthearted here, isn't there?

Re: Why Perl Didn't Win

#113

Post by anko »

nly wrote: post #100
unexistance wrote: post #64

Earlier quoted context omitted.

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'.

are you saying python is more efficient? :P

Re: Why Perl Didn't Win

#114

Post by anko »

mst wrote: post #88
steven2012 wrote: post #46

I gave up on perl when I saw the following code: $x = $src[$src]; I was confused as hell until I realized that arrays and scalars had different namespaces. That, along with the fact that "or" and || had different precedences were what ended Perl for me. I'm not saying that wonderful code can't be written by Perl, it just wasn't the right language for me in that I hate memorizing one-off rules, which Perl seemed to ha…

If you only want a single namespace for everything, I recommend sticking to only scheme (note: I really love scheme for that property, I'm not being sarcastic). Once you learn -enough- perl, there's a sort of overall consistency that's actually really nice, but there's a gap ... simple perl is very simple, but mid-level perl is generally a mess until you get to the expert level, and then its awesome again. There's pr…

I couldn't agree more, and that's why I hate perl.

That gap in the middle makes it really hard to hire perl developers unless they are experts. It's hard to find experts because they think perl code is a mess before they get there.

It's probably the main failing of perl.

Re: Why Perl Didn't Win

#115

Post by thorin »

kamaal wrote: post #49
icambron wrote: post #41

Earlier quoted context omitted.

I agree with your point but not the scare quotes. Yes, the field evolves, priorities change, and languages inevitably fall out of favor. However, that losing is inevitable doesn't make the losing less real, and I think it's still very useful to think about why a language fell out of favor. What changes in priority left the language behind? What could have made it more adaptive? What does that say about current progra…

>>What changes in priority left the language behind? I'm not an expert but let me try. The most common of all is abstraction level at which problems are looked increase with time. Once the problems you solve get complicated increasingly over time, you run into a situation where your tools have to provide syntax and semantics to deal with that. While the previous complicated things get trivial and easier to deal with.…

Have you used Java recently? The last few versions are showing consistent improvement with lambas, date library etc. I can't think of this happening successfully in other languages but it seems to be working well in Java. Also JavaEE and Spring framework have improved massively and the amount of code (and configuration) to do stuff is reducing all the time - much more in the style of rails/django.

I think Java (and C#) will be here for a long while where the enterprise jobs are. Javascript will continue to be popular as long as it's the only real choice in the browser. After that - who knows?

Re: Why Perl Didn't Win

#116

Post by BugBrother »

Joeri wrote: post #111
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…

Sane defaults are a cornerstone of good language and framework design because for better or worse people don't read the manual before they start using something. If a compiler doesn't do the right thing by default (throwing errors on problems a new user is likely to cause), it's a bad compiler.

What sane defaults are will change over the years.

Perl kept amazing backwards compatibility by adding extra statements to modify how it worked. So "use strict;", "use warnings;" and "use ;".

Both new code -- using the best OO system of the scripting languages, extendable syntax, etc, etc -- will run at the same time as most of the old and crufty stuff from before testing took over after the Millennium.

Re: Why Perl Didn't Win

#117

Post by EdwardDiego »

mst wrote: post #83
ghshephard wrote: post #18

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…

I felt much the same way, except in reverse - perl data structures did exactly what I meant, python data structures didn't. I don't think this is a compliment or complaint about either, just a question of different people thinking different way.

I must admit that Perl's autovivification can be nice.

Re: Why Perl Didn't Win

#118

Post by EdwardDiego »

__david__ wrote: post #68
EdwardDiego wrote: post #52

Earlier quoted context omitted.

> List aList = Arrays.asList( new int [] { 1, 3, 5 }); You can drop the inner array, asList takes variable number of arguments. > // I need to check if Java 8 has map literals a la Groovy... Sadly not, IIRC they've backed off from literals towards a Guava style static factory methods, which I'm not thrilled about. > I'm not seeing that much of a difference in parameter passing, other than the explicit reference/deref…

> Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections. It's not really two sets of sigils, it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much—once it sunk th…

> it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much

Fair point. I guess what bugs me is that you can use collections merrily without references until you want to pass more than one collection to a function - or create a collection that isn't flattened - at which point you have no choice.

Re: Why Perl Didn't Win

#119

Post by kamaal »

thorin wrote: post #115
kamaal wrote: post #49

Earlier quoted context omitted.

>>What changes in priority left the language behind? I'm not an expert but let me try. The most common of all is abstraction level at which problems are looked increase with time. Once the problems you solve get complicated increasingly over time, you run into a situation where your tools have to provide syntax and semantics to deal with that. While the previous complicated things get trivial and easier to deal with.…

Have you used Java recently? The last few versions are showing consistent improvement with lambas, date library etc. I can't think of this happening successfully in other languages but it seems to be working well in Java. Also JavaEE and Spring framework have improved massively and the amount of code (and configuration) to do stuff is reducing all the time - much more in the style of rails/django. I think Java (and C…

Perl is actually no different. There are a lot of cool things happening in the Perl universe too. But the problem is, the older issues persist. There is a big legacy baggage to carry, and in the overalls the feature adoption is generally slow.

Re: Why Perl Didn't Win

#120

Post by stcredzero »

twic wrote: post #87
stcredzero wrote: post #19

How does a language win? By being compelling enough to be used for new things. It's not solely a technical concern; it's a concern of the language community and ecosystem. One of the most valuable 4 sentence paragraphs I've read from an HN post in awhile. (Perhaps 3, but the semicolon really separates 2 sentences.)

The semicolon separates two independent clauses, but they constitute a single sentence. When we're thinking about language, clauses are probably a better atomic unit than sentences; clauses are a semantic unit, and sentences are really just a syntactic packaging format for some number of clauses. Just like we should be counting expressions (or something) rather than lines of code.

I'll take that comment as a parody?
Post reply on HN