"Code must be Chunkable"
in [Ruby]
|
From: James Coplien on 16 Feb 2010 12:06 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. >> 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. 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. > 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? > 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. 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. If you feel the Ruby style bears improvement I am open to suggestions. > (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. These things just take time. Keep working at it, guys, and don't let your preconceptions get in the way... any more. -- Posted via http://www.ruby-forum.com/.
From: James Coplien on 16 Feb 2010 12:22 > I did a couple of interesting things (though I suppose I may be taking > it too far) I thought of a Context as a Scene in a play, in which I > defined the roles upfront (ie. at the class level) -- I use the Anise > gem to do this, btw. And, despite what was said in the lecture, I was > able to use polymorphism with regard to the roles. This approach seems > very interesting. I was able to define two methods of the same name > that can act on the same object, but dependent on the role it plays. > Thus the Context has a method that is dispatched to all the roles. > While my code is from perfect the approach itself does seem like it > could be useful for large applications. (It feels like overkill for > small libraries though). Right! This is the metaphor we often have been using. More precisely, the Context is a combination of the script (which is in the roles within its scope) and the casting (the dynamic mapping of roles to objects/actors). I in fact have been working on a DCI pattern language based on this metaphor, because it works so well. -- Posted via http://www.ruby-forum.com/.
From: Intransition on 17 Feb 2010 06:31 Hi James, On Feb 16, 12:06 pm, James Coplien <jcopl...(a)gmail.com> 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?)
From: Intransition on 17 Feb 2010 06:38 On Feb 16, 11:41 am, James Coplien <jcopl...(a)gmail.com> wrote: > I can see from the thread below that it was too much for the posters in > this thread, and that the posters were unable to correlate that example > with the description in the Artima article. The reason this is a bit > advanced is that it comes from the design thinking that Trygve and I > have put into DCI, rather than the nerd-level stuff. It doesn't cater to > UML-shaped heads, or even to the way that most people characterize > object-oriented programming. It is one of the more difficult ideas in > DCI, and it is the one that most people trip on. Most people have so > much trouble fitting into their mental model that they just say that it > is wrong, or stupid. It's O.K. if you feel that way: new paradigms are > hard, and it will take a while to unlearn old ways and to learn new. No matter how hard anew paradigms is, it must still be taught.
From: Intransition on 17 Feb 2010 06:44
On Feb 17, 6:31 am, Intransition <transf...(a)gmail.com> wrote: > 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 "goal" isn't the right word actually, more like "tactic". |