I'm not much of a Perl guy (in the past, I used Perl 5 for one-off tasks), and I don't know much about Perl 6, so I don't understand some of the author's finer technical points. I do want to address his point about the "personal language anti-pattern" and how it comes up in Lisp.

It could be that I haven't read enough old Lisp code, but I have never yet seen this problem. Not once. Lispers use macros all the time to extend the language, but the practice has well-established conventions, and every time I see macros at play, they make the code more terse, and therefore much easier to read. Three typical examples. (1) New with- blocks, such as (with-datastore-connection ...), which abstract away recovery boilerplate. (2) New defclass macros, which provide CLOS classes with special functionality (maybe define-persistent-class). (3) New defun macros which define functions with special behavior (maybe define-memoized-function).

Of course macros in the wrong hands are dangerous. A macro called with-open-socket should open and clean up sockets, and if it actually opens a file instead, then the person who wrote it made a horrible blunder. However, this same person will probably do a lot of damage using any tools provided by any language, no matter how restrictive.

I have a feeling that a lot of this "personal language anti-pattern" FUD, which I've seen before, comes from being burned by bad developers wielding C++ and overusing operator overloading. C++ is probably not a useful template for where language programmability leads to disastrous code, because C++ itself has poorly thought-out and confusingly overloaded operators and syntax. Example: I just love that << and >> are both for bit shifting and stream operations, which brilliantly conflicts with nested templates like list<list<int>>, which must be written as list<list<int> >, note the trailing space.

This doesn't scare me. What scares me are tools like PPI. I don't want tools touching my source code. I want a language that makes those tools unnecessary. (Lisp and Perl6 qualify. I don't need my editor to type code for me; I can write language constructs that eliminate that need. Actually, I can do this rather effectively in Perl 5, too.)

What the author sees as a weakness is what many people here see as a strength: tailoring the language to the application.

I don't think I know enough to agree or disagree with the author, but I'm curious to see what people here have to say.

I'm not sure which to be more scared of - perl 6 or the death of our sun.

I am as scared of Perl 6 as I am of the Loch Ness Monster, Bigfoot, and other things that don´t exist...