[comp.software-eng] bridge building

cml@tove.cs.umd.edu (Christopher Lott) (04/23/91)

In article <jls.672364339@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>.... until the 1800's, HALF of all bridges built fell down. Why? Because the
>principles of civil engineering were not well-understood, and so much of it
>was empirical and artistic: more craft than science. It is different now, but
>I bet for a while there were members of the old guard who protested loudly
>that civil engineering was not a science and never could be...just like hackers
>proclaim loudly now.


uh, half?  But I don't know any better.  However, I DO dispute your claim
that the bridge-builders of yore claimed that their craft would never be
a science.  They were developing the science of statics through trial
and error.  We're using trial and error, but I'm not convinced we're 
developing a science.  The high level of human creativity in every software
enterprise as compared to the creativity involved in a static structure like
a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes.  

On a positive note, I think that bridge builders of today are confident that
there are techniques developed by others that work, and they are happy to
(perhaps required to) use these techniques.  Compare this situation with
software, where we have a multitude of techniques, some quite rudimentary
and well accepted, yet there are developers who play cowboy and ignore the
helpful work done by others.  Either they suffer from NIH syndrome or are
simply ill informed.  What can be done to reach the ill-informed practictioner?

chris...
--
Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742
  cml@cs.umd.edu /\ 4122 AV Williams Bldg  301 405-2721 <standard disclaimers>

jls@rutabaga.Rational.COM (Jim Showalter) (04/25/91)

>The high level of human creativity in every software
>enterprise as compared to the creativity involved in a static structure like
>a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes.  

You miss my point--the high level of creativity required in software is
due to our not yet having a clue how to make writing software more like
building bridges. Bridge builders were undoubtedly VERY creative before
there was any grasp of how to build bridges.

>yet there are developers who play cowboy and ignore the
>helpful work done by others.

Exactly my point--and I believe this is BECAUSE they regard themselves
as these creative geniuses who don't NEED discipline, science, etc,
when in fact they're really sort of emotionally retarded wannabee
artistes.

>Either they suffer from NIH syndrome or are
>simply ill informed.  What can be done to reach the ill-informed practictioner?

Large caliber handguns come to mind...
--
* "Beyond 100,000 lines of code, you should probably be coding in Ada." *
*      - P.G. Plauger, Convener and Secretary of the ANSI C Committee   *
*                                                                       *
*                The opinions expressed herein are my own.              *

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (04/26/91)

From article <jls.672529800@rutabaga>, by jls@rutabaga.Rational.COM (Jim Showalter):
>>The high level of human creativity in every software
>>enterprise as compared to the creativity involved in a static structure like
>>a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes.  
 
> You miss my point--the high level of creativity required in software is
> due to our not yet having a clue how to make writing software more like
> building bridges. Bridge builders were undoubtedly VERY creative before
> there was any grasp of how to build bridges.

May I suggest that you both are missing a crucial point.  I have been
developing software for most of the last 25 years and I have worked for
quite a few companies.  From this experience, I have observed that most
software developers display the same level of creativity as the average
builder of culverts in CalTrans.  I have also observed that it is a
rare software developer indeed who displays the level of creativity
that can be seen in the Golden Gate Bridge or the Alfa Romeo Alfetta
GT.

From watching my wife, who is a structural engineer, and her
collegues, I would have to say that the average software engineer is 
somewhat less creative than the average structural engineer.  If you
look around a bit, you will probably conclude that the most creative
engineering going on right now is by European automotive engineers and
American aviation engineers.

>>yet there are developers who play cowboy and ignore the
>>helpful work done by others.
> 
> Exactly my point--and I believe this is BECAUSE they regard themselves
> as these creative geniuses who don't NEED discipline, science, etc,
> when in fact they're really sort of emotionally retarded wannabee
> artistes.

Well said, and very true.
 
>>Either they suffer from NIH syndrome or are
>>simply ill informed.  What can be done to reach the ill-informed practictioner?

> Large calliber handguns come to mind.

Perhaps a little extreem.  From what I have seen, a lot of these people 
are educable.  Most of them were put on the wrong track by "computer 
science" training in college and have never had the advantage of being 
trained by an engineer.  If all they have ever seen is
pseudo-scientists being technicians, that's all they will know how to
do.  The ones who won't learn you convey gently to the street.

Chris Prael

taylor@intellistor.com (Dick Taylor) (04/26/91)

