I don't mean the language's syntax per se, though everyone who attends Algol
it's a language that's been around a while, that's accreted new features,
that's showing some limitations of its original design decisions, and that has
tremendous backwards compatibility concerns that make addressing the previous
points difficult. Like Perl, it's a language that's seen a lot of programming
novices pick it up to get things done, but it's also a language that rewards
and lack of ceremony with the potential to make great messes.
Perl through the lens of another language will give you a better perspective on
our favorite little powerhouse of a language.)
couple of additional features (basic lexical scoping, higher order functions,
and method dispatch, not to mention competing implementations with a lot of
effort spent on optimizing away efficiencies inherent in some of the poorest
misfeatures of the language's design).
JS has blatantly stolen some of Perl's better ideas, such as strict
magic string literal in your code).
applications, the language still has a ways to go before it can realize its
The Good Parts as well as libraries like jQuery, which take so much of the pain out of
(Fun fact: I modeled Modern Perl: the book
If the idea of modern Perl has brought new energy into Perl (and I believe
it has) and new perspectives on improving Perl 5 (and I believe it has),
perhaps some of the lessons of the Perl Renaissance are valuable to other
Perl 5 is alive and well thanks to the CPAN. Without the CPAN, it's an interesting
language with some great features and some flaws. With the CPAN, it's a
toolchest full of precision instruments that good programmers can wield to make
gyrations or at least rigorous pattern adherence, which fortunately the
language supports. (I'm aware of npm. It's a
For all of the flaws
with Perl 5's
import() mechanism, the compilation-time
import() led directly to the creation of and
growth of the CPAN. Libraries will happen without explicit language support,
but explicit language support in Perl made something amazing and transformative
use Perl because it's so very well tested and verified. In fact, I believe
testing culture has no parallel in other languages. In a very real way, the
entirety of the CPAN is a smoke testing system for the core language
The closest thing I've seen to a rigorous approach to writing high-quality
Unlike big-A Agile, which is a morass of training and
certification and books with too little focus on delivering successful
projects or little-a agile which is like flossing: something everyone says
they do but you know only happens a couple of times a week, at most, Jim's
test-driven development gets done and actually works.
it'd be in a much better place. Couple that with a better library
ecosystem—one encouraged by the language itself, and....
Reduce Technical Debt
(alternate heading: Reduce Crazy)
countless existing runtimes!" have a point. Waiting for whatever the oldest
version of Internet Explorer you have to support to go away before you can take
advantage of something designed and standardized in recent memory is a real
hassle. (Thanks to Dave's hard work and not mine, ClubCompy supports old versions of IE, but
it's a huge amount of work for little payoff.)
Sometimes you have to keep around the cruft, but you can't limit yourself to
what was valid in old code if it will prevent you from producing new code.
What I wrote in Safety
in (Version) Numbers is still true in Perl, and it's probably true in
to use on a particular piece of code can you explicitly document your
expectations, and only with explicit declaration does the parser have any hope
of figuring out what you mean.
Even if the semantics of features change, the surface syntax of the
language can upgrade slowly and deliberately if and only if programs
written in the language make explicit their requirements.
Put another way, HTTP makes you say
HTTP/1.1 for a reason.
automatic semicolon insertion) and add missing features (trailing commas in
list literals, library use and dependency management, namespacing) with a
strategy like this. For as much as I dislike
"use strict" as a
magic string constant, at least it works.
For as much as people complain that even decent Perl code can be
inscrutable, Perl has copious internal documentation (see perldoc.perl.org for an online version of
the docs which you most likely already have installed on your machine right
now). The CPAN also has strong cultural guidelines for how to document modules
and distributions. Even though these are community guidelines, projects adhere
(I have lost track of how many patches I've sent to rephrase an unclear
piece of documentation or add something missing or even to fix a typo; thank
goodness for Git and Github, I say.)
Building a culture of communication and documentation is not easy, but the
results are wonderful. I expect that any good library I use in Perl has decent
tests, has a working installer, and has at least basic API documentation. I'm
I could write more about community management and expectations, but that's a
non-technical subject with fluffier answers you can guess at anyhow.
Perl's done well and poorly. Stealing our better ideas will help it avoid some
of the problems other languages get caught up in, and refining our best ideas
will give us even better ideas to borrow back from.
Who knows? Maybe together we'll make programming easier, more pleasant, more
reliable, and even more secure.