
The Joy of Perl (1998) - bachmeier
https://www.salon.com/1998/10/13/feature_269/
======
mapgrep
Used to spend a ton of time writing Perl (see username). Moved on to better
designed languages. Which are not hard to find.

There are a few big issues with Perl 5 but the biggest is easily the mess of
references vs flat values. 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. A lot of built in operators expect direct values, eg array ops like
join, push. This is because the ops existed before Perl added complex data
structures — arrays of arrays, hashes of arrays, etc. References were bolted
on in Perl 5 to support such structures. And any code using them will handle
references not direct values. So you have a split. And then a lot of energy is
spent navigating between these two types of variables.

As Steve Yegge said:

“Perl's references are basically pointers. As in, C-style pointers. You know.
Addresses. Machine addresses. What in the flip-flop are machine addresses
doing in a "very high-level language (VHLL)", might you ask? Well, gosh, what
they're doing is taking up about 30% of the space in all Perl documentation
worldwide.”

[https://sites.google.com/site/steveyegge2/ancient-
languages-...](https://sites.google.com/site/steveyegge2/ancient-languages-
perl)

For a taste of this here is how you join an array inside a hash:

join(‘,’,@{$foo->{‘bar’}})

Update - I forgot to say my favorite thing about Perl. The CPAN community.
People talk about the sheer scale of CPAN but my favorite thing about it is
the quality of documentation, at least back when I was using it. Really good
uniform high quality docs. Almost always a great synopsis with multiple good
examples covering real uses cases and gotchas. Then thorough documentation of
functions/methods. My theory is this culture developed because CPAN predates
StackOverflow, github, Google, maybe even search engines. The docs had to be
good.

~~~
pmoriarty
_" 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']

~~~
tasty_freeze
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 problem demonstrated by your
python code, but in addition it has the problem of "is $foo a scalar value or
a reference?"

~~~
jlokier
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.

~~~
kevin_thibedeau
Numbers in Python are referenced objects. Low valued integers get reused to
avoid the bloat of duplicate objects.

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

~~~
heresie-dabord
> I still write Perl to this day

I do too. I use it for solving data-analysis problems in a portable and long-
stable way. To this day, I can still run Perl that I wrote a long time ago.
That's a good investment. I can build data structures in Perl OO that are much
more efficient in memory consumption than other interpreted languages.

Good code and bad code exist in every language -- anyone who has been in the
business for a while knows this.

I would just add that the rejection of sigils and braces is also the rejection
of other very useful and efficient tooling, such as bash and awk.

------
acomjean
We use perl to power some web services that have been running a long time.
It’s a work horse.

I’m ok with it but it is hard to read, I think because there are so many ways
to do everything. it takes a bit to get used to some of the syntax ($@~). I
was told my perl was very c like during a review.

It’s great for text manipulation though.

I just remember Rasmus (of php) talking about how he always expected any
language to take over php but perl made some design decisions that made it
unpalatable to hosting providers.

It’s still my go to for processing large text files.

~~~
agumonkey
PHP rise is a lesson in systemic effects. linguistic wise it had nothing on
perl, the module execution model was another 'less is more'. Crazy in
retrospect.

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

