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.<p>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).<p>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.<p>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.