In article <jls.672529800@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>The high level of human creativity in every software
>>enterprise as compared to the creativity involved in a static structure like
>>a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes.  
>
>You miss my point--the high level of creativity required in software is
>due to our not yet having a clue how to make writing software more like
>building bridges. Bridge builders were undoubtedly VERY creative before
>there was any grasp of how to build bridges.
>

Y'know, it occurs to me that your analogy is closer than you might think,
but not in a way that agrees with your central point.

I think that building _some_kinds_ of software is very much like building
bridges.  That is, the thing is expensive to produce, and so critical in
its function that any failure at all is potentially catastrophic and
certainly expensive.  Space shuttle operating software, for example,
fits nicely into this mold.

Other kinds of software may not have this level of expense and criticality. Or
they may not be susceptible to the same kind of orderly design methodology.

The problem with building everything as if it were a bridge is that bridges
cost lots to build (lots more per square foot than, for example, a parking
lot) and they take a lot of design and implementation time.  Civil engineering
has progressed to the point that bridges are built like bridges should be
built, buildings are build like buildings should be built, and parking lots
are built with as little effort as possible.  All done with good engineering.

I don't there there is or ever will be one and only one good method of
software engineering.  I think we do have a LONG way to go before we have
the methods as codified and tested as engineers in more concrete (ick. :-)
fields.  And I think your .sig indicates that you agree, or at least that
you quote someone who agrees:

>--
>* "Beyond 100,000 lines of code, you should probably be coding in Ada." *
>*      - P.G. Plauger, Convener and Secretary of the ANSI C Committee   *
>*                                                                       *
>*                The opinions expressed herein are my own.              *

That is, there are times when ANY software methodology may not work.

reggie@paradyne.com (George W. Leach) (04/26/91)

In article <1991Apr25.200023.5334@intellistor.com> taylor@intellistor.com (Dick Taylor) writes:
>I think that building _some_kinds_ of software is very much like building
>bridges.  That is, the thing is expensive to produce, and so critical in
>its function that any failure at all is potentially catastrophic and
>certainly expensive.  Space shuttle operating software, for example,
>fits nicely into this mold.

	IBM Houston is the ONLY SEI Level 5 organization that I know of.
They develop the space shuttle software.  However, cost is not a factor
in their development equation.

>Other kinds of software may not have this level of expense and criticality. Or
>they may not be susceptible to the same kind of orderly design methodology.

	Right.  We must make tradeoffs based upon constraints.  The trick
is to adequately balance quality, time, and money.  Unfortunately, most
organizations tend to focus on the later two and ignore the first.


-- 
George W. Leach					AT&T Paradyne 
reggie@paradyne.com				Mail stop LG-133
Phone: 1-813-530-2376				P.O. Box 2826
FAX: 1-813-530-8224				Largo, FL 34649-2826 USA

chaplin@keinstr.uucp (chaplin) (04/27/91)

In article <33407@mimsy.umd.edu> cml@tove.cs.umd.edu (Christopher Lott) writes:
>Either they suffer from NIH syndrome or are
>simply ill informed.  What can be done to reach the ill-informed practictioner?
>
>chris...
>--
>Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742
>  cml@cs.umd.edu /\ 4122 AV Williams Bldg  301 405-2721 <standard disclaimers>

First, identify them.  Being ill-informed, they are unaware of their condition,
right?

How to identify them?  (Here goes....) Measure their effectiveness.
-- 
Roger Chaplin                     | uunet!keinstr!chaplin | Don't blame my
Instruments Division Engineering  | CI$:   76307,3506     | company for my
Keithley Instruments, Inc.        | voice: (216) 498-2815 | opinions, nor me
Solon, Ohio  44139  USA           | FAX:   (216) 248-6168 | for theirs!

jls@rutabaga.Rational.COM (Jim Showalter) (04/27/91)

>I think your .sig indicates that you agree, or at least that
>you quote someone who agrees:

>>* "Beyond 100,000 lines of code, you should probably be coding in Ada." *
>>*      - P.G. Plauger, Convener and Secretary of the ANSI C Committee   *

>That is, there are times when ANY software methodology may not work.

Not at all--I have been involved in several MEGA-SLOC projects that
were completed satisfactorily. Clearly, something DID work. See, the
reason I think software can be engineered like anything else is that
I've seen that done in actual practice, and on some of the largest
and most complex projects ever attempted.

As for the quote itself, Plauger's point is that Ada is a language
designed from the ground up to support software engineering, whereas
C most decidedly is not (I do hear they recently made it harder to
pass an arbitrary number of arguments of arbitrary type to a C function,
so I guess progress is being made....).
--
* "Beyond 100,000 lines of code, you should probably be coding in Ada." *
*      - P.G. Plauger, Convener and Secretary of the ANSI C Committee   *
*                                                                       *
*                The opinions expressed herein are my own.              *

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (04/30/91)

