Contact:cdent@burningchrome.com
From a personal conversation about the effectiveness of object oriented programming. Included with permission from the other guy. ---------- Forwarded message ---------- Date: Thu, 25 Oct 2001 12:57:59 -0500 (EST) From: cdent@burningchrome.com To: Adrian Hosey <adrian@hosey.bloomington.in.us> Subject: Re: productivity applications On Thu, 25 Oct 2001, Adrian Hosey wrote: > : I suspect that has a lot to do with our design process in the early > : days. You know, the one that didn't really happen because we were > : either too busy or too willing to let Matt do everything or too > : unwilling to get into Matt's head (that would have taken some > : _energy_)? > > Eh. I don't know that I would have done any better. If you were going to > attack the problem from a OO philosophy - "we want to write code that > defines objects that know how to do shit" then Matt's approach was the > conventional one. Define the overarching problem as a noun - the Kiva > User. Then decompose that into a combination of containers, containees, > and inheritance trees that hook together like legos. Ideally polymorphic > legos. I'm not trying to say Matt didn't anything wrong. What Matt did was right, I think, but where things went wrong was our (you and me) own involvement in the process. I think that's a crucial part of the design process that tended not to happen at Kiva as much as it should have, mostly because of time constraints. Yes we spent a lot of time laying out the goals of the system, but once those were established, the detailed design process got a bit solo. There should have been a more iterated process of review, which could have potentially shed some light on things that didn't show up until later. Even just a series of this is how it works discussions. > The implementation was lacking, but I'm more interested in the design for > this particular discussion. As best I can tell from looking around, the > Kiva::User object model is pretty typical, and the problems I'm having > with it are typical problems. cf. http://advogato.org/article/83.html That's a good article. The Platypus problem, as he says, is all over the place in anything that claims to classify. Information Science, in some sense, is the study of classification and there is a great deal of resistance to allowing the Platypus into the room. A classification system, by definition, is a collection of categories that are sufficient. That means for the domain of things being classified there is a place for everything and the classes are sufficiently defined as to grant only one spot for every thing. Besides being bullshit this also completely limits flexibility, but it is done anyway because there is this enormous historical weight of the Book controlling classification systems. Book class systems are supposed to work with just one copy of the book and allow for adjacency (which allows for effective browsing). APUPA is a term used there: Umbra, Penumbra, Alien. Something close by in the class system is in the Umbra and is related, further away is stuff somewhat related in hte Penumbra, and then there's alien stuff. My point here is that academics tend to get over attached to clean theories of classification so when it comes time to talk about things like hiearchy and class structures they like to ignore the Platypus. But it doesn't have to be that way. There are models of classification which allow for multidimensionality and keep APUPA, if you stop worrying about physical space. If you are curious you might check out the notion of faceted classification from a guy named Ranganathan. That sort of leads into Ted Nelson's new deal, called ZigZag. Google's probably productive on both of those things. I reckon it is probably possible to create a object oriented paradigm for programming which supports faceted classification. All of which is not to suggest that I think OO is the way to go with programming. Just that there are different ways to do it that might be productive. I'm of the opinion that the creation and exploration of new ways of doing things, even if they are dead ends, moves the discipline along. > Implications... there's an inspiration. Would you ever have thought of > that? I know I wouldn't have. I don't know. I might have thought of it and thrown it away because I didn't think I could do it. That happens to me a lot. I have a hard time translating a mechanism in my head to a mechanism on the computer. Mostly because I don't think like that in my head (more on that below). > Talk about a good idea done bad > though. There was never a clear specification of the representation of an > implied value vs the representation of an explicit value and it was never > made clear in the code either. And that still continues to be a > problem. The root of the problem seems to be that, if you take all the > Attributes as a whole, there is no legal Perl value which is not also a > legal value for some Attribute. So there is no "out of band" value left to > represent an implication. Hrm. Maybe I could introduce an implication > exception and a handler which resolves the implication and carries > on. Returning the flow of control to the point of the throw would be > difficult though. Can you give me a concrete example of this, I'm not sure I'm following. > : I know that isn't how it was really, but in my mind you were the cool > : programmer and I was the programmer because somebody had to be. > > No denying Kiva::User is cool. I've learned a hell of a lot from it, for > the most part I enjoy working on it, and I have more cool plans I may or > may not get to do with it. Even when it frustrates me it teaches me, like > right now. All I'm saying here is that it's sometimes frustrating to > always be working on the engine and never driving the car, and also > admitting that may skew my perspective in the cost vs. benefits part of > this discussion. I found I got a lot of mileage towards understanding (and eventually improving) Kiva::User by stepping out of it and starting a K::U app in a way that I thought it should be and then seeing how and why it failed to work. In other words, if you get the chance, you might just make yourself drive the car for a while; addusers and disusers don't count because they are hybrids. Based on the current financial state there in Kiva land, I assume there's not much in the way of new projects going on? > Not trying to dissude you from OO design. I was just wondering if you > felt you had learned new approaches. Well, that's an interesting point: after having a semester and a half of CS courses I can say that I'm quite disappointed. Yes, c211 taught me recursion and that was a valuable lesson, but there has been very little instruction on how to program. Lots of instruction on how to code in a particular language but very little training on how to discover, visualize, articulate, create, transform or otherwise manipulate algorithms. So while my vocabulary is growing, I don't really feel like my ability to express myself is improving all that much. Thus, at this point, it would be difficult for me to articulate any new approaches, at least not with labels. Yes there's recursion and the notion of passing a procedure to another one (see, I can't remember what that's called) but the way those and other things were taught doesn't seem to have changed my (conscious) understanding all that much. > : I do wish that I was more skilled at lispy languages. Things like Java > : feel enourmously clumsy in comparison, but on the other hand lisp to > : me is hard to grok with glances. > > The Scheme bigots will tell you that's a good thing. ;) Why is that? I mean, really, what's the benefit of not being able to read? Do you mind if I quote some of this conversation in this: http://www.burningchrome.com/~cdent/fiaarts/ that's my readings journal for a class and since we are currently talking about classification it might be worthwhile to slice and dice some of this into the journal. Back to the Index