On 9/27/05, Jim Freeze <jim / freeze.org> wrote:
>
> Matz has said (at the Lightweight Language Conf) that Ruby will never
> have macros because they are too easily abused, by the average person,
> to mutate the language.
>

  This is a cop-out.  Every time a new language comes around and
doesn't support some feature, the reason is always "too easily
abused".  Macros in lisp are about abstraction.  Like every other
abstraction - interfaces, classes, pointers, etc, they can be abused
horribly.  They can also be a powerful tool.
  If I recall my CS 101, computer programming is built on the pillars
of algorithms and data structures.  Lisp and its variants are neat
because they represent the code as a native data structure.  With that
in place it becomes easy to create algorithms to manipulate the data
structure, changing the syntax as you write, and the code as it runs. 
If you're familiar with the more complex metaprogramming techniques
C++ provides with templates, you'll start to get the idea of what lisp
macros offer you.  Macros are less limiting than C++ templates though,
and more naturally represented.

  Consider an array in Ruby whose first element is a method call:
a = [method, param1, param2]
eval "${a[0]} ${a[1]} ${a[2]}"
If param1 becomes an array, that is a nested call:
a = [method, [method2, x, y], param2]

In Lisp, if 'method' is a macro:
a = [macro, [method2, x, y], param2]
then macro gets 'expanded' at compile time WITHOUT evaluating the parameters:
a = [method [do-crazy-thing param2 [do-cool-thing [method2, x, y] ] ]
[ [param2 method2, x, y] ] ]
; Did I match all my braces?

I really like Lisp.  :)

-Ben