From article <jls.672700751@rutabaga>, by jls@rutabaga.Rational.COM (Jim Showalter):
 
> As for the quote itself, Plauger's point is that Ada is a language
> designed from the ground up to support software engineering, whereas
                                 ^^^^^^^
Judging from the rest of this paragraph, you seem to mean 'force'
rather than 'support'.

> C most decidedly is not (I do hear they recently made it harder to

If you can't engineer software well in C, you can't engineer software
well period!

> pass an arbitrary number of arguments of arbitrary type to a C function,
> so I guess progress is being made....).

One of the grossest conceptual errors of well intended designers is the
idea that it is useful to constrain a programmer to do the right thing.
While it is demonstrably useful to harness, bridle, and blinder a draft
animal, it is just as obviously disfunctional to try to do this with
programmers/engineers/designers.  Tools that control the programmer can
only do so by disabling.  The result is not a technician forced to
behave like an engineer but a hobbled technician.

Chris Prael

koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/02/91)

In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:
>
>> C most decidedly is not (I do hear they recently made it harder to
>
>If you can't engineer software well in C, you can't engineer software
>well period!
>

Tell that to AT&T after their 1-800 blunder.  That error would have been
less likely in different language (like Ada - I had to say that.).

Harry Koehnemann
koehnema@enuxha.eas.asu.edu

cml@care.cs.umd.edu (Christopher Lott) (05/02/91)

>In article <> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:
>If you can't engineer software well in C, you can't engineer software
>well period!

In article <> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) replies:
>Tell that to AT&T after their 1-800 blunder.  That error would have been
>less likely in different language (like Ada - I had to say that.).

This is a red herring.  I assume you refer to the failure of switching
software that resulted from a missing "break" statement.  We can go around
and around, arguing that this was caused by the use of C, but it's not IMHO
productive to do so.  

There are classes of faults that are more prevalent in some languages than
others.  I'm not proficient enough in Ada to give a counter example, and
actually it's better that I don't, because that would just set off more flame
wars.

Let's discuss how we can identify these classes of faults, so we are
able to say before code reviews "watch out for this class of mistakes." 
What are the classes of faults which occur most often in your environment?
How expensive are they to identify, fix?  (In the previous red herring,
due to the application, pretty darned expensive if missed.)

I agree with Chris Prael's first comment - the syntax and low-level issues
of your development language are important, but other issues dominate.  

chris...
--
Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742
  cml@cs.umd.edu /\ 4122 AV Williams Bldg  301 405-2721 <standard disclaimers>

koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/02/91)

In article <33846@mimsy.umd.edu> cml@care.cs.umd.edu (Christopher Lott) writes:
>
>Let's discuss how we can identify these classes of faults, so we are
>able to say before code reviews "watch out for this class of mistakes." 
>What are the classes of faults which occur most often in your environment?
>How expensive are they to identify, fix?  (In the previous red herring,
>due to the application, pretty darned expensive if missed.)
>

It's more than that.  The point is that the error was not caused by
a single programming mistake.  It was designed, reviewed, and tested
extensively (I hope).  Therefore, we must blame th process as being
inadequate to catch that type of error.  Now, is that type of error
less likely to occur in a strongly typed language that strictly enforces
well identified software engineering principles (which C does not).
I'd say yes.  Hell, anyone that uses a break stmt to transfer control
out of an if probably needs a little help.

hammondr@sunroof.crd.ge.com (Richard A Hammond) (05/02/91)

In article <33846@mimsy.umd.edu> cml@care.cs.umd.edu (Christopher Lott) writes:

>Let's discuss how we can identify these classes of faults, so we are
>able to say before code reviews "watch out for this class of mistakes." 
>What are the classes of faults which occur most often in your environment?
>How expensive are they to identify, fix?  (In the previous red herring,
>due to the application, pretty darned expensive if missed.)
>It's more than that.  The point is that the error was not caused by

To which, In article <9105020234.AA01202@enuxha.eas.asu.edu>
koehnema@enuxha.eas.asu.edu (Harry Koehnemann) responds:

>a single programming mistake.  It was designed, reviewed, and tested
>extensively (I hope).  Therefore, we must blame th process as being
>inadequate to catch that type of error.  Now, is that type of error
>less likely to occur in a strongly typed language that strictly enforces
>well identified software engineering principles (which C does not).
>I'd say yes.  Hell, anyone that uses a break stmt to transfer control
>out of an if probably needs a little help.

