Open comment to Ted Holden

Open comment to Ted Holden

[SAHARBAUGH]

Ted,
  You do not seem to grasp the difference between the mission of
the US Army and the mission of commercial software vendors.
The US Army must defend our country and keep you and I and
our decendants safe.  The commercial software vendors must
make a profit for their stockholders.
  You do not seem to grasp the difference in performance
requirements ofr military software vs commercial software.
Military software must work or we may lose the war.  I urge
you to talk to some survivors from countries who lost wars.
Theirs is not a pleasant story, and they were the survivors.
Commercial software must only work well enough so that someone
will buy it and continue to buy the upgrades. I personally
call commercial software "crap for brains".  I have examples
to back that up.
  No matter what Army software costs it is cheaper than the
alternative.  Imagine an enemy with Apache helicopter
equivalents in your home town for an hour. The national
debt may be huge but it is not as huge as the cost of
rebuilding Wash DC or New Yoork after a nuclear attack.
And, as an extra added benefit, we are alive and well
and our infrastructure is intact and we can work to
pay off that debt.
  I agree with NOTHING you say but I defend your right
to say it.
sam harbaugh saharbaugh@ROO.FIT.EDU        
-----------
ps: pls excuse the typos
---

Re: Open comment to Ted Holden

[Gregory Aharonian]

Sam,
	Maybe Ted is unsuccessfully trying to say that while Ada is more
safe and reliable to program in than other computer languages and commercial
software products (which is a very desirable for the military), it is not
more cost effective (that is, with different policies, other languages or
off-the-shelf stuff can be used and still meet mission requirements).
	I do not believe that Ada is more cost effective to program in than
other languages, and I do not believe that anyone can prove that it is,
given the poor understanding of software microeconomics inside the DoD, and
the lack of large enough amounts of cost data and models to prove so. Thus
many of the public posturings about Ada's great cost benefit are of little
worth.  Defend Ada because it is a safer language to program in, not because
of the cost economics.  Maybe that what Ted is saying.
	A point in his favor, though, is that military specifications and
procedures are excessive.  A good number of soldiers ordered commercial,
off-the-shelf GPS recievers with their credit cards during the Gulf War,
and had no complaints about their operations, especially those whose lives
were saved.  If commercial, off-the-shelf, less mil-spec equipement passed
the test of combat, maybe the DoD software standards are as excessive. Also,
many commercial systems developed in other languages successfully handle
commercial mission critical tasks, for example, the programs that handle the
transactions of the stocks, commodities and international monetary exchanges,
each day handling tens of billions of dollars.

	Throwing money at Ada as a very safe, reliable system for mission
critical systems is justifiable, giving the lives and freedoms at stake.
Doing so because Ada is more cost-effective is a silly attempt by socialists
to act like captilists.  No one cares, as long as they defend the country.

Greg Aharonian
Source Translation & Optimization

Re: Open comment to Ted Holden

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uwm.edu!za]

SAHARBAUGH@ROO.FIT.EDU writes:
>  No matter what Army software costs it is cheaper than the
>alternative.  Imagine an enemy with Apache helicopter
>equivalents in your home town for an hour. The national
>debt may be huge but it is not as huge as the cost of
>rebuilding Wash DC or New Yoork after a nuclear attack.
>And, as an extra added benefit, we are alive and well
>and our infrastructure is intact and we can work to
>pay off that debt.

Does this argument extend to hardware too?  Like $500 toilet seats?

--Eric Nedervold

Re: Open comment to Ted Holden

[david.c.willett]

>From article <1992Apr9.155334.20536@schaefer.math.wisc.edu>, by nedervol@schae
fer.math.wisc.edu (Eric Nedervold):
> SAHARBAUGH@ROO.FIT.EDU writes:
>>  No matter what Army software costs it is cheaper than the
>>alternative.  Imagine an enemy with Apache helicopter
>>equivalents in your home town for an hour. The national
>>debt may be huge but it is not as huge as the cost of
>>rebuilding Wash DC or New Yoork after a nuclear attack.
>>And, as an extra added benefit, we are alive and well
>>and our infrastructure is intact and we can work to
>>pay off that debt.
> 
> Does this argument extend to hardware too?  Like $500 toilet seats?
> 
> --Eric Nedervold
>

