jacksonr@handel.ColoState.EDU (robert marsh jackson) (05/12/89)
Is there a relationship between Eloquent Rhetoric and
Computer Science?
"Eloquent rhetoric: The theory and practice of the reasoned orchestration of
symbols used in the process of adjusting ideas to people and adjusting people
to ideas." - Irvine.
I have just finished a survey course which followed rhetoric from its
roots in ancient Greece to the present. At the end of the semester, we dis-
cussed some of the areas in which rhetoric might be applied. One area dis-
cussed was computers. Initially, I scoffed at the idea as being absurd be-
cause I felt that computer science needed to be more of an engineering disci-
pline. The concept stuck in my mind, so I attempted to follow it to its
logical end. I came to the conclusion that I might be wrong about the rela-
tionship between rhetoric and computer science.
First is a modern definition of eloquent rhetoric, which is written above.
Starting with the first part, "The theory and practice of the reasoned orches-
tration of symbols...," if variables and operators are symbols (compiler
theory) and programming is (hopefully) reasoned orchestration of those sym-
bols then we might be on the right track. Looking at the next part, "used in
the process of adjusting ideas to people and adjusting people to ideas," if we
let the "people" be computers and the "ideas" be programs, then the fit be-
comes closer. This second part also relates well to the research of user
interfaces as well as programming languages.
I was still not convinced that I was on the right track, so I applied
another test. When Aristotle first showed Eloquent Rhetoric to be an "art,"
he showed a "natural order" for creating rhetoric. This "natural order" was
refined by the great Roman philosopher Cicero in the five great arts of Rheto-
ric.
1) Inventio: Finding out all that can be found out about a subject. This is
the investigation stage of a software engineering project.
2) Dispositio: Finding out how the information can be put together in a
logical format. This maps well to the specification stage of a software
engineering project.
3) Elocutio: Fitting the information into language. This is analogous to
writing syntactically (and semantically) correct code in a computer language.
4) Memoria: Memory. Internal and external documentation and modularization.
5) Actio: Style. User interface, speed, ease of use, ease of modification,
correctness.
As you can see, the five great arts of Rhetoric seem to fit well with
creating computer programs on a high level. What about on a lower level? Let
me use the same analogy that I have used in my tutoring over the years and
compare an essay/paragraph with a procedure. An essay/paragraph should be
limited to ONE idea; so should a procedure. The essay/paragraph and procedure
have similar structures:
essay/paragraph procedure
------------------------------------------------------------------
Introduction Initialization code
Body Main body of code
Conclusion Exit code
Hopefully, showing how the working definition, high and low levels of
eloquent rhetoric and computer science are similar has given some food for
thought. If the comparisons are valid, what are the implications to computer
science/software engineering? 1) We will have two thousand years of theory
to back up/refute software engineering practices. 2) Computer science may be
classified better as a rhetorical science than a engineering discipline. What
are your opinions?
Bob Jackson.
crh@aber-cs.UUCP (Clive Richard Higgs) (05/15/89)
What a coincidence! I've always thought that computer programming is
a form of nuclear waste dumping ie "the theory and practice of the
reasoned orchestration of atomic objects in the process of adjusting
entities from people and people from entities".
At first I thought this was a completely Bozo idea but the concept
stuck in my mind and after much logical reasoning, I came to the
conclusion that nuclear dumping IS computer programming and vice versa.
The theory and practice of the reasoned orchestration of atomic objects
is OOD. The UK has played a major part in structuring radioactive objects
into classes. We accept all lethal classes from the world of objects,
package them in oildrums and export to the Irish Sea. If we let "people"
be microcode then they are hidden completely from the concepts of objects
just as human people are hidden completely from the concept of radiaoactive
objects.
I was still not convinced that I was on the right track so I applied
another test. That great Roman philosopher Cicero categorised Nuclear
Dumping into 5 great arts:
1) Inventio: Unfortunately my fluent Latin detected that "Inventio"
refers to something you invent and not to "finding out all that can
be found out about a subject" so Cicero obviously didn't know what
he was talking about. So I went to a lower level.
I compared a nuclear dump with a procedure and found there were remarkable
similarities: both start, have a main body and end.
So what are the main implications to Computer Science? 1) We will have
forty years of sophistry, incompetence and lies to back up/refute/obscure
software engineering priciples. 2) Computer science may be classified
better as a load of old rubbish than an engineering discipline.
What are your opinions?
Cliversp@PacBell.COM (Steve Price) (05/18/89)
In article <1886@ccncsu.ColoState.EDU> jacksonr@handel.ColoState.EDU (robert marsh jackson) writes: > > > > > Is there a relationship between Eloquent Rhetoric and > Computer Science? > As a former professor of English and a veteran of years of teaching rhetoric and public speaking, I'd say you answered your own question rather well and convincingly. Yes! I have always seen these connections between well-designed programs/systems and well-designed essays/speeches, and always wondered why others never seemed to be aware of it. I'm glad to see I am not alone. Now that I'm a programmer, striving to become a software engineer :-), I'd make a better English professor, especially when facing the CS major who can't see any earthly reason for taking Freshman Composition (where I taught mostly Rhetoric) seriously. I admit that it did take me a while when changing careers from teaching to data processing, to get over the bias that implies that only math or physic or engineering students can be "real programmers". I almost believed that myself, but my background in rhetoric has given me a very strong platform from which to design programs, systems and especially databases. I find that a natural grasp of relational database theory flows from my Humanities training. So I second your motion to include Computer Science in the Humanities disciplines as much as in the "hard" sciences. -- Steve Price pacbell!pbhyf!rsp (415)823-1951 "'Nothing will come from nothing' without information" -- Shakespeare & Bateson
emuleomo@yes.rutgers.edu (Emuleomo) (05/20/89)
Wonders will never cease! How can you include COMPUTER SCIENCE in humanities when this discipline evolved from the math and EE depts.?? My suspicion is that this author never took courses like a. Graph theory b. Analysis of Algorithms c. Microprocessors and Microprogramming d. Switching theory c. Computability and complexity theory etc.. in college. Please note that computer science <> programming!!!! --Emuleomo O.O. ** Research is what I'm doing when I don't know what I'm doing!! **
shf@well.UUCP (Stuart H. Ferguson) (05/22/89)
+-- 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 analogies are pretty good: the relationships between sentence/statement, paragraph/procedure and section/module, as well as first draft/prototype, outline/pseudocode and revisied edition/version 2.0. Although there are certainly places where the analogies are strained a bit, they are at least as good as the "bridge building" analogy, if not better, so I think it's possible to learn something from them. The purpose of writing is communication, but not what that most people think of as "communication:" namely, the simple transmission of information. Most people think that writing is just taking the ideas in your head and wrapping them up in a syntatic structure so that someone else can parse it and extract the same ideas into their head. This turns out to be a very naive notion. Language, particularly rhetoric, has the capability to create worlds, and to allow people to share them. Writing encapsulates not just some particular information, but the entire set of background assumptions that make those facts or ideas possible at all. What's important is not what the words say, but the reality that makes them possible, and this is true of programs as well. 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. PostScript, for example, isn't just some program, or some arbitrary syntax for making marks on a page, rather it's a whole world, a complete self-consistent philosophy for page layout. An end-user example might be a music scoring program. The program presents a world to the user, consisting of a formalization of the process of scoring music. It sets into a concrete form the abstract process of music and makes it available. If done well, the program can communicate the realm of music scoring by making the concepts come alive (literally). If done poorly, the program will simply present a collection of arbitrary formalisms which can surround the subject but fail to recreate it for the user. 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. | Bob Jackson. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
paul@moncam.co.uk (Paul Hudson) (05/23/89)
In article <May.19.15.36.05.1989.2641@yes.rutgers.edu>, emuleomo@yes.rutgers.edu (Emuleomo) writes: > Wonders will never cease! How can you include COMPUTER SCIENCE in > humanities when this discipline evolved from the math and EE depts.?? > My suspicion is that this author never took courses like Over here several places put maths in the "arts" side of the fence. It's my experience that mathematics does attract the "arty" people as well as the science. (Speaking as a mathematician who's definately on the science side.. ). That makes the humanities OK for computer science to me, especially since there's not all that science in the computer science I've seen practised ... Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket" -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"
warw@cgch.UUCP (Anthony R. Wuersch) (05/25/89)
shf@well.UUCP (Stuart H. Ferguson) writes: >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. For a good analogy, use railroads instead of bridges. Let a program be a railroad network, i.e., tracks, switches, and stations, which trains, (i.e., computing machines) run on. Trains transport goods from boarding stations to deboarding stations. You need a train schedule, price list, money, and means to get to the train station to use the railroad. [ Thanks to Albert Meier for writing the article with this analogy ] Derailments, missed connections, changing schedules and prices, disabled track, overpacked trains --- all are possible. But they don't occur too often (I hope). If you agree that railroads are a good analogy, then show me a railroad schedule which reads like an essay. The best railroad schedules, such as Switzerland's three volume set, are packed with path maps, indexes, codings, and graphical symbols. Their amount of text is small. Also, their readers don't all speak the same language. >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. Donald Knuth is maybe its biggest exponent. The CACM had a series called ``Literate Programming.'' Documentation and specification people stress it. Many computer people accept the writing analogy. It's a popular opinion. Don't confuse a rhetorical opening --- claiming the enemy's point of view is dominant in order to use it as a strawman --- with reality. >Although there are certainly places where the analogies are strained a >bit, they are at least as good as the "bridge building" analogy, if not >better, so I think it's possible to learn something from them. There are no decent analogies from writing to issues of process and flow control. With the loss of these issues, one can't grip issues of how a system performs in an operating environment. And such issues lie at the heart of engineering, as I understand it. A railroad schedule, on the other hand, lists thousands of performance promises. >Language, particularly rhetoric, has the capability to create worlds, and >to allow people to share them. Writing encapsulates not just some particular >information, but the entire set of background assumptions that make those >facts or ideas possible at all. Aristotle's definition of rhetoric is the study of the available means of persuasion. That is, there is always a persuader [speaker], i.e., someone who wields those means, and an audience (or audiences) to be persuaded. There is no assumption in a rhetorical point of view that the speaker and the audience(s) share assumptions. And there's no restriction of the means of persuasion to written linguistic forms alone. The encapsulation thesis is very questionable. At any time, potentially available means of persuasion are much wider than writing, and today they also go beyond what was possible in Greek and Roman times. And you can't just unify assumptions by taking their union. I doubt that one can unify assumptions except in very well-defined cases. If one could, then PT Barnum could rule the world. (PT Barnum: "you can fool some of the people all of the time, and all of the people some of the time, but you can't fool all of the people all of the time.") In general, spreading the idea of unifying assumptions (or "worlds") is pernicious. One makes a nearly impossible idea sound simple and natural. >Badly designed code is mearly [sic] 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. I'm not sure that code requiring almost no maintenance requires grotesque machinery to protect the maintainer. If the product requires very little maintenance, you could pay a qualified engineer to repair it. A saying: when a Japanese product has a problem, the manufacturer sends an engineer. When a American product has a problem, the manufacturer sends a FAX. Maybe this means that the American product is better designed --- its maintenance only requires a FAX. But I doubt it. Think of how many FAXes get sent, and how much time the customer loses reading them. Repetez: the best products require almost no maintenance. Code is a product. Toni Toni Wuersch (CIBA-GEIGY Scientific Computing Center) c/o CIBA_GEIGY AG, R-1032.3.32, P.O.Box, CH-4002 Basel, Switzerland UUCP: warw@cgch.UUCP ( ..!mcvax!cernvax!cgch!warw ) Internet: warw%cgch.uucp@uunet.uu.net Phone: (+41) 61 697 31 43 BITNET: warw%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 32 88 First order logic disclaimer: `forall x ( "Toni wrote x" --> "CIBA-GEIGY endorses x" )' is unsatisfiable.
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)