Does anybody have the actual code fragment and what it should have been?
What follows may not apply (but neither may Harry's comment above).

BULL!!! Harry, the error has nothing to do with typing, strong or weak, it
was a syntax error, according to your description.  In fact, the same
error could be made in Ada, i.e. using 'exit' out of an  if statement
which is inside a loop, e.g. (formatted to line up parallel constructs)
  Ada version                         C Version

  loop                                for ....
                                      {
      if condition                        if ( condition )
      then                                {
          do_something;                       do_something;
          exit;                               break;
      end if;                             }
      something_else_to_do;               something_else_to_do;
  end loop;                           }

Now I admit that the actual description I heard, which was similar to
that given by Harry, was:
  using a break statement to terminate an if,
makes no sense to me, i.e. it would be like saying that they used exit
to terminate an if in Ada.  Both only work in the syntax of the language
if there is an outer loop (or case statement in C).

As far as a language that supports "software engineering prnciples",
I fail to see how this would help in this case.  The error was inside
a single module.

I've done 13 years of programming in C, and spent the last two using Ada.
While I much prefer using Ada to C, I won't be so bold as to claim that
they make any difference in my error rate or productivity.

In fact, I strongly suspect that some of the Ada sucess stories I've
been hearing, on closer examination are examples of the Hawthorn effect,
i.e. management pays attention to what's going on and gets better results.

Disclaimer: my opinions are my own and not GE's.
Rich Hammond

adam@visix.com (05/02/91)

In article <9105020234.AA01202@enuxha.eas.asu.edu>, koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) writes:

|>   The point is that the error was not caused by
|> a single programming mistake.  It was designed, reviewed, and tested
|> extensively (I hope).  Therefore, we must blame th process as being
|> inadequate to catch that type of error.

I'm sorry, but you can't blame an entire process based on a single
data point.  You may well argue that C is statistically more likely
to have errors, but that is a different argument, for which
anecdotes are irrelevant.

Adam

chaplin@keinstr.uucp (chaplin) (05/03/91)

In article <9105012313.AA23259@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes:
>In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:
>>If you can't engineer software well in C, you can't engineer software
>>well period!
>>
>
>Tell that to AT&T after their 1-800 blunder.  That error would have been
>less likely in different language (like Ada - I had to say that.).
>
>Harry Koehnemann
>koehnema@enuxha.eas.asu.edu

Baloney!  Read what Chris Prael said!  The fact that it is *possible* to
engineer software well in *any* language does not mean that well-engineered
software is guaranteed.  Perhaps the blunder would not have happened had
AT&T used Ada, but using Ada would not have guaranteed that the blunder would
not have happened.

If I have a hacksaw but not a wrench, I can still remove a bolt.  It may
be easier and I may like the result better if I have a wrench.  I have
programmed large systems using Forth (no flames, please!) and small systems
using C.  Had it been the other way around I probably would not have spent
as much time programming these systems, but the fact remains that they both
perform to specs.
-- 
Roger Chaplin / Instruments Division Engineering / uunet!keinstr!chaplin
CI$: 76307,3506 / voice: (216) 498-2815 / FAX: (216) 248-6168
"In the last analysis the customer is the independent auditor.  In the
merciless light of real use, every flaw will show." - Frederick P. Brooks, Jr.

alesha@auto-trol.com (Alec Sharp) (05/04/91)

In article <1991May3.142824.208@keinstr.uucp> chaplin@keinstr.uucp (chaplin) writes:
>In article <9105012313.AA23259@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes:
>>In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:
>>>If you can't engineer software well in C, you can't engineer software
>>>well period!
>>>
>>
>>Tell that to AT&T after their 1-800 blunder.  That error would have been
>>less likely in different language (like Ada - I had to say that.).
>>
>>Harry Koehnemann
>>koehnema@enuxha.eas.asu.edu
>
>Baloney!  Read what Chris Prael said!  The fact that it is *possible* to
>engineer software well in *any* language does not mean that well-engineered
>software is guaranteed.  Perhaps the blunder would not have happened had
>AT&T used Ada, but using Ada would not have guaranteed that the blunder would
>not have happened.

All this talk about C and software engineering reminds me of the NRA 
argument - guns aren't dangerous, people are dangerous.  Sure, you can
do software engineering in C, but most people don't.  Maybe the people
defending C as a software engineering tool force themselves to abide
by various conventions but most people I've worked with don't.  In my
experience there are too many hackers out there, and they love C
because it let's them hack.