Oh, I *had* to jump in here on this one.  The issue in the original post
as well as the two follow-ups I've read seems to be:

	Are MIL-SPECs worth the cost?  They sure don't seem to be, but
we haven't had to re-fight WWII yet.  I have worked with 40-year old 
MIL-SPEC hardware that wouldn't have been available to me if it hadn't 
been built so ruggedly.  Greg pointed out that commercial GPS receivers
served well in the Gulf.  I would point out that the ground war there 
lasted approx. 100 hours and the entire military campaign less than
3 months.  In my opinion, that is not a fair test.  

Remember that military equipment must be able to function in spite of battle 
damage.  In a system heavily dependent on software (most are nowdays), 
survivability has a lot to do with the software being modular as well as being
able to respond to exceptions (i.e. that channel is down -- use another).  It
seems to me that Ada was designed to facilitate production of that sort of 
software.

With regard to Ada not being cost effective, I would submit that the
"commercial" world has not yet reached the degree of dependence on software tha
t
our high-tech military "enjoys".  It is getting there fast though.  I think
Ada's advantages will become apparent in the commercial world in the next 
decade.  Of course, just because the advantages of software engineering 
methodology become well known, doesn't mean that Ada itself will be successful.
There could very well be newer languages that will do what Ada does "better".
When these languages arrive, DoD would do well to encourage their use.

Dave

Re: Open comment to Ted Holden

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!cs.utexas.e]

In <1992Apr9.155334.20536@schaefer.math.wisc.edu> nedervol@schaefer.math.wisc.e
du (Eric Nedervold) writes:

>Does this argument extend to hardware too?  Like $500 toilet seats?

I believe that most of these popular DoD-bashing anecdotes are driven
by:

a) Poor or overlooked requirements specifications that cause things
   like expensive coffee pots because all equipment on a certain
   aircraft has some blanket requirement that it be radiation-hardened
   or will continue to operate if the aircraft is inverted!

b) The result of cost-recovery by contractors driven by the current
   government procurement practises that almost preclude accurately
   costed proposals from winning contracts.

c) Blanket requirements for specifications and documentation, that,
   for example, drive up the procured cost of what the "general
   public" could buy commercially.

I think it is specious to introduce hot button phrases like
"$500 toilet seats" into some people's attempts at a rational
discussion on software technology transfer.

--Rob   spray@convex.com

Flaming for myself.

Re: Open comment to Ted Holden

[Brian Hanafee]

In article <spray.702841253@convex.convex.com> spray@convex.com (Rob Spray) wri
tes:
>In <1992Apr9.155334.20536@schaefer.math.wisc.edu> nedervol@schaefer.math.wisc.
edu (Eric Nedervold) writes:
>>Does this argument extend to hardware too?  Like $500 toilet seats?
>
>I believe that most of these popular DoD-bashing anecdotes are driven
>by:
>
> [first 3 reasons deleted]

d) Incomplete stories being told to the public by people such as Sen.
   Proxmire.  As I got the story (2nd hand from an ex-Lockheed
   employee), the famous $500 toilet seat was a part from the P-3
   Orion (a submarine chasing aircraft with a very long endurance).
   To reduce weight, all of the interior wall panels were molded from
   a Kevlar/resin material.  One of the moldings (for an entire wall
   panel) included the toilet seat as an integral part.  The entire
   custom wall panel cost $500.

e) Stockpiling requirements.  Since many DoD contracts require that
   the manufacturer be able to provide spares for many years, and the
   parts are often custom built, the price includes the cost of
   keeping the part in inventory for years at a time (usually cheaper
   than restarting the production line years into the contract for one
   or two parts).  Commercial companies avoid this problem by making
   customers buy entire new systems.


>--Rob   spray@convex.com
--
Brian Hanafee                         Advanced Decision Systems
bhanafee@ads.com                      1500 Plymouth Street
(415) 960-7300                        Mountain View, CA 94043-1230

Re: Open comment to Ted Holden

[Dan Vanderwerken]

In article <SRCTRAN.92Apr9102404@world.std.com> srctran@world.std.com (Gregory 
Aharonian) writes:
>Sam,
[stuff about Ada not being cost effective deleted....]
>A good number of soldiers ordered commercial,
>off-the-shelf GPS recievers with their credit cards during the Gulf War,
>and had no complaints about their operations, especially those whose lives
>were saved.  If commercial, off-the-shelf, less mil-spec equipement passed
>the test of combat, maybe the DoD software standards are as excessive. 
>Greg Aharonian
>Source Translation & Optimization

This thread certainly looks like it will provide lively discussion for this
group...I'd like to throw in my two cents too:

As far as Ada being cost effective--you need to look at the bigger picture.
We don't just _develop_ weapon systems.  We deploy, use, and _maintain_ them.
One of the bigger (and cost effective) advantages of Ada is it ease of 
maintainability.  Instead of giving some contractor one hundred thousand
lines of spegetti code in C, we give them Ada.  Now, I don't tremendous persona
l
experiance saying Ada is better to maintain, but everything I've dealt with
does strongly suggest this is the case.  Just for the record, I'm fairly
certain the maintenance costs of our weapon systems far exceed the development
costs.  This _is_ something to think about.

Using the GPS receiver analogy is somewhat inaccurate (IMHO).  It's paramount
to saying that smoking isn't bad for your health because you have a ninety
year old grandfather who still smokes (while the other ninety percent of
all smokers have already died of smoking related illnesses).  We build our
weapon systems to _survive_ a war time environment.  If the commercial GPS
receivers worked, great, but that performance doesn't guarantee they'll work
under all specified conditions.  

During the Gulf War, we had a four star general come and explain how everyone 
laughed at the Air Force's requirement for a FAX machine which worked in 
seemingly rediculous temperature extremes.  He then explained how those very 
same FAX machines were presently working in the desert under those extreme 
temperature conditions...and working well while other FAX machines (commercial)
had crapped out.

Ada software development is just the beginning of a weapon system's life
cycle.  Ada _may_ be more expensive to program in now, but I suspect it will
get less expensive as more and more companies begin to use it.  It's the
long-term life cycle maintenance where Ada will really pay off.  We're still
maintaining systems built with FORTRAN and assembly code almost twenty years
ago.

---Dan---

-- 
+ Captain Daniel F. Van Der Werken, Jr., USAF |  I do not speak for the Air
+ Rome Laboratory/OCDS                        |  Force, otherwise I'll be
+ Griffiss AFB, NY 13441                      |  in Kansas making big rocks
+ (315) 330-4441/DSN 587-4441                 |  into little rocks!

Re: Open comment to Ted Holden

[news]

In article <9204081355.AA13680@ajpo.sei.cmu.edu>, SAHARBAUGH@ROO.FIT.EDU writes
:
> Ted,
>   You do not seem to grasp the difference between the mission of
> the US Army and the mission of commercial software vendors.
> The US Army must defend our country and keep you and I and
> our decendants safe.  The commercial software vendors must
> make a profit for their stockholders.
>   You do not seem to grasp the difference in performance
> requirements ofr military software vs commercial software.
> Military software must work or we may lose the war. 

Several points:  The commercial software venders are now adhering
to standards, the most serious from the perspective of languages 
being C/C++.  The argument you give would pertain in a situation
in which Borland, MicroSoft, Ashton-Tate et. al. were each hawking
their very own language.  The reality is quite different.  The choice
is between the standard North American programming language (C/C++)
which everybody uses and which is well understood by most serious
programmers, and the flakey piece of garbage known as Ada.

The problems mentioned in that large post of mine are real enough.  Some
very bright people have been wasting their lives spending 12 hours working
around Ada and one hour solving their own problem (to the extent
possible WITH Ada)..

Virtually all really vital and serious military work is still being
done in C and other languages with waivers.  There's a real reason
for that.

Ted Holden



-- 
HTE
bear

Re: Open comment to Ted Holden

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!news.bbn.com!kirin!m]

vanderwerkend@lonexc.rl.af.mil (Dan Vanderwerken) writes:

>In article <SRCTRAN.92Apr9102404@world.std.com> srctran@world.std.com (Gregory
 Aharonian) writes:
>>Sam,
>[stuff about Ada not being cost effective deleted....]

>One of the bigger (and cost effective) advantages of Ada is it ease of 
>maintainability.  Instead of giving some contractor one hundred thousand
>lines of spegetti code in C, we give them Ada.  Now, I don't tremendous person
al

Funny, I've seen lots of spaghetti code writting in almost every language,
including Ada.  Good program design and implementation are much more an 
attribute of the programmer than the implementation language.

>experiance saying Ada is better to maintain, but everything I've dealt with
>does strongly suggest this is the case.  Just for the record, I'm fairly
>certain the maintenance costs of our weapon systems far exceed the development
>costs.  This _is_ something to think about.

Absolutely; the bulk of the cost, expecially in military systems is in
maintenance, especially since the military never seems to throw anything away.
In fact, I remember rumors of the USAF negotiating a contract for 20 years of
maintenance on a Honeywell DPS-8 running GCOS, when GCOS was already 10 years
obsolete.

Still, I'd be willing to bet that a well-designed and written software system
in any language will be easier to maintain than a poorly designed and written
system in Ada.

While standardization may be desirable sometimes, we also have to remember that
computer langauges are TOOLS for expressing ideas in the form of programs.
Computer languages aren't usually created for the intellectual joy of creation
but rather to solve particular kinds of problems;  Thus some languages 
will be more effective at solving particular problems than others.  If you
doubt this, compare the difficulty of writing a heuristic search program in
LISP and {Ada, C, C++} etc., or an OS kernel in C versus {Ada, COBOL, etc.}.

It seems to me that the least-cost solution to solving a problem is to carefull
y
engineer the design, choose the right tools (language, development environment,
execution environment) for the job, and properly execute the design.
The only major drawback that I see is that maintenance programmers might be
forced to learn more than one computer language; something which a lot of peopl
e
seem to be inordinately afraid of.

Mark Fausett
mfausett@bbn.com

Re: Open comment to Ted Holden

[Ha rry Koehnemann]

In article <mfausett.703186106@kirin> mfausett@bbn.com (Mark Fausett) writes:
>
>Funny, I've seen lots of spaghetti code writting in almost every language,
>including Ada.  Good program design and implementation are much more an 
>attribute of the programmer than the implementation language.

It's also an attribute of managerial pressures and marketing idiots.
This, perhaps as much as anything, leads to poor quality code.  Many of
the short cuts you can take in other languages don't exist in Ada
(privates, packaging, and particularly the typing mechanism) so that
such pressures don't propogate themselves into the code as easily as
they can with C and other languages.
--
Harry Koehnemann
koehnema@enuxha.eas.asu.edu

Re: Open comment to Ted Holden

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!nic!jonesm]

And for my 2 cents.

I think that comparing carrying commercial GPS equipment into the desert
to mil equipment is really not fair. First as someone already pointed out
the war only lasted a few days and second GPS is a really simple device
and is of a really small form factor. I hardly think this is a good test
for camparing commercial to mil equipment. 

Defense contractors take a lot of criticism for producing expensive 
bug riddled products. Many people ask why doesn't mil equipment 
work as well as commercial stuff. I think that people should consider
that Microsoft for example had 50,000 people beta test Windows 3.1
and the people are still having problems with it. Does
the defense department have 50,000 people to test their equipment?
For free? Does the Dod have a Dr. Dobbs Journal or many of the 
equivalents to help them work over technical issues. 
That is paid for by the user community?
If a Word processor has a FATAL bug it in that probably means that
it might destroy some data on your hard disk. A FATAL error in 
a mil system may mean that many people will die. Are these two really
comparable?

To me that largest problem with Ada is that it doesn't have a large
customer base. So the Ada Compiler/development systems are not checked
out as well as its commerial counterparts. How many beta test sites
are there for the average C compiler? How many for Ada? And keep in mind
that Ada is a lot more complicated than C. Borland has sold hundreds
of thousands of their C (and C++) compilers, how many has Meredian
or Alsys sold for the PC?

End of 2 cents.

Matthew Jones
jonesm@cerf.net

Re: Open comment to Ted Holden

[micro-heart-of-gold.mit.edu!wupost!uwm.edu!ogicse!henson!hearne]

jonesm@nic.cerf.net (Matthew Jones) writes:

>And for my 2 cents.

>I think that comparing carrying commercial GPS equipment into the desert

                  . . .

>To me that largest problem with Ada is that it doesn't have a large
>customer base. So the Ada Compiler/development systems are not checked
>out as well as its commerial counterparts. How many beta test sites
       
                  . . .

