Re: In defense of Admiral tuttle

Re: In defense of Admiral tuttle

[agate!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu]

In <EMERY.93Jul12113022@goldfinger.mitre.org> emery@goldfinger.mitre.org (David
 Emery) writes:

>And, if anyone has any doubts about the importance of software
>quality, I refer you to the recent IEEE Computer article by Nancy
>Levison, et al. analying software and system failures that caused a
>medical instrument to kill 6 people.  Military systems, when they
>malfunction, are much more dangerous (just ask any relatives of the
>people on the Iranian flight that the Navy's Aegis system shot down.)

Also note that there *was* no malfunction of the Aegis system.  It did
just what it was told to do.  The 'malfunction' was human.  This is
often the case when the system takes the blame.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: In defense of Admiral tuttle

[Robert Kitzberger]

Dr. Stephen G. Batsell <batsell@itd.nrl.navy.mil> writes:

>idea is the best tool for the job. If that requires a specialized
> language or version of a language that is fine. However, I will
>point out that SIM ++ which uses C++ is probably the best 
>distributed computing package available especially for simulation.

Remember, one of the main justifications for Ada's existence is the
overwhelming plethora of languages that DoD found itself stuck with in
the mid-70s.  Given your statement above, how would you prevent the
(re)creation of a Navy Tower of Babel?

	.Bob.
--
Bob Kitzberger                          Internet:   rlk@rational.com
Rational, Grass Valley, CA              CompuServe: 70743,1550
"Man is a rational animal who always loses his temper when he is called
 upon to act in accordance with the dictates of reason." -- Oscar Wilde

Re: In defense of Admiral tuttle

[news.intercon.com!eddie.mit.edu!magnesium.club.cc.cmu.edu!news.sei.cmu.ed]

In article <CA2qwH.L1G@ra.nrl.navy.mil> Dr. Stephen G. Batsell <batsell@itd.nrl
.navy.mil> writes:
>1) I wasn't limiting myself to just "traditional languages". The 
>idea is the best tool for the job. If that requires a specialized
> language or version of a language that is fine. However, I will
>point out that SIM ++ which uses C++ is probably the best 
>distributed computing package available especially for simulation.
>
>We are not pro or anti Ada. We are only 
>interested in software market realities and how this impact DoD systems. 

I believe Dr. Batsell has just elucidated a good point.  His comments
support the general case that Ada MUST be used wherever economically

possible.  It doesn't take a rocket scientist to figure out that
proliferation of "specialized" languages for "mainstream" software
development will drive up long-term costs like crazy.  This is
the very reason we are required to use Ada.  My company uses Ada
for their large, distributed simulations (including the B-2
simulator and the Space Station simulator).  I have serious
doubts that a research toy like SIM++ could stand up to the
weight or the requirements of such "industrial strength" systems.
Mind you, SIM++ has some interesting applications for small
simulations, but hardly represents the maturity of Ada.

I believe there is a place for "specialized" languages, such
as SIM++ (or DRAGOON :-), but to advocate their appearance
in fielded systems is tantamount to unraveling the LONG-TERM
strategy of the DoD.  

Now, I'm sure Greg would like to pipe in about "economic models",
to which I'm not likely to argue (much).  The bottom line is,
the "best tool for the job" is usually Ada, even if it doesn't
look like it in the next three years.  But, hey, most of are
Americans, right?  That means we can't see beyond the current
quarter for projections, much less the fiscal year. :-)
(Carefully notice the attached smiley).

-- 
-Comments above aren't neceessarily the opinion of the SEI, AJPO, or CAE-Link-
David Weller  |  Have you hugged your DRAGOON lately?
----I'm the Ultimate International Masochist: I speak Ada AND Esperanto!-----

Re: In defense of Admiral tuttle

[agate!howland.reston.ans.net!usc!cs.utexas.edu!milano!photon.mcc.com!brel]

