Re: "Code must be Chunkable"

Hi James,

On Feb 16, 12:06=A0pm, James Coplien <[e-mail]> wrote:
> Thomas Sawyer wrote:
> > I just finished watching the 2nd video. I agree with you. Coplien does
> > an awful job of explaining things. Trygve, despite his age, does a
> > much better job.
>
> Thomas, I apologize if I did not explain things well for you. To move
> things forward as a community, it's good to ask questions. I'm happy to
> try to answer. Thomas, I tell people all the time that if they fail to
> ask their business people for clarification about requirements but
> instead cast cowardly aspersions supposedly out of earshot, that it
> explains many of the problems their firms have been having in its
> developments. Maybe you behave that way with your business people, but
> I'd appreciate enough respect from you to address your concerns about
> me, to me.

Honestly, James, I didn't even think about contacting you --I didn't
even suspect I'd be getting this deep into a conversation about it. I
was just sharing an interesting presentation, Trygve's (in which you
do a good job in the Q & A periods, btw). I looked forward to the
second video when I understood it had a Ruby example (as you might
imagine from a Ruby ethusiast). However, while your example gave me at
least something to go on, the presentation as a whole left me more
confused and thus less enthusiastic about the whole DCI idea. I
apologize for compacting this opinion into the one word "awful", I
suppose that is too disparaging a term, and for that I apologize. So
please accept this explanation in it's place and take it for what it's
worth.

> >> 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 don't know what he is talking about.
>
> Yes, it is clear that you don't understand what I am talking about.
>
> > It's as if he thinks, if
> > something isn't solid it isn't an object.
>
> No, that isn't it. Instead of guessing, or putting words in my mouth, or
> assuming, you could have asked me.

 No, no. I wasn't putting words in your mouth. I was expressing what
*I* was getting out of your words.

> I'm pretty easy to find on the web. I
> have done my best in the above posting to answer your question. I do so
> as a service and because I think it's important that this community
> understand the subtleties here.
>
> > And his whole speel about
> > logging-in is not a usecase because there's no business goal, is silly
> > too.
>
> This represents a fundamental misunderstanding of use cases. The
> distinction between atomic operations on objects (the direct
> manipulation metaphor) and the role of algorithms (the use case angle)
> is fundamental to understanding why DCI is different from
> object-oriented programming. I use the term "use case" in the Cockburn
> sense, as a collection of possible scenarios. Each scenario is a
> collection of interactions towards a goal. I think this definition is
> consistent with Jacbosson's more formalized use case framework. I am not
> sure what you are using as your reference standard, but I would be
> interested in your arguments against Cockburn's use of the goal as a
> major element that distinguishes use cases from just blah blah blah.
> Words mean things, and use case is not just Swedish for scenario.

The definition seems fine. I just don't see why logging-in can't be
viewed as a goal in itself.

> > He's splitting hairs over words and as much as he thinks DCI is
> > so cool, I'm not sure he actually "gets it" himself.
>
> Can you translate that into some delineated professional feedback?

Ok. This is my take. DCI seems to me like an idea with a lot of
potential. But I don't think it's an all of nothing kind of thing. I
get the feeling that you so badly want DCI to be a Major Paradigm
Shift that you might be pushing it's concepts too far.

For instance, to say that an account is not a not object... going all
the way back to the bad old days of COBOL, an account has always been
treated as as object, even if not coded in OOP form. That's because
banks treat accounts as objects --people have them, they have ID
numbers, etc. Writing a banking system without the concept of an
account ignores the very system to be modeled. I'm pretty sure that
any attempt to do so will prove far less readable (exactly the
opposite of what DCI is trying to achieve) then any program that does
--even in COBOL. Moreover, when you say an account isn't an object and
yet give a presentation where it is an object, that's just confusing.

> > However, at the
> > very beginning he does point out the main point of the whole pursuit
> > -- code readability.
>
> > His Ruby code, btw, wasn't very well written, would not run and worse,
> > I don't think represents DCI well either.
>
> Well, my version of the code runs fine here.

Then please make it available!

> One takes certain liberties
> with presentation in PowerPoint to a large audience to make points about
> design. And the code passes Trygve's muster as representing DCI well; we
> had been corresponding intensely to nurture the ideas using this
> example. But it is good to hear your input. Maybe we have found someone
> here in Thomas who understands DCI better than Trygve and I do. Please
> join the object-composition list, listen, learn, and contribute
> positively. When you post objections in a frustrated way on this list
> without engaging those you criticize, it makes me frustrated, and it
> does not advance our collective understanding.

Please don't feel that I am criticizing *you* --take it for what it
is, my personal critique of *your presentation*.

> If you feel the Ruby style bears improvement I am open to suggestions.

I can can certainly offer some suggestions, but I would have to
understand DCI better to go beyond the surface. I posted my take on
it, but being new to DCI, I can only guess if I am on the right track
or not.

> > (P.S. I also think this is much more like AOP then Coplien is willing
> > to admit.)
>
> Second, I'd like to know why; and first, I'd like to know why it's
> important. Again, I think you are making the mistake that another poster
> here warns about: confusing the language mechanisms with the design
> ideas.

The goal of AOP is to come at a problem orthogonal to the traditional
OOP direction. In AOP you are organizing code into aspects. These
aspects are like contexts in DCI. Aspects are composed of advice, code
injected into classes/objects by wrapping other methods.
There are clear similarities. DCI goes a bit further by injecting
methods whole-clothe, and in doing so decomposes "aspects" into a
context and set of roles. (Actually that might be useful, might DCI
roles make use of AOP's concept of advice too?)