Path: utzoo!utgpu!watmath!iuvax!rutgers!att!cbnewsm!lfd
From: lfd@cbnewsm.ATT.COM (leland.f.derbenwick)
Newsgroups: comp.software-eng
Subject: Re: Theory vs. Practice in CS Education
Summary: Engineers must worry about the "beam and rivet level".
Message-ID: <6738@cbnewsm.ATT.COM>
Date: 17 Nov 89 18:23:56 GMT
References: <880@dms.UUCP> <7044@hubcap.clemson.edu> <4251@pegasus.ATT.COM> <4979@ae.sei.cmu.edu>
Organization: AT&T Bell Laboratories
Lines: 72

Richard D'Ippolito appears to think engineering (specifically software
engineering) ends with high-level design.  The engineering disciplines
apply all the way down to implementation details.

In article <4979@ae.sei.cmu.edu>, rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
> In article <15947@bloom-beacon.MIT.EDU> Chris Craig writes:
> 
> >In article <4967@ae.sei.cmu.edu> Richard S D'Ippolito writes:
> >
> >>Nonsense -- this has nothing to do with software engineering, the original
> >>topic.  At the engineering level, you don't care what the compiler is doing
> >>with the code anymore than an architect cares how electricity flows through
> >>wires.
> >
> >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.

I would have said _extremely_ naive; Chris Craig is more tactful.

> Indeed, that's precisely why it's not software engineering!  Any need to do
> this should tell you that you are not doing engineering.  

Needing to meet specified performance is common in all branches of
engineering.  How one goes about that is part of engineering.
Why should software be different?

For example, a chemical engineer who doesn't understand how spray
towers work could design one that's 99% fluid and 1% air.  (Which
isn't a spray tower, it's occasional bubbles in a pot of fluid,
and it's _not_ going to work as intended!)

> 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.

Very bad example.  The Hartford Civic Center's roof collapsed (when the
place was empty, luckily) because "beam and rivet level", as understood
by the architects (and their CAD programs), didn't match the reality
of how things are put together.

And people _died_ a few years ago (the multi-level pedestrian walkway
that collapsed) largely because an architect didn't properly understand
the "beam and rivet level".  Architects routinely provide "detailing"
of how buildings are to be constructed.  The detailing for the joints
to attach each level of the walkway wasn't feasible to build, so the
contractor used a feasible method that had only about half the strength
that the architect intended.

> >>If you wish to specialize in designing compilers, take the course.
> >
> >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.
> [...]

That's like saying that a chemical engineering student who is learning
about how to design chemical reactors isn't learning engineering.

And even the high-level portions of software engineering can be taught
(or at least practiced) in any course that involves software
development.  A compiler course is no exception.

 -- Speaking for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd