Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucla-cs.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!ucla-cs!berke
From: berke@ucla-cs.UUCP
Newsgroups: net.cog-eng
Subject: Re: Knowledge and Design
Message-ID: <8824@ucla-cs.ARPA>
Date: Sat, 8-Feb-86 18:09:27 EST
Article-I.D.: ucla-cs.8824
Posted: Sat Feb  8 18:09:27 1986
Date-Received: Tue, 11-Feb-86 06:27:22 EST
References: <11800004@uiucme>
Reply-To: berke@ucla-cs.UUCP (Peter Berke)
Organization: UCLA Computer Science Department
Lines: 62

In article <11800004@uiucme> keith@uiucme.UUCP writes:
>
>In the last discussion I made an impassioned, if ill-documented,
>case for the importance of interactions in design. 

>I stated that tomorrow's designers are being taught by specialists,
>thus missing an opportunity to learn about these interactions during
>their initial engineering education.  This severely handicaps a designer
>as he begins learning his trade, since for four or more years he has been
>conditioned to ignore these interactions that will control many of the
>problems he will be asked to solve.

At the risk of seeming to pick on Keith, who I don't know, I'd like to agree
with his remarks while making a point of my own:  By using the word 'he'
to refer to all engineers, or a single generic engineer, however you care 
to look at it, we are patterning our minds to actually believe engineers are
men.
>
>This, basically, is the research I am involved in:  demonstrating the idea
>of the general knowledge base for design.  This incorporates two concepts:
>dealing with information at a more abstract level, to allow more abstract
>decision-making, and improving the coherence of the knowledge base.  These
>two are hopelessly interrelated, since a great deal of the process of
>incorporation requires abstraction, and vice versa.
>

Yes, indeed, our abstractions determine the interactions in our knowledge, and
the interactions of our knowledge form (perhaps are) our abstractions.  To say
that 'he' has two meanings, gender specific and gender-neutral while denying
gender-neutral use to 'she' results in a lot of abstract decisions that 
assume people, especially engineers, are men, not women.  At the very least,
then, even if we don't conciously believe all engineers are men, when we speak
of them as 'he' we are bound to make decisions that assume engineers are men.

>Incorporating new knowledge also requires a good look at the interactions
>between the new information and what is "already known".  

Yes, again, unless we examine our presumptions, we cannot learn conciously,
we just end up trained in unconcious patterns by accepted societal word usages.
So, in a very real sense, when we conciously choose words to communicate,
we are conciously designing our world.  That means to me, that each and every
one of us is creating the world as it is, minute to minute, day by day, 
whether or not she is an engineer.

When it is no longer an insult for a man to be called a woman, it will no
longer be oppresive to call a woman a man.  How do we get there from here?
By designing our world conciously.  In this case, I think by using 'she' 
everywhere instead of 'he'.  As said in a popular textbook on Pascal "ten
years of 'she' can't undo thousands of years of 'he', but it's a start."

As to where new teachers of design come from, I assume from this group. Thank
you to Keith for helping me to see this matter more clearly.  By the way, this
note uses Frege's convention for referring to words rather than their meanings
by enclosing each word in single quotes.  I use double quotes for direct
discourse as in quoting the textbook in the preceeding paragraph.  I put 
punctuation outside single quotes to avoid indicating that the punctuation
is part of the word.  I put punctuation inside the double quotes just because
that is accepted English usage (disclaimer for occasional errors).

Cheers,

Peter Berke