>Matthew Jones
>jonesm@cerf.net

There is an obvious implicate to this view: the DOD should simply
buy Ada compilers for universities to increase the volume of tests
the compilers are subjected to.   This would be much cheaper than
paying defense industry rates for the same thing and would serve
a useful educational purpose also.


				James Hearne
				Computer Science Department
				Western Washington University
				Bellingham, WA  98225

Re: Open comment to Ted Holden

[news.u.washington.edu!milton.u.washington.edu!mfeldman]

In article <1745@nic.cerf.net> jonesm@nic.cerf.net (Matthew Jones) writes:
>And for my 2 cents.

  [ 1.5 cents deleted ]
>
>To me that largest problem with Ada is that it doesn't have a large
>customer base. So the Ada Compiler/development systems are not checked
>out as well as its commerial counterparts. How many beta test sites
>are there for the average C compiler? How many for Ada? And keep in mind
>that Ada is a lot more complicated than C. Borland has sold hundreds
>of thousands of their C (and C++) compilers, how many has Meredian
>or Alsys sold for the PC?
>
Now my $0.02. Meridian and Alsys (and RR Software) have sold - at least -
several thousand copies apiece of their systems. It's not up to Borland's
quantities, or Microsoft's, but it's not trivial either.

Meridian, Alsys, and RR are, in my opinion, guilty of a terribly myopic
view of Ada, shared by much of the Ada industry. Ada does not have a large
customer base because - several years ago when there was plenty of DoD
and venture money flowing, the Ada companies failed to hire marketing
forces who would break their backs enlarging that customer base. Now,
when money is tight, they complain - perhaps with justification -
that they can't afford to do so. 

IMHO, none of the Ada companies seem to have done a close study of
the successful mass-market software houses, and tried to emulate them.
Ada is a VERY GOOD language, and could be quite a worthy competitor to
the others, but its proponents must be willing to admit that Ada has
mass-market potential. Meridian persists in selling against Alsys, which
persists in selling against TeleSoft, etc. No company has had the
vision to sell - HARD - against the other languages.

The engineers in these companies believe they have a better mousetrap
(at least I think they do), but the world can't beat a path to their
door because they don't know the door is there.

One small example: I meet a lot of college kids who grew up in the Seattle
area. The biggest employer in Seattle is Boeing (~100,000 jobs here). My
guess is that Boeing has as many software people as Microsoft (which has,
I think, about 6000 employees). Yet these students ALL know that Microsoft
is heavy into C, and very few - if any - know that Boeing is heavy into
Ada. Their jaws drop when I tell them.

Why are Borland and Microsoft compilers sold in every software store in
town, but nobody's heard of Meridian? The Ada companies will either learn
that they have to spend money to make money, hire some decent marketeers,
take some risks, and go for it, or they will simply shrivel up and die.
Ada is a much better invention than its own proponents allow it to be.

Spare me the flames about how expensive validation is. I know that, and
know that all the validation in the world will not sell a product its
own manufacturers refuse to market aggressively.

Mike Feldman

Re: Open comment to Ted Holden

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!nstar!towers!grafted]

news@fedfil.UUCP (news) writes:
> Several points:  The commercial software venders are now adhering
> to standards, the most serious from the perspective of languages 
> being C/C++.  The argument you give would pertain in a situation
> in which Borland, MicroSoft, Ashton-Tate et. al. were each hawking
> their very own language.  The reality is quite different.  The choice
> is between the standard North American programming language (C/C++)
> which everybody uses and which is well understood by most serious
> programmers, and the flakey piece of garbage known as Ada.
> 
> The problems mentioned in that large post of mine are real enough.  Some
> very bright people have been wasting their lives spending 12 hours working
> around Ada and one hour solving their own problem (to the extent
> possible WITH Ada)..
> 
> Virtually all really vital and serious military work is still being
> done in C and other languages with waivers.  There's a real reason
> for that.
> 
> Ted Holden
> -- 
> HTE
> bear

   I hate to burst your bubble Ted, but "everbody" doesn't
use C/C++.
    Most business systems (counting systems or packages, not
installations) are written in COBOL.  There is still more
lines of COBOL "in production" than any other language in
the business environment.
    Most scientific stuff is still in Fortran.  I did a survey
