Re: Real-world education (was: Ariane 5 failure)

Re: Real-world education (was: Ariane 5 failure)

[Simon Johnston]

Michael Feldman wrote:
> In article <1996Sep29.193602.17369@enterprise.rdd.lmsc.lockheed.com>,
> Chris McKnight <cmcknigh@hercii.lasc.lockheed.com> wrote:
>=20
> [Rich Pattis' good stuff snipped.]
> >
> >  An excellent bit of teaching, IMHO. Glad to hear they're putting =
some
> >  more of the real world issues in the class room.
>=20
> Rich Pattis is indeed an experienced, even gifted teacher of
> introductory courses, with a very practical view of what they
> should be about.
>=20
> Without diminishing Rich Pattis' teaching experience or skill one bit,
> I am somewhat perplexed at the unfortunate stereotypical view you
> seem to have of CS profs. Yours is the second post today to have
> shown evidence of that stereotypical view; both you and the other
> poster have industry addresses.

I think some of it must come from experience, I have met some really =
good, industry focused profs ho teach with a real "useful" view (my =
first serious language was COBOL!). I have also met the "computer =
science" guys, without whom we would never move forward. I have also met =
some inbetween who really don't have that engineering focus or the =
science.
 =20
> This is my 22nd year as a CS prof, I travel a lot in CS education
> circles, and - while we, like any population, tend to hit a bell
> curve - I've found that there are a lot more of us out here than
> you may think with Pattis-like commitment to bring the real world
> into our teaching.

Mike, I know from your books and postings here the level of engineering =
you bring to your teaching, we are discussing (I believe) the balance in =
teaching computing as an engineering discipline or as an ad-hoc =
individual "art".

> Sure, there are theorists, as there are in any field, studying
> and teaching computing just because it's "beautiful", with little
> reference to real application, and there's a definite place in the
> teaching world for them.  Indeed, exposure to their "purity" of
> approach is healthy for undergraduates - there is no harm at all
> in taking on computing - sometimes - as purely an intellectual
> exercise.
>=20
> But it's a real reach from there to an assumption that most of us
> are in that theoretical category.

I don't think many of the people I work with have made this leap.
=20
> I must say that there's a definite connection between an interest
> in Ada and an interest in real-world software; certainly most of
> the Ada teachers I've met are more like Pattis than you must think.
> Indeed, it's probably our commitment to that "engineering" view
> of computing that brings us to like and teach Ada.

Certainly (or as in my case COBOL) it leads you into an application =
oriented way of thinking which makes you think about requirements, =
testing etc.

 [snip]

let me give you a little anecdote f my own.=20
I recently went for a job interview with a very large well-known =
software firm. Firstly they wanted me write the code to traverse a =
binary tree for which they described the (C) data structures. Then I was =
asked to write code to insert a node in a linked list (I had to ask what =
the requirements for cases such as the list being empty or the node =
already existing where). Finally I was asked to write the code to find =
all the anagrams in a given string.
There were no business type questions, no true analytical questions, the =
things which as an engineer I have to do each day. The problems set me =
have a simple and single answer which I don't write each day. I am sure =
you can recite off hand the way to traverse a binary tree, but I have to =
stop and think because I wrote it ONCE, AGES AGO and wrote it as a =
GENERIC which I can REUSE. I know an understanding of these algorithms =
is required so that I can decide which of my generics to use, but that =
is why I invest in good books!
By the way I happen to know someone who works for this firm who told me =
that graduate programmers seem to do well in their interview process, he =
once interviewed an engineer with 20 years industry experience and a PhD =
who got up and left half way through the interview in disgust.

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,----------------------------------------------------------------------=
---.
--|Simon K. Johnston - Development Engineer (C++/Ada95) |ICL Retail =
Systems |
--|-----------------------------------------------------|3/4 Willoughby =
Road|
--|Internet : skj@acm.org                               |Bracknell       =
   |
--|Telephone: +44 (0)1344 476320 Fax: +44 (0)1344 476302|Berkshire       =
   |
--|Internal : 7261 6320   OP Mail: S.K.Johnston@BRA0801 |RG12 8TJ        =
   |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom  =
   |
--`----------------------------------------------------------------------=
---'
end Sig;

Re: Ariane 5 failure

[Richard Pattis]

As an instructor in CS1/CS2, this discussion interests me. I try to talk about
designing robust, reusable code, and actually have students reuse code that
I have written as well as some that they (and their peers) have written.
The Ariane falure adds a new view to robustness, having to do with future
use of code, and mathematical proof vs "engineering" considerations..

Should a software engineer remove safety checks if he/she can prove - based on
physical limitations, like a rocket not exceeding a certain speed - that they
are unnecessary. Or, knowing that his/her code will be reused (in an unknown
context, by someone who is not so skilled, and will probably not think to
redo the proof) should such checks not be optimized out? What rule of thumb
should be used to decide (e.g., what if the proof assumes the rocket speed
will not exceed that of light)? Since software operates in the real world (not
the world of mathematics) should mathematical proofs about code always yield
to engineering rules of thumb to expect the unexpected.

  "In the Russian theatre, every 5 years an unloaded gun accidentally 
   discharges and kills someone; every 20 years a broom does."

What is the rule of thumb about when should mathematics be believed? 

  As to saving SPEED by disabling the range checks: did the code not meet its
speed requirements with range checks on? Only in this case would I have turned
them off. Does "real time" mean fast enough or as fast as possible? To
misquote Einstein, "Code should run as fast as necessary, but no faster...."
since something is always traded away to increase speed.

If I were to try to create a lecture on this topic, what other similar
failures should I know about (beside the legendary Venus probe)?
Your comments?

Rich

Re: Ariane 5 failure

[Chris McKnight]

In article Hzz@beaver.cs.washington.edu, pattis@cs.washington.edu (Richard Pattis) writes:
>As an instructor in CS1/CS2, this discussion interests me. I try to talk about
>designing robust, reusable code, and actually have students reuse code that
>I have written as well as some that they (and their peers) have written.
>The Ariane falure adds a new view to robustness, having to do with future
>use of code, and mathematical proof vs "engineering" considerations..

  An excellent bit of teaching, IMHO. Glad to hear they're putting some
  more of the real world issues in the class room.

>Should a software engineer remove safety checks if he/she can prove - based on
>physical limitations, like a rocket not exceeding a certain speed - that they
>are unnecessary. Or, knowing that his/her code will be reused (in an unknown
>context, by someone who is not so skilled, and will probably not think to
>redo the proof) should such checks not be optimized out? What rule of thumb
>should be used to decide (e.g., what if the proof assumes the rocket speed
>will not exceed that of light)? Since software operates in the real world (not
>the world of mathematics) should mathematical proofs about code always yield
>to engineering rules of thumb to expect the unexpected.

 A good question.  For the most part, I'd go with engineering rules of thumb
 (what did you expect, I'm an engineer).  As an engineer, you never know what
 may happen in the real world (in spite of what you may think), so I prefer
 error detection and predictable recovery.  The key factors to consider include
 the likelihood and the cost of failures, and the cost of leaving in (or adding
 where your language doesn't already provide it) the checks.

 Consider these factors, likelihood and cost of failures:

    In a real-time embedded system, both of these factors are often high.  Of
    the two, I think people most often get caught on misbeliefs on likelihood of
    failure.  As an example, I've argued more than once with engineers who think
    that since a device is only "able" to give them a value in a certain range, 
    they needn't check for out of range values.  I've seen enough failed hardware
    to know that anything is possible, regardless of what the manufacturer may
    claim.  Consider your speed of light example, what if the sensor goes bonkers
    and tells you that you're going faster?  Your "proof" that you can't get that
    value falls apart then.  Your point about reuse is also well made.  Who knows
    what someone else may want to use your code for?

    As for cost of failure, it's usually obvious; in dollars, in lives, or both.
 
 As for cost of leaving checks in (or putting them in):

    IMHO, the cost is almost always insignificant.  If the timing is so tight that 
    removing checks makes the difference, it's probably time to redesign anyway.
    Afterall, in the real world there's always going to be fixes, new features, 
    etc.. that need to be added later, so you'd better plan for it.  Also, it's
    been my experience that removing checks is somewhere in the single digits
    on % improvement.  If you're really that tight, a good optimizer can yield
    10%-15% or more (actual mileage may vary of course).  But again, if that
    makes the difference, you'd better rethink your design.
   
 So the rule of thumb I use is, unless a device is not physically capable (as
 opposed to theoretically capable) of giving me out of range data, I'm going
 to range check it.  I.E. if there's 3 bits, you'd better check for 8 values
 regardless of the number of values you think you can get.

 That having been said, it's often not up to the engineer to make these 
 decisions.  Such things as political considerations, customer demands, and 
 (more often than not) management decisions  have been known to succeed in
 convincing me to turn checks off.  As a rule, however, I fight to keep them
 in, at very least through development and integration. 

>  As to saving SPEED by disabling the range checks: did the code not meet its
>speed requirements with range checks on? Only in this case would I have turned
>them off. Does "real time" mean fast enough or as fast as possible? To
>misquote Einstein, "Code should run as fast as necessary, but no faster...."
>since something is always traded away to increase speed.

  Precisely!  And when what's being traded is safety, it's not worth it.


  Cheers,

     Chris


=========================================================================

"I was gratified to be able to answer promptly.  I said I don't know".  
  -- Mark Twain

=========================================================================

Re: Real-world education (was: Ariane 5 failure)

[Michael Feldman]

In article <1996Sep29.193602.17369@enterprise.rdd.lmsc.lockheed.com>,
Chris McKnight <cmcknigh@hercii.lasc.lockheed.com> wrote:

[Rich Pattis' good stuff snipped.]
>
>  An excellent bit of teaching, IMHO. Glad to hear they're putting some
>  more of the real world issues in the class room.

Rich Pattis is indeed an experienced, even gifted teacher of
introductory courses, with a very practical view of what they
should be about.

Without diminishing Rich Pattis' teaching experience or skill one bit,
I am somewhat perplexed at the unfortunate stereotypical view you
seem to have of CS profs. Yours is the second post today to have
shown evidence of that stereotypical view; both you and the other
poster have industry addresses.

This is my 22nd year as a CS prof, I travel a lot in CS education
circles, and - while we, like any population, tend to hit a bell
curve - I've found that there are a lot more of us out here than
you may think with Pattis-like commitment to bring the real world
into our teaching.

Sure, there are theorists, as there are in any field, studying
and teaching computing just because it's "beautiful", with little
reference to real application, and there's a definite place in the
teaching world for them.  Indeed, exposure to their "purity" of
approach is healthy for undergraduates - there is no harm at all
in taking on computing - sometimes - as purely an intellectual
exercise.

But it's a real reach from there to an assumption that most of us
are in that theoretical category.

I must say that there's a definite connection between an interest
in Ada and an interest in real-world software; certainly most of
the Ada teachers I've met are more like Pattis than you must think.
Indeed, it's probably our commitment to that "engineering" view
of computing that brings us to like and teach Ada.

But it's not just limited to Ada folks. I had the pleasure of
participating in a SIGCSE panel last March entitled "the first
year beyond language." Organized by Owen Astrachan of Duke,
a C++ fan, this panel consisted of 6 teachers of first-year
courses, each using a different language. Pascal, C++, Ada,
Scheme, Eiffel, and (as I recall) ML were represented.

The challenge Owen made to each of us was to give a 10-minute
"vision statement" for first-year courses, without identifying
which language we "represented." Owen revealed the languages to
the audience only after the presentations were done.

It was _really_ gratifying that - with no prior agreement or
discussion among us - five of the six of us presented very similar
visions, in the "computing as engineering" category. It doesn;t
matter which language the 6th used; the important thing was that,
considering the diversity of our backgrounds, teaching everywhere
from small private colleges to big public universities, we were
in _amazing_ agreement.

The message for me in the stereotype presented above is that it's
probably out of date and certainly out of touch. I urge my
industry friends to get out of _their_ ivory towers, and come
visit us. Find out what we're _really_ doing. I think you'll
be pleasantly surprised.

Especially, check out those of us who are introducing students
to _Ada_ as their first, foundation language.

Mike Feldman

------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
       Pork is all that money the government gives the other guys.
------------------------------------------------------------------------
WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/education
------------------------------------------------------------------------