So, are they the dangerous ones, or is it C that's dangerous because
it lets them skip the software engineering part of things and go 
straight to the serious hacking part.

Of course, I'm sure all you fellow posters are very responsible
with your guns, and I'm sure you impose a lot of discipline on
your C development.  I'm just not sure about all the others out there.

Incidentally, C is my favorite language, and I've never worked with
Ada, so I'm not biased.  I just happen to think that C only works with
software engineering if discipline is mixed in, and this seems to be a
commodity in short supply, certain among most of the software 
developers I've worked with in the last ten years.

So, people being people, I sort of figure I'm safer if no one has
guns, and I sort of figure people do better software engineering if
they have a language more conducive to it than C.

Alec Sharp
-- 
------Any resemblance to the views of Auto-trol is purely coincidental-----
Don't Reply - Send mail: alesha%auto-trol@sunpeaks.central.sun.com
Alec Sharp           Auto-trol Technology Corporation
(303) 252-2229       12500 North Washington Street, Denver, CO 80241-2404

koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/06/91)

(Richard A Hammond) writes:
> BULL!!! Harry, the error has nothing to do with typing, strong or weak, it
> was a syntax error, according to your description.  In fact, the same
> error could be made in Ada, i.e. using 'exit' out of an  if statement
> which is inside a loop, e.g. (formatted to line up parallel constructs)

But it wasn't a syntax error or the compiler would have caught it, or
at least warned about it.  That's part of the point - a language should
allow a programmer to convey as much information as possible.  I agree
the error could have happened in Ada, but is it less likely?  Break is
an integral part of C - you cannot write a switch without it.  You don't
need exit in Ada.  When you teach an Ada class, do you mention exit or
goto?  Probably not - it's like showing a child where you store your
gun.  Therefore, if your not using it, it can't hurt you.

> As far as a language that supports "software engineering prnciples",
> I fail to see how this would help in this case.  The error was inside
> a single module.

My point is that, if proper techinques are strictly followed, errors
are less likely and IMO C does not support them very well.  Things like
encapsulation and ADTs, separating specification from implementation,
packaging, private sections, parameter modes, overloading, a powerful
typing mechanism, etc. allow a programmer to express more information
to a compiler and allow it to catch more 'this is a stupid thing and I'm
not going to let you do it' errors.  This is not very well supported in
C.  Granted it can be done, just like that error could have been written
in Ada, but it is much more work and IMO it is not as likely to happen.
However, it has been rather interesting watching people run to C's
defense :).  Hell, it all started out as a joking comment anyways.

> In fact, I strongly suspect that some of the Ada sucess stories I've
> been hearing, on closer examination are examples of the Hawthorn effect,
> i.e. management pays attention to what's going on and gets better results.

Good point.  Many claim that the largest benefit of this entire
Ada thing will be that programmers will be forced to get training.
While they're learning the language, they'll also be reinforced (or
introduced) to some solid principles as well.

Have a nice day....
Harry Koehnemann
koehnema@enuxha.eas.asu.edu

hammondr@sunroof.crd.ge.com (Richard A Hammond) (05/06/91)

In commenting about the AT&T error I wrote:
As far as a language that supports "software engineering prnciples",
I fail to see how this would help in this case.  The error was inside
a single module.

In article <9105051741.AA27297@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) replies:
>My point is that, if proper techinques are strictly followed, errors
>are less likely and IMO C does not support them very well.  Things like
>encapsulation and ADTs, separating specification from implementation,
>packaging, private sections, parameter modes, overloading, a powerful
>typing mechanism, etc. allow a programmer to express more information
>to a compiler and allow it to catch more 'this is a stupid thing and I'm
>not going to let you do it' errors.  This is not very well supported in
>C.  Granted it can be done, just like that error could have been written
>in Ada, but it is much more work and IMO it is not as likely to happen.

All these are good things that Ada does, but they don't apply to the
specific bug in question.  The bug wasn't 'stupid' in that one could
very easily really want the program to have control flow as specified.

>However, it has been rather interesting watching people run to C's
>defense :).  Hell, it all started out as a joking comment anyways.

You're wrong, I am not defending C, I am against the following logic:

Premise 1: Ada supports Software Engineering better than C	(I agree)

Premise 2: AT&T switching code was written in C		(I agree)

Premise 3: AT&T switching code had a 'bug'		(I agree)

