The Joy of Perl (1998) • Hacker News Board

Re: The Joy of Perl (1998)

#41

Post by forinti » Sat, Dec 21, 2019, 8:18 PM UTC

scarface74 wrote: post #26

1996 wrote: post #13

Earlier quoted context omitted.

Some workers complains about their tools. Other just use whatever, fix problems, and make money.

Until you need your next job and you see spending 10 years doing Perl was detrimental to your career...

Perl has never been central to nor a requirement of my jobs, but it has always helped me immensely.

-As a web developer, I use it to write all sorts of small webservices and file conversion utilities;

-As a embedded system developer, I used it to integrate with other services in the network;

-As a sysadmin and DBA, I use it a lot to parse all sorts of data.

The downside is that I have to put up with the little jokes and criticisms. Then again, more than once I've been called because I was the only one who could do some job fast enough.

Re: The Joy of Perl (1998)

#42

Post by oblib » Sat, Dec 21, 2019, 8:31 PM UTC

I still use Perl for server side chores, but most all my web app code is JS now and runs entirely in the web browser.

As I recall, back in the mid-late 90s the phrase "there's more than one way to do it" was used a lot in reference to Perl, and that was generally true and made it pleasure to learn and use.

There soon came to be two very divided camps of perl users. There were guys like Randal Schwartz that considered themselves as elite geniuses and hacks like me who asked stupid questions and "made crap".

Coming from knowing nothing about writing code I bought books by Selena Sol and Lincoln Stein and learned a lot. They were very accessible with lots of example code. But Randall's O`Reilly books were just way too perplexing for me to get anything out of them.

I also joined some of the official Perl and Perl CGI mailing lists. Those lists were public but had just few hard core users and then guys like me, who knew almost nothing, came flooding in with lot's of newbie questions and things got pretty vicious. "RTFM" was a common snotty response that gave no help at all.

I made an effort to answer those newbies fast and courteous but they'd still often get just beat to shit by the snobs there. In fairness, Larry Wall was always very welcoming and encouraging to dabblers and beginners like me, and he did work hard to discourage snobbiness, but somehow those perl mailing list just attracted hardasses. Larry was never on any of the lists I joined.

If you go read some of those old emails you can see it.. I started the perl.macosx mailing list around March 2001 after getting chased off the "macperl" list for asking a question about perl on OSX when it first came out. I tried to keep things friendly on the new list and it was a lot of fun until the snobs showed up there too about a year later. I finally just unsubscribed after a just few more years.

It wasn't long after I left that participation in those email lists started really falling off. Now they're barely used at all. Can't blame it on Larry Wall though. I still love that guy.

Re: The Joy of Perl (1998)

#43

Post by jlg23 » Sat, Dec 21, 2019, 9:01 PM UTC

If perl6 had not been the Duke Nukem Forever of programming languages, I'd probably still be coding in Perl, but Ruby just came along and offered a very similaly spirited playground. And then I found lisp and realized that my late perl code was very lisp-ish anyway.

Re: The Joy of Perl (1998)

#44

Post by gerikson » Sat, Dec 21, 2019, 9:42 PM UTC

tashi wrote: post #38

ocschwar wrote: post #22

I bet some younger HN readers are looking at this and wondering if the popularity off Perl at this point is primarily sentimental associations that older devs have with the early days of the Web when they could find artsy ways to explore a new emerging medium. It is. Very much so.

I disagree completely, but I'll accept that that's partly a matter of taste. But the thing that shocks me most about how completely Perl has fallen out of fashion is that nowadays sysadmins will write a hundred-line bash script rather than a five-line Perl script because of the theory that Perl is hard to read.

That could be, but I've also noticed a sort of purism where the shell script is ideal because it can be run on any system.

(Of course, using bash for the shell isn't a good choice because you can't rely on bash being installed).

Personally I reach for Perl as soon as any sort of arithmetic is involved. And even if starting with find(1) is the first choice, it's worth getting to know modules like File::Find because they're way more powerful.

Re: The Joy of Perl (1998)

#45

Post by vaporland » Sat, Dec 21, 2019, 9:59 PM UTC

Amazing - I did not realize that this article was 21 years old until 3/4 of the way through reading it.

Re: The Joy of Perl (1998)

#46

Post by jlokier » Sat, Dec 21, 2019, 10:12 PM UTC

ben509 wrote: post #39

pmoriarty wrote: post #24

Earlier quoted context omitted.

"Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct value. Perl does." If you don't think about these things in python, you're going to be scratching your head when you see something like this: >>> foo = ['a','b','c'] >>> bar = foo >>> bar[1] = 'z' >>> foo ['a', 'z', 'c']