In article 93Jul13120046@goldfinger.mitre.org, emery@goldfinger.mitre.org (Davi
d Emery) writes:
>A problem that I've seen with much of the rush towards 'consortium'
>solutions (and this is NOT a criticism of MCC or any particular
>consortium, but rather a criticism of "the rush") is that they tend to
>be very language and technology specific.  For instance, OSF's DCE has
>serious problems with respect to Ada, and even with respect to the
>emerging POSIX .4a standard.  The X Window System has had problems
>with concurrency until recently.  

[much good POSIX and language interoperability/unability stuff deleted]

I realize you weren't specifically calling out MCC as part of "the rush",
Dave, but you provided me with an entree to elaborate on a paradigm shift
we have here as well.  ;) Your point about the unsuitability of technology
and language specific solutions is 100% accurate.  Why?  Because the end
result is a point solution directed at a highly vertical slice of the
problem space.

I don't understand your indictment of consortiums as being pre-disposed to
address problems with such vertical solutions, unless, of course, all
members have an identical problem they want to solve in the same way.  The
system architecture migration topic I mentioned; however, represents the
more adaptable approach you recommend...to be responsive to a broad range
of technologies/languages.  We envision problem solutions to be inclusionary
rather than exclusionary because of the quite broad and eclectic mix of
our members.  Therefore, our implementations of major initiatives (such as
system migration) are language and hardware independent.

It does a major insurance company no good to be told we can convert any huge
mainframe dependent architecture to a parallel architecture at 5 times the
performance and half the expense, BUT ONLY IF the legacy code is written in
FORTRAN IV targeted for re-implementation as Lisp...and all the insurance
company's software is written in COBOL.  See?  So the point is, diverse
consortiums with common problems can yield robust, adaptable, and flexible
solutions...and that's the direction we deliberately pursue to provide the
most benefit for all our members.

---
Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC)
Advanced Systems and Networks                     | voice:    (512) 338-3509
3500 West Balcones Center Drive                   | FAX:      (512) 338-3900
Austin, Texas 78759-6509   USA                    | internet: breland@mcc.com

Re: In defense of Admiral tuttle

[munnari.oz.au!metro!usage!sserve!newshost.anu.edu.au!cairo!gsc]

Dr. Stephen G. Batsell <batsell@itd.nrl.navy.mil> writes:

> To use any language that is not true OOP for simulation is a mistake and
> deviates greatly from direction of the simulation community as a whole.

Could you please give us _your_ definition of "true OOP"? Everyone seems
to have their own these days...

Sean Case
--
Sean Case                                              gsc@coombs.anu.edu.au
"Oh, why must it always be enjoyment for us? Can't we suffer--can't we go on
suffering, forever and ever? Maskull, until love crushes our spirit, finally
and without remedy, we don't begin to feel ourselves."--A Voyage to Arcturus

Re: In defense of Admiral tuttle

[cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!source.asset.com!s]

 (David Weller) writes:
>
>....  It doesn't take a rocket scientist to figure out that
>proliferation of "specialized" languages for "mainstream" software
>development will drive up long-term costs like crazy.  ....

Right on.  It seems that in a great deal of the discussions about what
language is better that what language, the topics of longevity and
maintenance seem to be ignored.  This occurs to me a more of a cultural
problem than anything else.  We seem to have for too much concern on the
process of _developing_ software; when MOST programmers (gainfully
employed programmers) are working at _maintaining_ existing sofware.

The point to discuss is what features of a language, and ultimately a
methodology to use with that language will cause a reduction in the
ongoing costs of maintaining that software.

As a nation, we have several bridges and dams that are about to reach,
or have reached, the end of their 50 year life expectancy.  What now?
What is the average life expectancy of any given software system?  Why
are the numbers so small?

Hey gang, let's think about the future here.  The planet will be here
for quite some time to come, but what of us?

with Standard.Disclaimer;  -- that's some child package!
Keith Shillington;
FasTrak Training, San Diego Earth Day, Pragmatic Solutions, and other
hats as needed.  (shilling@asset.source.com)


-- 
  Keith Shillington               /---------\   "No matter where you go,
email: shilling@source.ASSET.com   /=======\     There you are."
voice: (619) 944-5134               /_____\          -- Buckaroo Banzaii
fax  : (619) 944-7089                 | |         office: (301) 924-0050