Conclusion: the bug would have been prevented by using Ada.	(doesn't follow)

If the bug had been an argument type mis-match error or some other interface
error I would accept that Ada could have prevented it.  But, as far as the
actual error involved, it was one that put a break statement in a logically
incorrect but syntactically legal location.  Ada wouldn't have prevented
this.  Without the actual code fragment in C and what it should have
been we can't even say that Ada would have made it mroe difficult.

Cheers,
Rich Hammond

koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/08/91)

[Talking about AT&T bug - using a break to transfer out of an if stmt]

>All these are good things that Ada does, but they don't apply to the
>specific bug in question.  The bug wasn't 'stupid' in that one could
>very easily really want the program to have control flow as specified.

Bite your tongue :).  You *want* to transfer control out of the middle
of a block?  Remember single entry/exit?  Really, if that had been flight
system software and had caused a casualty, do you think a victims lawyer
would be glad or disappointed to find it was caused by that type of an
error?  i.e. One that they could easily show does not follow good
practices.  When you think about it, AT&T got off rather cheap.

>You're wrong, I am not defending C, I am against the following logic:
	[middle logic deleted]
>Conclusion: the bug would have been prevented by using Ada.  (doesn't follow)

But I have never said 'prevent' as you've been saying.  Hell, nothing
prevents errors.  Can we do anything to prevent errors?  No, we can
simple decrease the likelyhood that they exists.  All this time I've been
saying 'less likely' and since 'exit' is not an integral part of Ada as
'break' is with C (you won't use it if you don't need it and you can't
use it if you don't know it's there, or better yet *forbidden*), "that
error might have been less likely in a different language". --orig stmt

I'll talk to you by Email next time - I'm sure
everones bored of this by now...
Harry Koehnemann
koehnema@enuxha.eas.asu.edu

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/09/91)

From article <1991May3.234349.14026@auto-trol.com>, by alesha@auto-trol.com (Alec Sharp):
> 
> All this talk about C and software engineering reminds me of the NRA 
> argument - guns aren't dangerous, people are dangerous.  Sure, you can

You ever have someone come after you with a carving knife or a tire iron?
I haven't either, but if someone did, it wouldn't make the least little
bit of difference that neither device can throw lead.

> do software engineering in C, but most people don't.  Maybe the people
> defending C as a software engineering tool force themselves to abide
> by various conventions but most people I've worked with don't.  In my
> experience there are too many hackers out there, and they love C
> because it let's them hack.

The point that you seem to me to be missing is that the languages that
attempt to force the programmer into "good" practices do no better than
C.  

No one has built a compiler that can force you to get or develop a clear 
statement of requirements.  No one has built a compiler that can force 
you to completely design the functionality of a program (or even 
partially, for that matter).  No one has built a compiler that can force
you to have peers and/or users review your design.  No one has built a
compiler that will force you to design how the program will implement the
functionality you have arrived at.

These are the processes that an "engineer" goes through, whether s/he is
building software, a disk drive, a car engine, or a bridge.  If you are
not going through these processes, you are not an engineer and no
compiler yet imagined can help or force you to be one.

If you just sit down and start bashing out code, you are hacking, no
matter how "clean" the code is.

Chris Prael

rlk@telesoft.com (Bob Kitzberger @sation) (05/13/91)

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:

>The point that you seem to me to be missing is that the languages that
>attempt to force the programmer into "good" practices do no better than
>C.  

Nope, that's the point that is _denied_, not missed.

>No one has built a compiler that can force you to get or develop a clear 
>statement of requirements.  No one has built a compiler that can force 
>you to completely design the functionality of a program (or even 
>partially, for that matter).  No one has built a compiler that can force
>you to have peers and/or users review your design.  No one has built a
>compiler that will force you to design how the program will implement the
>functionality you have arrived at.

All valid points, however, there are languages that _encourage_ good
software engineering practices, e.g. separation of specification and
implementation, strong type checking, inter-module dependency
verification, etc.  C isn't one of them.  Can this honestly be denied?   

>These are the processes that an "engineer" goes through, whether s/he is
>building software, a disk drive, a car engine, or a bridge.  If you are
>not going through these processes, you are not an engineer and no
>compiler yet imagined can help or force you to be one.
		       ^^^^^^^^
		       big difference between helping and forcing.