It's incredibly confusing if you naively use a list as a default argument, e.g. def foo(some_list=[]): ... some_list.append(3) ... Since the default is constructed when the function is evaluated, it's the same list, but only when the default is used. Or the n00b's attempt to use lambdas: def list_of_lambdas(x): result = [] for n in range(x): result.append(lambda m: n + m) return result for func in list_of_lambdas(3):…

Yes indeed, that's a bug-prone misfeature of Python.

Perl and JavaScript both get default arguments right: They make a new array on each call.

Perl and JavaScript also get the for-loop closures right as well. In Perl, "for (my $n = ...)" and in JavaScript "for (let n = ...)" will both create a new "cell" each time around the loop, so closures work as expected.

(However, MSIE's version of "let" doesn't create a new "cell" each time, and this can be a source of difficult to see event callback bugs; best transpiled out.)

Re: The Joy of Perl (1998)

#47

Post by jlokier » Sat, Dec 21, 2019, 10:28 PM UTC

tasty_freeze wrote: post #31

pmoriarty wrote: post #24

Earlier quoted context omitted.

"Python, Ruby, JavaScript and many other dynamic languages do not make the programmer think about whether you are going to pass a data structure like an array or hash as a reference or direct value. Perl does." If you don't think about these things in python, you're going to be scratching your head when you see something like this: >>> foo = ['a','b','c'] >>> bar = foo >>> bar[1] = 'z' >>> foo ['a', 'z', 'c']

No, it isn't the same. I'm no language lawyer, but this is my understanding of it. In python, $foo is a reference. It might be a reference to a scalar value, or list, or hash, etc, but it is a reference. The code you wrote might cause confusion for people who don't understand the python model. In perl, $foo might be a scalar value, or it might be a reference to a value of some kind. Perl has this exact same type of p…

Imho that's not really correct, or at least misleading.

In Python, variable "foo" behaves like its value is a non-reference if the value is what some languages call "unboxed", for example numbers and strings.

That's exactly the same as Perl.

Technically, Python shares objects even in the case of numbers being copied around, and the object's address is visible with the "id()" function.

(I emphasise address because that was a criticism of Perl in another comment, but everything in Python is memory with an address as well and the criticism ought to apply more strongly because even numbers need memory allocation.)

However, the fact that numbers are immutably-shared when assigned in Python doesn't make their behaviour any different from numbers being assigned in Perl (apart from the obscure id()). It's hard to imagine what "problem" is created in Perl by the fact that numbers and strings are non-references. Most other languages do like Perl.

With strings, Perl does both according to a performance heuristic: Sometimes it copies, sometimes it shares. This is completely safe because you can't tell the difference at language semantics level anyway.

Re: The Joy of Perl (1998)

#48

Post by martinclayton » Sat, Dec 21, 2019, 10:40 PM UTC

I met a long-time collaborator of mine over drinks a while back, and we talked about Perl.

“It’s my second language”, he said.

“What’s your first?”

“English.”

Re: The Joy of Perl (1998)

#49

Post by marghidanu » Sat, Dec 21, 2019, 10:47 PM UTC

I still write Perl to this day on my personal projects and try to contribute as much as I can to CPAN. After more than 10 years it’s still my go to language. I think a lot of people are afraid of learning Perl just because they heard is hard to write or they came across some horrible code, I believe PHP suffered from this not so long ago. If you want a taste of using a really good web framework have a look at Mojolicious, Moose and friends introduce some really nice concepts around objects, there are many other interesting packages. The consistent documentation and testing around most of the packages on CPAN makes working with modules a breeze. Other languages like Python or Node.JS could learn a lot from the Perl community even to this day. The are just a few rules for writing code in Perl, the expresivity of which a lot of people are complaining it’s actually the Perl’s strong points.

Re: The Joy of Perl (1998)

#50

Post by shagie » Sat, Dec 21, 2019, 10:52 PM UTC

gerikson wrote: post #44

tashi wrote: post #38

Earlier quoted context omitted.

I disagree completely, but I'll accept that that's partly a matter of taste. But the thing that shocks me most about how completely Perl has fallen out of fashion is that nowadays sysadmins will write a hundred-line bash script rather than a five-line Perl script because of the theory that Perl is hard to read.

That could be, but I've also noticed a sort of purism where the shell script is ideal because it can be run on any system. (Of course, using bash for the shell isn't a good choice because you can't rely on bash being installed). Personally I reach for Perl as soon as any sort of arithmetic is involved. And even if starting with find(1) is the first choice, it's worth getting to know modules like File::Find because th…

It is unfortunate that those sysadmins are then failing to just go full on awk then rather than those shell scripts.

Even alpine has awk installed. docker run --rm alpine awk