An excerpt from Higher Order Perl:
3.11
If you’re trying to explain to a C programmer why Perl is good, automatic
memoization makes a wonderful example. Almost all programmers are familiar
with caching techniques. Even if they don’t use any caching techniques in their
own programs, they are certainly familiar with the concept, from caching in
web browsers, in the cache memory of their computer, in the DNS server, in
their web proxy server, or elsewhere. Caching, like most simple, useful ideas, is
ubiquitous.
Adding caching isn’t too much trouble, but it takes at least a few minutes to
modify the code. With all modifications, there’s a chance that you might make
a mistake, which has to be factored into the average time. Once you’re done, it
may turn out that the caching was a bad idea, because the cache management
overhead dominates the running time of the function, or because there aren’t as
many cache hits on a typical run as you expected there to be; then you have to
take the caching code out, and again you run the risk of making a mistake. Not
to overstate the problems, of course, but it will take at least a few minutes in each
direction.
With memoization, adding the caching code no longer takes minutes; it
takes seconds. You add one line of code:
memoize 'myfunction';
and it is impossible to make a serious mistake and break the function. If the
memoization turns out to have been a bad idea, you can turn it off again in
one second. Most programmers can appreciate the convenience of this. If you
have five minutes to explain to a C programmer what benefits Perl offers over C,
memoization is an excellent example to use.
Of course memoization is facilitated by Perl's lexical scoping, closures, the flexibility of its references, and by its powerful containers (hashes, in this case). In Perl, functions are arguably first class objects.
It may also be worth discussing why everyone else has "Perl Compatible Regular Expressions", and what Perl's modern regular expressions can do (new constructs from 5.10 through 5.16, embedded code via (?{...}), named captures, (?(DEFINE) .... ) semantics, and so on.
I also like this paragraph from the preface to Higher Order Perl:
Around 1993 I started reading books about Lisp, and I realized something important: Perl is much more like Lisp than it is like C. If you pick up a good book about Lisp, there will be a section that describes Lisp's good features. For example, the book Paradigms of Artificial Intelligence Programming, by Peter Norvig, includes a section titled What Makes Lisp Different? that describes seven features of Lisp. Perl shares six of these features; C shares none of them. There are big, important features, features like first-class functions, dynamic access to the symbol table, and automatic storage management. Lisp programmers have been using these features since 1957. They know a lot about how to use these language features in powerful ways. If Perl programmers can find out the things that Lisp programmers already know, they will learn a lot of things that will make their Perl programming jobs easier.
(Emphasis added.)
