From: "Jörg W Mittag" <JoergWMittag+Ruby@...>
Date: 2010-02-13T09:00:06+09:00
Subject: Re: "Code must be Chunkable"

Brian Candler wrote:
> Thomas Sawyer wrote:
>>   http://architects.dzone.com/videos/dci-architecture-trygve
> [...]
> Then at the end, it says that an account isn't really an object at all - 
> but all the previous code has shown it as a concrete object (e.g. 
> Account.find(id)). So an example of what an account role *should* look 
> like in code would be good.

I have been following DCI on and off ever since James's JAOO 2008
interview and more closely since James's and Trygve's March 2009
article. I won't even try and pretend that I understand as little as
1% of this stuff, but there is one important idea that I have carried
around with me, ever since I read all those "it's just traits"
comments on the Artima article: one thing that I always need to remind
myself of, is that doing DCI in Ruby is like doing OO in C: it's only
a *very* rough approximation which lacks much of the expressive power
and often confuses the idea with the implementation.

Whenever I think "it's just traits/aspects/mixins/responsibilities and
why does he say this isn't an object when it clearly is?" I picture
myself trying to explain OO to a C programmer, in C, and constantly
answering questions like "it's just structs and function pointers and
why do you keep calling it an object when it clearly is a struct?" and
yelling back at him "because there are no objects in C, idiot, structs
is all I have!"

I believe that, like OO or logic programming, DCI is only going to
start to *really* shine (or, as the case may be, bomb spectacularly)
when we have DCI languages. There were many logic systems in Lisp
before Prolog, and as Alan Kay recently pointed out, there were object
systems in assembly going back as far as 1952, but before Prolog,
Simula and Smalltalk nobody cared, and nobody understood. It's hard to
see the real value of the idea behind the implementation, if the
implementation leaks all over the place as structs+function pointers
as objects and methods do in C and objects, classes and mixins as
data, context and roles do in Ruby.

Unfortunately, for this dynamic role injection stuff, we run into one
of the (very few) limitations of Ruby. We cannot just, as Trygve says,
"subclass the compiler" and "add to and delete methods from the method
dictionary" in Ruby (although we probably *can* in Rubinius) like
Trygve's Squeak implementation does or subvert the compiler like
James's C++ template metaprogramming implementation does.

Ironically, this stuff, which looks like a match made in heaven for
Ruby, is one of the *very few* instances where C++'s static
metaprogramming outshines Ruby's dynamic metaprogramming and the leaky
abstraction of ECMAScript actually *helps* rather than hurts.
(Although I *do* have a seed of a spark of a hunch on how to fake
dynamic class composition.)

Anyway, I don't really have anything useful to contribute to this
discussion other than the tip that it helps to constantly remind
myself that DCI in a non-DCI language is always only an approximation.

jwm