Yes, but insistence on using a tool that discourages engineering 
discipline warrants justfication!  Simile and analogy seem to be popular in
this newsgroup lately... let me draw another.   I'm marginally content
that small housing structures are built with relatively quick,
low accuracy techniques.  HOWEVER, if a builder uses the same tools and
techniques to build skyscrapers and large public buildings that he
uses to slap together a condo complex, they're setting themselves up
for a serious lawsuit.  The tools must scale up with the complexity of
the project.  The complexity of software systems is growing quickly, 
such that there are rarely any projects under 100,000 SLOC (sweeping
assumption).  It borders on negligence to build these systems
with nothing more than a screwdriver, a hammmer, and a level, despite
any commitment to modern software engineering principles.

	.Bob.
-- 
Bob Kitzberger               Internet : rlk@telesoft.com
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA  92121-9891  (619) 457-2700 x163
------------------------------------------------------------------------------
"Wretches, utter wretches, keep your hands from beans!"	-- Empedocles

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/16/91)

From article <1264@telesoft.com>, by rlk@telesoft.com (Bob Kitzberger @sation):
 
> All valid points, however, there are languages that _encourage_ good
> software engineering practices, e.g. separation of specification and
> implementation, strong type checking, inter-module dependency
> verification, etc.  C isn't one of them.  Can this honestly be denied?   

It is very easy to deny for the simple reason that you are not talking
about engineering practices, you are talking about software coding
practices.  Coding is not an engineers issue, it is a technicians
issue.

If you are willing to be accurate enough to assert that C++, for example, 
forces better CODING practices, there is no impediment to agreeing with 
you.  But any claims that mechanisms that operate on a technicians 
performance is erroneously putting software engineering on teh same
level as field engineering and custodial engineering.  I hope that is
not your intent.
 
> Yes, but insistence on using a tool that discourages engineering 
> discipline warrants justfication!  

The problem with your assertion is that the tool, C,  has no effect on 
ENGINEERING discipline.  It does have some connection with coding 
discipline.  In a real engineering environment, coding discipline is a 
very minor issue, if it is an issue at all.

Sure, C lets a software blacksmith be a real slob.  C++ can make the
software blacksmith a much tidyer blacksmith.  But neither of them can
turn a blacksmith into an engineer.

Chris Prael

dmg@ssc-vax (David M Geary) (05/17/91)

Chris Prael writes:

]]From article <1991May3.234349.14026@auto-trol.com], by alesha@auto-trol.com (Alec Sharp):
]] 
]] argument - guns aren't dangerous, people are dangerous.  Sure, you can
]] do software engineering in C, but most people don't.  Maybe the people
]] defending C as a software engineering tool force themselves to abide
]] by various conventions but most people I've worked with don't.  In my
]] experience there are too many hackers out there, and they love C
]] because it let's them hack.

]The point that you seem to me to be missing is that the languages that
]attempt to force the programmer into "good" practices do no better than
]C.  

  I'm not sure what this means - no better than C *at what*.  If Chris
means that other languages' attempts to force (or help) programmers to write 
better code are all failures, that is certainly arguable.

]No one has built a compiler that can force you to get or develop a clear 
]statement of requirements.  No one has built a compiler that can force 
]you to completely design the functionality of a program (or even 
]partially, for that matter).  No one has built a compiler that can force
]you to have peers and/or users review your design.  No one has built a
]compiler that will force you to design how the program will implement the
]functionality you have arrived at.

  No one has built a compiler that washes dishes either.  *Compilers* are not
meant to help you one bit with requirements, or force humans to perform
certain actions, such as reviewing a design.  Compilers are meant to 
produce executables from code, and help the programmer by pointing out
errors and warnings found in the code.  There are *environments* available
that can assist in the things mentioned above.

  Note too that IMHO, compilers have been written that do a better job of 
*helping* the programmer write correct code than C compilers.  C's lax type 
checking of function calls is not a problem with many other languages (although
that has been alieviated with ANSI C).  Eiffel for example, has assertions and 
exceptions - two important tools not supported by C compilers that allow 
programmers to produce better code.

]These are the processes that an "engineer" goes through, whether s/he is
]building software, a disk drive, a car engine, or a bridge.  If you are
]not going through these processes, you are not an engineer and no
]compiler yet imagined can help or force you to be one.

  Well, I'm not so sure.  The field of software engineering is very young.
Like other "sciences", (please - no thread on whether sw engr is science and/or
engineering) I am sure that some of the things that we think are gospel today
will prove to be folly tomorrow.  One example would be structured (top-down)
design, which, when used to specify a *system* is at odds with the current
methods of object-oriented programming.  Thus, structured programming, 
previously thought to be one of the processes that a "software engineer" 
must go through to properly construct software, may turn out to be a 
methodology best avoided.

]If you just sit down and start bashing out code, you are hacking, no
]matter how "clean" the code is.

  I can agree with this.  There is a difference between software engineering
