Greenspun's 10th rule in Perl?

Question

Greenspun's Tenth Rule of Programming is a common aphorism in computer programming and especially programming language circles. It states:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

The questions are,

1. Would you consider this to be true of Perl interpreter? Only objective arguments please (e.g. which features of Common Lisp are implemented within the interpreter)

2. Independently, does there exist a Lisp (or at least a n ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp) implemented entirely in Perl?

Answer 1

You might like the preface (as well as the rest of the book) for Mark Jason Dominus's Higher-Order Perl, whose subject is essentially your question. He says:

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

Mark has many other things to say about Lisp and Perl

So, Perl is already Lisp, practically, but I'd say neither slow nor half. One of the things that Mark points about about the difference between Perl and Lisp, however, is that Perlers deal with unstructured strings (in general) while Lispers deal with structured data whenever possible. Perl can do that, but Perlers tend not to do that.

Answer 2

The problem with that aphorism is that it isn't saying very much. Common Lisp is so complicated and general-purpose that it implements almost any feature a programming language could have. Thus, all it's really saying is that any sufficiently complicated system contains half of all possible features.

And yes, Perl is sufficiently complicated.

Answer 3

I'll leave aside the "slow" and "bug-ridden" parts, because they're basically cheap shots. Nothing prevents a deliberate, formally specified implementation of all of Common Lisp from being slow or bug ridden.

As for the rest, I think it tends to be true, but a lot of the reason for it being true is that Common Lisp provides quite a bit, and C provides so very little. Stuff as basic as hash tables, linked lists and expandable vectors are left up to the user to implement. All the memory management is manual, but you can automate it by doing ref-counting or even by adding a garbage collector. You can roll your own polymorphic OO by stashing function pointers in a struct somewhere and using it as a vtable. You may add an interpreter for a language to let you easily script your application, or ease interaction and testing at runtime.

That's pretty much half of Common Lisp; Perl really provides all of it and some other Lispy features to boot. But it doesn't really seem like that much of a big deal, because one thing that's changed in the 15+ years since Greenspun coined his Tenth Law (while skipping the other nine) is that lots of languages have added that same half of Common Lisp. Guy Steele said that about Java a few years later---it was dragging programmers halfway to Lisp.

Answer 4

1. See »What are the features that Perl shares with Lisp?«. The missing feature is true macros (this discounts source filters and Devel::Declare, which are a poor substitute from the POV of a lisper). Perl 6 has it.

2. MJD provides a practical demonstration of the essential part of Lisp in Perl:
   Perl contains the λ-calculus