Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!xanth!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng
Subject: Re: Theory vs. Practice in CS Education
Message-ID: <16169@duke.cs.duke.edu>
Date: 22 Nov 89 16:19:11 GMT
References: <880@dms.UUCP> <7044@hubcap.clemson.edu> <4251@pegasus.ATT.COM> <4967@ae.sei.cmu.edu> <15947@bloom-beacon.MIT.EDU> <4979@ae.sei.cmu.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 65

In article <4979@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>>Reasonable in some cases, but kind of naive in others.  Sometimes what
>>the compiler does with the code determines whether or not your program
>>satisfies its specifications.
>
>Indeed, that's precisely why it's not software engineering!  Any need to do
>this should tell you that you are not doing engineering.  
>
>Architects are not doing architecture if they are worrying about how their
>designs are implemented at the beam and rivet level  Architects and other
>engineers can only work effectively when the working models exist.  How can
>there be working models when the lowest-level specifications are interpreted
>differently?  The lowest-level components in engineering disciplines are
>truly standardized and portable.
>
Richard, I don't mean this to be derogatory, but this really reads like
you haven't had much exposure to engineering in the field, or for that
matter to a working engineering organization that does much of anything
BESIDES software engineering.

While an architect is doing design, they should not be worrying about
the nail, screw, and rivet level.  They certainly do worry at the beam
level, because strength and cost optimizations determine things like
maximum clear span.

But an architect's job usually includes construction supervision:
sometimes with the architect acting as the general contractor, more
often with the architect working as a sort of independent review of the
general contractor.  They must by law and by custom do this, becuase
unless they have an explicit waver they are liable for flaws in the
building that cause damages.  Ev en if they are explicitly taken of the
job in writing before contruction, the architect is liable for flaws in
the design (cf the Kansas City flyway -- the architect was named in the
liability suit.  I don't know if they were found liable, since the
failure was apparently due to an out-of-spec change made by the
contractor.)

It is true that most engineering disciplines use prebuilt components
when available, but not all.  Mechanical engineers will design special
components for fabrication, they just have the choice, something that
software engineers often don't (yet.)

>>
>>What if I just want to learn about lexical analyzers, parsers, etc. so
>>I can apply them to *other* areas?  What about a little breadth in
>>education? ...
>
>Of course, as long as you realize exactly what you are learning and are not
>told that you are studying engineering.
>

I don't think anyone is under the impression that you are learning
engineering when learning about finite state automata and the executable
models of them.  I think many of us are holding that learning things
like FSA's and parsers is a useful an necessary part of a good education
in the things which ground software engineering.

No one thinks that Diff Eq courses are studying engineering; they are
just things that are necessary to *do* engineering on the continuous
world.  FSA's, computability, etc aren't engineering per se, but I think
they are as necessary for we engineers of the discrete world as DE is
for the other guys.


Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)