Contact:cdent@burningchrome.com
While discussing categories I tossed out: Categories are resistant to definition because they exist to replace definitions. This is apparently worth saving. So I've put it here to flesh it out a bit more later. Back to the Index
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
Contact:cdent@burningchrome.com
Norman, D. (1993). Chapter 7: A place for everything and everything in
its place. In _Things that makes us smart_ (p. 155-184).
Cambridge: Perseus Books.
-=-=-
There's a great deal to respond to here but I'll pick just one issue.
People benefit from the lumping and ordering of information. It helps
to create relationships and maintain distinctions. Norman realizes
that with the help of a computer the lumping and ordering of
information can be dynamicaly adjusted to the needs of the immediate
user and application. This is a good insight. N. could have come right
out and said, "computers would be great at facilitating faceted
classification."
There's a bit of a flaw in his reasoning:
One of the powers of the computer should be that it doesn't
have to keep things in order.
I think what he really means is that we don't need to know the
internal representation the computer is using to order things. If the
computer does not order the information it can't be retrieved.
Back to the Index
Contact:cdent@burningchrome.com
Brown, J.S., & Duiguid, P. (1009). Organizing Knowledge. Retrieved
November 4, 2001 from http://slofi.com/organizi.htm.
-=-=-
"Conclusion: Dialectical Thinking"
But of course: if organizations (and by extension organizing) exist to
create a synergistic synthesis then there must be the comparative
force of the dialectic. Things, information, people must be put in
relationships--they must be organized--so that new stuff may form.
The dialectic is at the center of Information Science, but thus far
rarely mentioned. Distinctions, categories, classification,
organization, representation are all illuminated if placed in the
evolutionary context of thesis=>antithesis=>synthesis (which
transforms to thesis, endless process).
In this context, the healthy organization is one that is constantly
reacting and adapting to its environment.
As B&D say, the organization of a firm provides the sometimes
invisible scaffolding by which groups effectively think so as to
survive in their environment.
A corporation is not, contrary to US law, a person but it does create
and utilize cognitive scaffolding in ways quite similar to a person.
Back to the Index
Contact:cdent@burningchrome.com
Tesar, P. (1991). The other side of types. In G. Rockcastle (Ed.)
_Midgard Monographs of Architectural Theory and Criticism, Number
2_ (p. 165-175).
-=-=-
WOW. Well written, interesting; we should have more of these.
While trying to deduce how meaning in architecture is reached, Tesar
provides a lucid description of how and why humans create types
(categories). In the process we get to read a few lovely turns of
phrase, such as: "Equilibrium becomes possible only through tr
conctant adaptive struggle to maintain it and is ultimately achieved
in death." and "our perception is permeated by an 'urge to recognize,'
an initial tendency to make a new phenomenon fit into an existing
category."
I wonder if the labels on genera are the same as the labels on
categories, or really the question is in what way are categories not
genera?
It is fabulous that the fundamental way to discuss the idea of
categorization/typification is to compare it with other ideas.
The buttons example clearly demonstrates that it is the relationships
between things which contains information. This is shown again, from a
different angle, with the "Couples" art exhibit. One thing cannot
suggest a category but two can and once suggested exemples spring to
mind.
What is that process? That's one of the keys.
Back to the Index
Contact:cdent@burningchrome.com
Brown, R. (1958). How shall a thing be called? _Psychological Review
65_, 14-21.
A well constructed argument supporting the idea that the choice of
term used for any referent which has multiple choices from a hierarchy
of terms is most likely made by utility. That is, the term chosen is
that which is going to contain the most useful information for the
context. The argument is made by comparing with other notions of how
the choice is made. This may seem quite obvious but the elucidation
structures categorization as the jumping off point for classification.
Back to the Index
Contact:cdent@burningchrome.com
Shedroff, N. (1999). Information interaction design: a unified field
theory of design. In R. Jacobson (Ed.), _Information Design_ (p.
267-292). Cambridge, MA: MIT Press.
-=-=-
It is telling that the majority of my margin notes for this article
are in the first half, prior to the Interaction Design section. Here
are the highlights:
The introduction of the article makes it feel like something we have
to read to justify all the abstract stuff in the class. As in "here,
let me help you make this applicable." (I think that is a shame; see
what follows).
p. 270 Be willing to say it: information design is the foundation for
other design--it's all information. Representation is at the bottom of
all communication.
p. 271 Words that matter for effective understanding:
organize
transform
present
represent
compare
contrast
synthesize
synergize
categorize
classify
compose
decompose
interpolate
extrapolate
contextualize
integrate
p. 272 While it is true that effective communication is the
transmittal of information, not data, it must be remembered that the
transformation of data to information to knowledge to wisdom is a
political act. To be free, critical thinkers we must put ourselves in
the stance as accepters only of data use our brains to make the
adjustments further down the path. In effect we say, "that may be
knowledge for you, I'll evaluate it for myself". This can be an
enormous cognitive task which is why we must enhance our tools of
comparison so we may quickly categorize and transform data into our
information matrix.
Back to the Index