and hacking.  C has a reputation (well-deserved or not) of being used mainly
by hackers who know nothing of "software engineering principles".  Like all
sterotypes this perception is to some degree true.  However, it does not
automatically follow that noone can "software engineer" if they are using C.

]Chris Prael

rlk@telesoft.com (Bob Kitzberger @sation) (05/22/91)

chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:

>From article <1264@telesoft.com>, by rlk@telesoft.com (Bob Kitzberger @sation):
> 
>> All valid points, however, there are languages that _encourage_ good
>> software engineering practices, e.g. separation of specification and
>> implementation, strong type checking, inter-module dependency
>> verification, etc.  C isn't one of them.  Can this honestly be denied?   
>
>It is very easy to deny for the simple reason that you are not talking
>about engineering practices, you are talking about software coding
>practices.  Coding is not an engineers issue, it is a technicians
>issue.

The division at coding seems somewhat arbitrary... with higher levels of
abstraction, your requirements tool becomes your design tool becomes your 
coding tool.

Nonetheless, assuming that I take off my engineer's hat and put on the
rumpled technicians hat when I code, I am forced to deal with the errors
of my designs.  Tools (and in this context, languages) that help point
out flaws in design (see list in original post) help me to learn _some_
of my design mistakes earlier in the process.  Being the good engineer that 
I am, I carry these lessons with me when I again don my engineer's hat.

I maintain that separation of specification and implementation is
a strong design tool, as are Ada's exceptions and Eiffel's assertions.
As languages provide more and more "design level" capabilities such
as these, the importance of them in the design process increases.

>If you are willing to be accurate enough to assert that C++, for example, 
>forces better CODING practices, there is no impediment to agreeing with 
>you.  

Ah, but I used the word "encourage" (highlighted, even), not "force".  
BIG difference.  Anybody can write FORTRAN in Ada, if they're determined.

>Sure, C lets a software blacksmith be a real slob.  C++ can make the
>software blacksmith a much tidyer blacksmith.  But neither of them can
>turn a blacksmith into an engineer.

Agreed.  My assertion was that some languages _encourage_ better engineering
practices.  This is not the same assertion that some people make -- 
that using a certain language _forces_ better engineering practices.

	.Bob.
-- 
Bob Kitzberger               Internet : rlk@telesoft.com
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA  92121-9891  (619) 457-2700 x163
------------------------------------------------------------------------------

dc@sci.UUCP (D. C. Sessions) (05/23/91)

In article <1338@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes:
# From article <1264@telesoft.com>, by rlk@telesoft.com (Bob Kitzberger @sation):
#  
# > All valid points, however, there are languages that _encourage_ good
# > software engineering practices, e.g. separation of specification and
# > implementation, strong type checking, inter-module dependency
# > verification, etc.  C isn't one of them.  Can this honestly be denied?   
# 
# It is very easy to deny for the simple reason that you are not talking
# about engineering practices, you are talking about software coding
# practices.  Coding is not an engineers issue, it is a technicians
# issue.

  [etc. -- dcs]

# Chris Prael

  We seem to have some major differences between our definitions of 
  "engineering".  From where I sit (which is frequently behind a 
  soldering iron) engineers are the folks who *document* the *process* 
  which results in a *product*.  I wish *I* could get away with 
  telling the manufacturing department that a calibration procedure
  "is not an engineers issue, it is a technicians issue".  (I won't, 
  though -- I need the work!)

  An engineer doesn't live in lofty isolation from the grungy details 
  of production.  Instead, most of an engineer's work concerns making 
  the most cost-effective use of the "materials" available.  If that 
  means steel instead of carbon composites, or 7400 TTL instead of the 
  latest GaAs logic, or C instead of Ada; well, so be it.  If s/he 
  *does* end up with steel instead of fiber, though, the design had 
  better be optimized for steel.

  Similarly, if the mandated toolset only supports global scoping a 
  competant software engineer plans in the manual symbol-space 
  management instead of whining "that's not my job."

----------------------------------------------------------------------
  Sorry, folks.  My sysadmin informed us today that the company is
  cutting our net access to save on phone bills.  I guess I won't be 
  getting any flames, will I?
----------------------------------------------------------------------
-- 
| The above opinions may not be original, but they are mine and mine alone. |
|            "While it may not be for you to complete the task,             |
|                 neither are you free to refrain from it."                 |
+-=-=-    (I wish this _was_ original!)        D. C. Sessions          -=-=-+