~~~
lizmat
Did Duke Nukem Forever change its name? Perl 6 has. It's called Raku now
([https://raku.org](https://raku.org) using the #rakulang tag on social
media). And it is very much alive and ready for production.

~~~
jlg23
No, but it was so long in the making that I had discovered alternatives and
mastered them.

I still write perl5 sometimes but none of perl6 features convinced me to
install an interpreter anywhere when I already have ruby or python on the
machine.

~~~
lizmat
Too bad. And now it is too late, because Perl 6 has been renamed to Raku
([https://raku.org](https://raku.org) using the #rakulang tag on social
media). Which features _would_ convince you to install Raku?

~~~
jlg23
Which does it offer that are not covered by ruby, python or CL?

I am fluent in a lot of languages and cannot really imagine anything that
could motivate me to upgrade my perl5 black belt to perl6 except for a well-
paid gig that requires it.

~~~
lizmat
Better Unicode support and async/parallel processing primitives that don't
depend on a GIL, are the first things that come up.

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

~~~
collyw
The Perl Cookbook was great for most basic questions and Perlmonks for
anything beyond that. I still miss the discussions in Perlmonks, something
that Stack Overflow is missing.

------
forinti
> it's a completely different beast, a highly complex "scripting" language

I learned long ago to not call my programs scripts, because many people
interpreted (sorry) this negatively.

~~~
ivanhoe
In those days "real programmers" were doing C and ASM, and they anyway
considered all other languages as a joke :P

~~~
wbl
Kernigan didn't! The number of little languages he made is astounding.

~~~
p_l
The "unix way" was full of small languages, sometimes compiled to C.

There's a good reason why parser generators were part of UNIX.

------
superbaconman
Perl isn't so bad once you learn all the little gotchas, but it's not
something I would recommend to anyone unless they're scraping clis. It has too
many foot guns, and the pool of engineers to choose from seems too small.

------
ttflee
I was basically introduced to functional programming through Higher Order
Perl.

~~~
sigzero
That is such a great book.

------
tpmx
After I first got online in 1995, I had noticed that Perl was this thing that
everyone was using to create dynamic HTTP server behavior.

I ended up using what I knew instead: Turbo Pascal + some oddball "wincgi"
interface.

Later I caved and started using Perl, since everyone else was using it. It was
a pretty weird experience. I did my first paid "consulting", for a company
from the tiny place where I grew up, building a "web app" using Perl. This
happened during the first year of university studies. I got paid $12/hour.
That was so much money to me, back then! (I was like 18 or 19.)

This experience is where I grew to hate Perl and learned to love more
structured languages.

A year later in 1997, I ended up working full-time with the
[https://en.wikipedia.org/wiki/Pike_(programming_language)](https://en.wikipedia.org/wiki/Pike_\(programming_language\))
instead. This was essentially a precursor of Dart.

~~~
tpmx
14 years later (2011) I ended up visiting/working with a team that had stayed
with Perl for some time. That was a fascinating experience. They were using
selected "good" parts of Perl, sort of how you can can use the good parts of
any competent dynamic programming language and stay productive, in a small
team. Afaik they're still going strong.

------
dang
A thread from 2012:
[https://news.ycombinator.com/item?id=3728313](https://news.ycombinator.com/item?id=3728313)

~~~
jotakami
Yeah kamaal’s comment on that thread shows just how insanely terse Perl can
be... truly the king of one-liners

------
martinclayton
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.”

------
combatentropy
It soothes me to read that even back in 1998, people were criticizing Perl for
being write only and were considering Python. Trends in programming seem a
little slower, knowing that.

~~~
asveikau
In that time period I remember it being _very_ common to hear Python
introduced in conversation as a perl alternative. That was how I first heard
of it too.

------
jotakami
Oh man, this brings back memories... when this article was written, I was a
high school freshman, and I had just bought _Teach Yourself Perl 5 in 21 Days_
so I could learn how to write my own custom CGI scripts for my geeky personal
webpage. It was my first true programming language, after childhood flings
with BASIC.

Also, I find it humorous how the term “hacker” is used here to refer to
literally anyone who works on computers. I suppose the title of this site
retains that meaning...

------
askar_yu
One of the most insightful pieces from the article:

""" "I realized at that point that there was a huge ecological niche between
the C language and Unix shells," says Wall.

...

"People are always looking for the interstices," says Wall. "They are always
looking for the new ecological niches. And the speed with which you can move
into those ecological niches is really important, because the first person
into a niche is often the winner." """

------
combatentropy
I did not know that Larry Wall wrote patch. I thought it came out with diff.

------
pkrumins
I can't imagine programming in any other programming language than Perl.

~~~
benbristow
I can’t imagine programming in Perl anymore. I did a bit in a previous job and
it was a ball ache trying to remember the syntax and all it’s quirks.

I don’t know why you’d want to use it over other popular scripting languages
like JS/Ruby/Python. All have more active communities.

AWS don’t even support Perl

~~~
ryl00
Non-web developer here... I've personally never seen any Ruby in anything I've
ever worked on (only personal, limited anecdote, of course).

Python's nice for gluing more performant native code together (perl XS isn't
as straightforward IME). But for text processing I'll take perl every time.

~~~
benbristow
Ruby definitely has its niche in web development mainly due to Rails, Jekyll
and Sinatra. Quite a weird choice for other things. Pretty sure Homebrew on
Mac uses it.

It’s not the most performant of languages (although it’s definitely getting
better).

~~~
sdegutis
Homebrew is the only thing I think Ruby is perfect for. It's just a DSL for
describing how to fetch and build a program, like Makefiles but more
convenient.

~~~
benbristow
Chef is the same kinda thing but for managing infrastructure (like Ansible for
Python & Cake for .NET)

[https://www.digitalocean.com/community/tutorials/configurati...](https://www.digitalocean.com/community/tutorials/configuration-
management-101-writing-chef-recipes)

------
mastrsushi
Perl comes from the days when interpreted programming languages were invented
as concrete solutions to general problems. Now we have reusable frameworks as
concrete solutions, whereas high level languages have more general use cases.

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

------
wwarner
The thing about perl I still miss is the metaprogramming. It's really amazing
to be able to launch a program that writes the "last mile" of code before it
starts taking requests.

~~~
pflanze
You can do a lot in Perl with just closures and setting package slots etc.,
that you would need to use macros for in say Lisps.

Still, I agree, there's no real AST and string eval is unsafe and parsing is a
real issue. I've started
[https://metacpan.org/pod/FP::AST::Perl](https://metacpan.org/pod/FP::AST::Perl)
(very unfinished) to solve the code generation issue and hope to generate an
AST from the op tree (not sure how feasible, will see). Feel free to tell me
(here or offline) what your use case is and whether that module might suit
you.

~~~
lloeki
> There’s no real AST

Perl cannot be statically parsed!

> Theorem: Parsing Perl 5 is Undecidable

[https://www.perlmonks.org/index.pl?node_id=663393](https://www.perlmonks.org/index.pl?node_id=663393)

~~~
pflanze
> Perl cannot be statically parsed!

My usage (modifying syntax / extending the compiler when _running_ Perl
programs) doesn't need static parsing. What I need is a way to leverage the
existing infrastructure in the interpreter for parsing in a way that's
compatible with most modules/usages. AFAIK the parser in perl goes directly
from source to an OP tree (modulo running other Perl code on the go that
modifies the parsing state, which is the reason for the undecidability), it
would be cool if it didn't go to an OP tree but something more AST instead,
but it might not be feasible to change perl to do that because of modules
working on the op tree (if anyone wants to help figure out how much this is
true, please do); because of that I'll instead look into converting the op
tree into an AST. I've been told the op tree does have additional info that
might make that feasible. Notabene, B::Deparse exists, which is somewhat of a
proof that this works, although there are limitations, whether they matter is
part of what I need to find out.

~~~
lloeki
Haha, my comment was definitely tongue in cheek ;) I fully expect most of
properly written Perl code to be statically parseable into an AST, save for
pathological cases (and I fully expect a proper rubocop-like Perl linter to
highlight such ambiguities, and would reject them in any sensible project)

------
askar_yu
Such a well written article. It was amusing that an article from _1998_ ends
with a footer with author's (Andrew Leonard) Twitter ref.

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

~~~
tashi
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.

~~~
gerikson
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.

~~~
shagie
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

~~~
boring_twenties
alpine doesn't "have awk installed," it's just that BusyBox that has an awk
implementation. For real GNU awk you have to install the gawk package.