in comp.sys.super and by FAR the largest amount of production
code and by FAR the largest amount of development is in
Fortran when dealing with supercomputers.  I talked to people
involved in NCSA and they say Fortran is by far and away the
language of choice on supers.
 
Also, there is no "Standard C".   Ansi C and K&R C are *NOT*
"standards" that are adhered to.  Talk to the people at
Aldus corporation, the people who wrote PageMaker.  They
have PageMaker on the Mac and PageMaker on the PC.  Only 
about 80% of the code is identical between the two systems.
 
Graphic handling and system calls are still too different.
 
I went over this "C is not C all around the world" with a friend
of mine when we discussed writing a business program in C.
 
I wanted a C program that was portable to mini-computers and
workstations.  He wanted to write it in Borland C with
Borland's user interface package.   I can think of 3 
completely different versions of the package:
  1) character based version for minicomputer users running
      dumb terminals
  2) X-windows based version for workstations
  3) PC-based version with Brand-X user interace package.

--
Dave Appel
The Grafted Branch BBS
317-881-4369
internet: dappel@grafted.UUCP
uucp: ..!uunet!grafted.UUCP!dappel
 = = Grafted Branch BBS (317) 889-6997 2 Gig on-line = =

Re: Open comment to Ted Holden

[snorkelwacker.mit.edu!spool.mu.edu!olivea!news.bbn.com!kirin!mfausett]

dappel@grafted.UUCP (Dave Appel) writes:

>Also, there is no "Standard C".   Ansi C and K&R C are *NOT*
>"standards" that are adhered to.  Talk to the people at
>Aldus corporation, the people who wrote PageMaker.  They
>have PageMaker on the Mac and PageMaker on the PC.  Only 
>about 80% of the code is identical between the two systems.
> 
>Graphic handling and system calls are still too different.
> 
So,
How does Ada solve this problem;  should the language become the OS?
Wouldn't an Ada version of PageMaker differ between platforms as well?


Mark Fausett
mfausett@bbn.com
 

Re: Open comment to Ted Holden

[sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!nstar!towers!grafted!dappe]

mfausett@bbn.com (Mark Fausett) writes:

> dappel@grafted.UUCP (Dave Appel) writes:
> 
> >Also, there is no "Standard C".   Ansi C and K&R C are *NOT*
> >"standards" that are adhered to.  Talk to the people at
> >Aldus corporation, the people who wrote PageMaker.  They
> >have PageMaker on the Mac and PageMaker on the PC.  Only 
> >about 80% of the code is identical between the two systems.
> > 
> >Graphic handling and system calls are still too different.
> > 
> So,
> How does Ada solve this problem;  should the language become the OS?
> Wouldn't an Ada version of PageMaker differ between platforms as well?
> Mark Fausett
> mfausett@bbn.com

My point was not that ADA solved those problems, but was to 
counter Mr. Holden's point that C/C++ is some kind of "universal"
or "North American" standard.  C/C++ is not a panacea. 
   Maybe someday X-windows will become a universal standard.
