This was once unthinkable — now I find myself having to defend one of the Monastery's more infamous users.

I could name a few things that aren't purely interpreted and aren't interpreted at every run, such as [a list of XS-based modules]

I am fairly sure that this misses his point: Perl programs are compiled only to an in-memory form; there are no binary artifacts that remain usable even if they cannot be regenerated, as with languages like C. (C is a bad example here because backwards compatibility is maintained, but I do not know of any examples of compiled languages that did what PHP did — or any language other than PHP that did that.)

If your latest C compiler cannot compile your old sources, the old binaries still work; Perl programs have no such binaries. If current perl can no longer load the version of Perl your programs need, your only solution other than rewriting your code is to keep an old version of perl itself around that can load your code.

Put DBI in that list for your previous point too.

You are both correct here. DBI is an XS module, but his argument was centered on Perl's modularity: DBI only exists in your program if you ask for it, while in PHP all available extensions are effectively statically-linked into the interpreter and register their symbols in the single global namespace, a limitation that even Tcl moved beyond years ago.

The Perl language has largely avoided such snares because, as a language, it is minimal.

Compared to PHP maybe, but if you read the grammar it's really not and if you read the Camel it's really, really not.

Perl probably has the most complex grammar of any programming language I know, complex enough that full syntax highlighting in Emacs actually requires a fair amount of Lisp code to fix up what the syntax tables cannot express. As a language, Perl has very, very, vary far from a minimal grammar, but his point seems to have been that the set of builtins is small compared to PHP, where everything that Perl does with XS modules instead has to be provided by yet more builtins.

unless you truly believe that using a platform that's supported for things like bug fixes and security improvements represents no measurable business gain

I have worked in places like that. Managers often do not see that value; they see only "we have to spend all this money 'fixing' something that is not broken why again?" because you are changing a large amount of code for the same feature set.

No, managers do not always see security as "business value", either. There was one system, written in an old PHP4 framework, that kept getting cracked and various bots installed. Management preferred to routinely clean the intrusions off of the server instead of replacing the system with something reasonably secure. Yes, that is insane. No, that was not my call. I no longer work there.

Perl created a lightweight and flexible way to interface with the standard binary libraries upon which we all ultimately depend, without embedding this directly into the compiler/interpreter.

I have no idea what this means.

He seems to be describing XS in that sentence.

Lisp or a Scheme or a Forth or Smalltalk

Arguably, Common Lisp macros are a preprocessor, itself written in Lisp; consider the MACROEXPAND and MACROEXPAND-1 builtins from this perspective. Forth grammar is simple enough that defining procedures can make interesting quasi-syntax that ultimately relies on the Eliza effect, and I do not know enough about Smalltalk to comment. Raku is also notable here; if I understand correctly, there are metaclass-like entities in Raku that can define their own parsing rules, distinct from the main Raku grammar.