a_dent@vaxa.uwa.oz (Andy Dent, ph: 09 380 2620) (05/29/89)
In article <11766@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > +-- jacksonr@handel.ColoState.EDU (robert marsh jackson) writes: > | Is there a relationship between Eloquent Rhetoric and > | Computer Science? > > Yes, I think so. I've always maintained that business of programming > computers is a lot closer to the artistic and technical practice of writing > and word-smithy than that of building bridges. (Actually, building > bridges and wrting good essays have some strong similarities as well, but > that's another matter...) But computer people seem to reject this notion, > and I don't really understand why. Perhaps it's because we generally > dislike the "humanities" and did poorly at them in school -- I don't > know -- anyway, it's not a popular opinion. ... > > The purpose of writing is communication, but not what that most people > think of as "communication:" namely, the simple transmission of information. ... > > The very best programs are those that communicate a world -- that, by > virtue of their interactions, create a self-contained reality in which > the person using the program can dwell, be he end-user or programmer. I heartily agree. I have always been a proponent of the idea that the best way to understand a system is to understand the totality. A good system has a self-consistency that makes it easier to understand as a whole. But why restrict the analogy to writing? Considering painting - there are paintings that convey such a powerful/consistent world that most viewers are swiftly drawn in and can see from the artist's viewpoint. Conversely, there are paintings which take more "refined" sensibilities to appreciate (no, I'm not sneering - this refers to the experience of the observer). ... > > This also happens at the code level. Well "engineered" program code can > create a domain which formalizes the process the code is supposed to > perform. This allows the people who have to enhance and maintain it a > place to extend from, to try new things and see how they work. It > results in code where each piece makes sense in the context of the world > that they together comprise. Badly designed code is mearly a collection > of statements that do something without any underlying reason beyond the > world of the programming language itself. The result is code that can't > be extended or maintained and is full of the kinds of bugs that come > from a lack of a reasoned structure. In my experience as a maintenance programmer, I have seen code which maps well on to my Art argument. Some programs are written in such a clear manner that it takes little effort/experience to "join the programmer's world" and are thus simple to maintain. There are some programs which are also well-written but require more sophistication to understand. There are also examples of "bad art" - programs which exhibit little internal consistency. I have worked on some atrocious code and the (printable) phrase which most often comes to mind is: "this guy doesn't know what he's doing". Incidentally, this line of reasoning meshes with the idea that some of the best programs come from single programmers. It is very hard for a committee to develop a consistent "inner vision", let alone convey it. Andy Dent (Systems Programmer, language student and amateur thinker)