But now, in the personal computer world (note lower case letters)
there exists several GUI's: MS-Windows, OS/2's Presentation
Manager, Mac's GUI, X-windows ala Motif, X-windows ala Open
Look.   And coming down the pike are: IBM's "Pink" operating
(the one being developed by the joint IBM/Apple thing for
the Power Platform nee' RS/6000 ) MS-Windows-32, and 
MS-Windows-NT.


--
Dave Appel
The Grafted Branch BBS
317-881-4369
internet: dappel@grafted.UUCP
uucp: ..!uunet!grafted.UUCP!dappel
 = = Grafted Branch BBS (317) 889-6997 2 Gig on-line = =

Re: Open comment to Ted Holden

[news]

In article <TD79iB1w161w@grafted.UUCP>, dappel@grafted.UUCP (Dave Appel) writes
:
> news@fedfil.UUCP (news) writes:


 
>    I hate to burst your bubble Ted, but "everbody" doesn't
> use C/C++.
>     Most business systems (counting systems or packages, not
> installations) are written in COBOL.  There is still more
> lines of COBOL "in production" than any other language in
> the business environment.

>     Most scientific stuff is still in Fortran.  I did a survey
> in comp.sys.super and by FAR the largest amount of production
> code and by FAR the largest amount of development is in
> Fortran when dealing with supercomputers.  I talked to people
> involved in NCSA and they say Fortran is by far and away the
> language of choice on supers.

I can't honestly recommend C++ or C for anything like a majority of coding
which goes on in DOD.  I would recommend it for anything which remotely
resembles the sort of applications which C, Pascal, Ada, or anything LIKE
that is used for.  Borland's PAL might be a good evolving choice for a lot
of other kinds of applications.

Cobol is anti-structurable.  The fact that it is used at all is a tribute 
to intertia and to nothing else.

The fact that Fortran is used at all is likewise disgraceful.  C++ with it's
facilities for extension and function overloading can match all of the 
functionality not only of Fortran, but of APL as well, with none of the
slowness whenever IO beyond the trivial is required, and with far greater
connectivity to anything resembling modern computer science.


> Also, there is no "Standard C".   Ansi C and K&R C are *NOT*
> "standards" that are adhered to.  Talk to the people at
> Aldus corporation, the people who wrote PageMaker.  They
> have PageMaker on the Mac and PageMaker on the PC.  Only 
> about 80% of the code is identical between the two systems.

Nonetheless, from everything I've ever read or heard, the best luck anybody
has had making applications portable for the last 15 years has been simply
writing them in C, DESPITE the fact that C was not even a standard in name
much of that time.

Fortran and Cobol are standards, and I can tell you horror stories all day and
all night about portability in them.  Take FORTRAN...  The 77 spec was a
subset of functionality which which everybody in the room agreed to before
the cigar smoke killed them all.  Each separate vendor kept his own items
which didn't make the list which, by the way, was minimal;  you got two guys
who couldn't do something and it didn't make the standard, but everybody else
kept on doing it anyhow.  Namelist reads for instance.  Aside from that sort
of thing, practices common to earlier varients, such as storing text in
integer arrays didn't make the spec either, and guess what happened when
people started writing FORTRAN compilers for minis and micros?  That's 
right!  Those yuppies just bought a copy of the 77 standard and wrote a
compiler for it;  none of the stuff every bit of existing code on the planet
used would work.

> Graphic handling and system calls are still too different.

They've GOT to be.  Different systems handle graphics differently.  The
only other possibility is to write an operating system for/by/with Ada
and figure to have that OS on every machine you ever use, but, if you
recollect, as one of the problem-report authors from that Ada-Woe BBS
noted, you can't write an OS in Ada.

Let me tell you about portability in Ada.  There are so many things you
can't do in Ada, that any real-world application which is forced to use
Ada to any extent ends up being a mixed-language application, and there's
NOTHING less portable than that.  That's guaranteed non-portable.  I ended
up writing all of the low-level file-handling routines for a typical large
database application like that once, in C of course, and those routines
had to be callable from Ada, Cobol, and Informix SQL with the same
conventions.  This was for one of the larger applications which runs on
a CTASC-II (Unisys 5000, soon to be Sequent) mobile unit.


> I went over this "C is not C all around the world" with a friend
> of mine when we discussed writing a business program in C.
  
> I wanted a C program that was portable to mini-computers and
> workstations.  He wanted to write it in Borland C with
> Borland's user interface package.   I can think of 3 
> completely different versions of the package:
>   1) character based version for minicomputer users running
>       dumb terminals
>   2) X-windows based version for workstations
>   3) PC-based version with Brand-X user interace package.

For total compatibility amongst UNIX systems and on DOS and/or anything
remotely close to normal, you needed to either use the curses library or 
some totally generic character-based interface like JAM.  That's how
it's done in the real world.



> The Grafted Branch BBS
> Dave Appel
> 317-881-4369
> internet: dappel@grafted.UUCP
> uucp: ..!uunet!grafted.UUCP!dappel
>  = = Grafted Branch BBS (317) 889-6997 2 Gig on-line = =

Ted Holden 

-- 
HTE
bear

Re: Open comment to Ted Holden

[munck]

In V92 #69, SAHARBAUGH@ROO.FIT.EDU writes:
>  No matter what Army software costs it is cheaper than the
>alternative.  Imagine an enemy with Apache helicopter
>equivalents in your home town for an hour.

