"Its Me" <itsme213 / hotmail.com> wrote:

> That way the visible and maintained code for class A remains uncluttered and
> declarative. The way the code generator "implements" the initializer
> construct can change without impacting class A's definition.

There's a tradeoff here that fascinates me: on the one hand, code
generation of that sort definitely makes the code more "declarative"
in that the intent is more directly obvious to a human reader
("explicit programming").  On the other hand, it makes the code much
more opaque to automated tools, because they can't (statically) know
what the resulting code will be: the refactoring browser becomes
useless.  In that sense, code generation leads to much *less*
declarative code: the only way you can know what your program is (much
less what it does), is to run it.

I believe that the only way Ruby will ever be able to have the same
level of tool support (of any kind, whether we're talking about code
browsers, refactoring tools, or version control systems) that
Smalltalk does is by making the same sacrifice that Smalltalk did: to
completely avoid any form of code generation or macros.  It's not an
easy sacrifice to make - as someone used to Lisp, I found it very hard
to come to terms with - but as long as the language is dynamic enough
in other ways, I'm beginning to think it's worth making.  I'd be
curious to see what "declarative Ruby" (ie, Ruby consisting solely of
class and method definitions) would look like, and what new kinds of
tools would emerge if everyone started writing Ruby that way.

Avi