Why Perl 6 Scares The Hell Out Of Me(use.perl.org)
use.perl.org
Why Perl 6 Scares The Hell Out Of Me
http://use.perl.org/~Alias/journal/35508
11 comments
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 ...)))
withFile $ \h -> do
...
fib = memoize $ \n -> if n <= 1
then n
else fib (n - 1) + fib (n - 2)
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:
Or you can go further to name the enum itself, defining conversion functions between symbolic names and their values:
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))
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) ...)
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.
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?
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...
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.