According to last night's 60 Minutes report, they'd be sitting on
the ground duct-taping their rotors back together, hammering on
their jammed guns, and trying to talk to each other over useless
radios.  Meanwhile, since I live in the South, a counter-attack
of armed pick-up trucks would be coordinated by CB radio and
would kick their butts.

Bob

Re: Open comment to Ted Holden

[Johan Margono]

In article <1745@nic.cerf.net> jonesm@nic.cerf.net (Matthew Jones) writes:
>And for my 2 cents.
>
>[deleted stuff ...]
>
>Defense contractors take a lot of criticism for producing expensive 
>bug riddled products. Many people ask why doesn't mil equipment 
>work as well as commercial stuff. I think that people should consider
>that Microsoft for example had 50,000 people beta test Windows 3.1
>and the people are still having problems with it. Does
>the defense department have 50,000 people to test their equipment?
>For free? Does the Dod have a Dr. Dobbs Journal or many of the 
>equivalents to help them work over technical issues. 
>That is paid for by the user community?
>If a Word processor has a FATAL bug it in that probably means that
>it might destroy some data on your hard disk. A FATAL error in 
>a mil system may mean that many people will die. Are these two really
>comparable?
>
>To me that largest problem with Ada is that it doesn't have a large
>customer base. So the Ada Compiler/development systems are not checked
>out as well as its commerial counterparts. How many beta test sites
>are there for the average C compiler? How many for Ada? And keep in mind
>that Ada is a lot more complicated than C. Borland has sold hundreds
>of thousands of their C (and C++) compilers, how many has Meredian
>or Alsys sold for the PC?
>
>End of 2 cents.
>
>Matthew Jones
>jonesm@cerf.net

This argument reminds me of the following software development guidelines
which seem so pervasive in our industry:

  1. Order T-shirts for the development team
  2. Announce availability
  3. Write the code
  4. Write the manual
  5. Hire a Product Manager
  6. Spec the s/w (writing the specs after the code helps to
     ensure that your s/w meets the specs)
  7. Ship
  8. Test (the customers are a BIG help here)
  9. Identify bugs as potential enhancements
 10. Announce the upgrade program

-------------------------------------------------------------------------------
-
 Johan Margono
 Computer Sciences Corporation
 email: jmargono@starlab.csc.com
-------------------------------------------------------------------------------
-

Re: Open comment to Ted Holden

[Charles H. Sampson]

In article <2733@fedfil.UUCP> Ted Holden writes:

>Let me tell you about portability in Ada.  There are so many things you
>can't do in Ada, that any real-world application which is forced to use
>Ada to any extent ends up being a mixed-language application, and there's
>NOTHING less portable than that.  ...

     Whoops, there we go again.  Since Mr. Holden hadn't enlightened me
on this point my team and I have implemented a "pure" Ada application that
is 99.99% portable, running on VAXes (DEC Ada), IBM PCs (Alsys Ada) and
the Navy's UYK-43 (Ada/L).  I quibble about calling it pure Ada because
it has to call some non-standard packages.  The 0.01% of non-portability
comes from inherent operating system differences which we chose to honor
rather than ignore: The way you pick up command line parameters in VAXes
and PCs and the fact that there are none for the UYK-43.  We could have
handled all parameter input using Text_IO with prompts, of course, but
we chose to make the VAX version look like a VAX program, the PC version
look like a PC program, and the UYK-43 version look like a poor man's
Macintosh.   The impurities arose for the same reason.

     Just think, if I had known this was impossible, we might have been
forced to use a real software engineering language like C!

				Charlie

Re: Open comment to Ted Holden

[Mark Fausett]

news@fedfil.UUCP (news) writes:

>In article <TD79iB1w161w@grafted.UUCP>, dappel@grafted.UUCP (Dave Appel) write
s:

>I can't honestly recommend C++ or C for anything like a majority of coding
>which goes on in DOD.  I would recommend it for anything which remotely

Hmmm.  What characterizes the majority of coding which goes on in the DOD.
I'd been involved in software development for the DOD for quite a few years, bu
t 
always having been in R&D, I suspect my uses were anything BUT typical;
in particular the amount of exploratory programming which goes on in a typical 
AI
R&D project.

Mark Fausett
mfausett@bbn.com