Why Perl 6 Scares The Hell Out Of Me | Hacker News Reader

Why Perl 6 Scares The Hell Out Of Me

use.perl.org

12 pointsantiform11 comments

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.

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

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

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

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.

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.

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

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

Anyone taking bets?

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

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

Reply on news.ycombinator.com