

Why Perl 6 Scares The Hell Out Of Me - antiform
http://use.perl.org/~Alias/journal/35508

======
gcv
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.

~~~
sarehu
You can perfectly easily write with-foobar functions of any kind, so macros
aren't a win there, except maybe in Lisp where it saves you a parenthesis or
two. You can replice define-memoized-function with

    
    
       (define f (memoize (lambda args ...)))
    

so I don't see what macros gain you there. (Well, they save you from having to
write lambda.) Especially if you're using a language with 'nicer' syntax, like
Haskell:

    
    
        withFile $ \h -> do
          ...
    
        fib = memoize $ \n -> if n <= 1
                              then n
                              else fib (n - 1) + fib (n - 2)
    

Example (2) seems interesting though. And I'd like to see some examples of (3)
that couldn't be so easily overcome. (Granted, my example is rather fake,
since I don't know how you'd implement memoize for general types that only
have a comparison function on them, without resorting to using some IO
operation.)

~~~
shiro
Yes, with nicer closure syntax and/or lazy evaluation, lots of macro use cases
can be eliminated. However, making single definition work as multiple
definitions is a pattern that I haven't find ways other than macros.

For example, think of defenum macro that expands to a bunch of defconstants:

    
    
        (defenum (ONE 1) TWO THREE FOUR (TEN 10))
         =>
        (progn (defconstant ONE 1)
               (defconstant TWO 2)
               (defconstant THREE 3)
               (defconstant FOUR 4)
               (defconstant TEN 10))
    

(Haskell programmers would use types for enum-kind of stuff, but suppose that
you really need to associate numbers to those symbols.)

Or you can go further to name the enum itself, defining conversion functions
between symbolic names and their values:

    
    
        (defenum the-numbers ONE TWO THREE ...)
        =>
        (progn
          (defun symbol->the-numbers (sym)
            (case sym
              ((ONE) 1) ...)))
          (defun the-numbers->symbol (num)
            (case sym
              ((1) 'ONE) ...)))
          (defconstant ONE 1) ...)
    

Without macros, you need to have some procedural interface to modify the
global environment to realize these (which is, imho, worse than macros).

~~~
sarehu
I wasn't asking why macros were useful in general, but thanks anyway.

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

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

~~~
kingkongrevenge
My bet is that his fear is unfounded. It will play out just like Perl 5: Only
smart guys making popular libraries will use the language modification black
magic and it won't be a problem.

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

~~~
LogicHoleFlaw
Well, I guess it depends on which you believe will arrive first.

Anyone taking bets?

~~~
kingkongrevenge
Perl 6 is here now. There are two working implementations, they're just in
heavy flux.

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

