comp.lang.ada
 help / color / mirror / Atom feed
From: mshapiro@manta.nosc.mil (Michael D Shapiro)
Subject: Re: 30 Years
Date: Wed, 8 Sep 93 13:25:07 -0700	[thread overview]
Message-ID: <9309082025.AA03031@manta.nosc.mil> (raw)

In <CCDG8D.Js5@cbnewsl.cb.att.com> willett@ucbvax.Berkeley.EDU
     (david.c.willett) writes, regarding some earlier comments:

> From article <9308251529.AA07664@manta.nosc.mil>, by mshapiro@MANTA.NOSC.MIL 
(Michael D Shapiro):
 	{Much deletion}
> > Probably what we should really hope that someone is looking for the
> > successor to Ada and C++ and {insert your other favorite language here}
> > that takes the most appropriate properties of each and combines them
> > into a new tailorable language.  As I see it, this language should have
> > multiple formality levels.  High formality would be required for huge
> > systems.  Informality would be allowed for throwaway programs.
> > In-between systems would need to conform to some intermediate formality
> > levels.
> 
> Why do you think we need a "one-language-fits-all" solution?  In a previous
> long-term (>30 year) project, we used two languages:
> 
> 	HP's Rocky Mountain Basic for rapid prototyping
> 
> 	Fortran for production code
> 
> Flame all you wish, but we were a collection of legacy systems that were
> "protected" from the mandate.  I thought that environment worked very
> well, largely because Rocky Mountain Basic (circa 1975) was a "Fortranized" 
> dialect of Basic.  This made conversion into production code much easier.
> 
> We had the best of both worlds.  We could "run a solution up the flagpole"
> with a quickie Basic prototype, and if "someone saluted" we could efficiently
> recode the algorithm into Fortran.  If it turned out that the program was 
> not that useful, we could trash the prototype or reuse pieces to solve 
> other problems.
> 
> I found that I did just a bit more than half of my coding in Basic because
> we wrote more throwaway stuff than production stuff.

No flames at all from me.  Over my desk I have a list of 23 programming
languages I've used in various projects over the years.  And I've
probably left some out.  Most people like to use the tools with which
they're familiar.  I started a couple of products with Dan Bricklin's
Demo system.  Some people call it a programming language; others call
it "an expert system for building vaporware."  The nice thing with
building prototypes with it was that it didn't actually produce code
that worked outside the demo environment.  Then someone had to come
along and provide a tool that translated its files to C code.  Oh well.

The point of discussing the possibility of a single programming
language is that one idea of Ada was to provide precisely one
programming language for the DoD community.  To some, Ada should be
used for everything, whether or not it's appropriate.  To others, Ada
should never be used, because it's not appropriate for some
applications.  Still others take a position between those extremes.

Long ago, when I was a graduate student studying compiler construction,
I recall a professor remarked that while people kept looking for UNCOL,
the UNiversal COmputing Language, nobody had succeeded in finding it
yet.  And likely wouldn't.  A few years earlier that professor, Maurice
H. Halstead, had written a book entitled "Machine-Independent Computer
Programming" (Spartan Books, 1962).  He described work done by the Navy
at the Naval Electronics Laboratory (NEL) in San Diego (now NCCOSC
RDT&E Div.) on developing a portable language named NELIAC, based on
Algol '58.  A parallel effort produced JOVIAL for the Air Force.  While
both those languages had some successes, neither became the UNCOL.
Later, some had hopes that Ada could become the UNCOL for the DoD
community, despite its shortcomings in many application areas.  [Yes, a
few years later he developed the software science theories, basis of
the Halstead Numbers of software estimation.]

In summary, my point is that IF we need a single computing language for
the future, it will not be Ada, C++, nor any other existing language.
We will need a language with the best properties of each, tailorable
for each task domain.

      Michael

========================================================================
Michael D. Shapiro, Ph.D.                      e-mail: mshapiro@nosc.mil
NCCOSC RDT&E Division (NRaD) Code 411            San Diego CA 92152-7560
Voice: (619) 553-4080         FAX: (619) 553-4808          DSN: 553-4080
   [Until January 1992 we were the Naval Ocean Systems Center (NOSC)]


             reply	other threads:[~1993-09-08 20:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-09-08 20:25 Michael D Shapiro [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-09-16 11:43 30 Years Richard A. O'Keefe
1993-09-13 16:27 agate!howland.reston.ans.net!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co
1993-09-10 22:07 Tucker Taft
1993-09-10 20:25 Robert I. Eachus
1993-09-10 17:57 Robert Kitzberger
1993-09-10 17:03 Mark C. Carroll
1993-09-10 15:49 cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!progers
1993-09-08 19:38 Tucker Taft
1993-09-08 17:21 Michael D Shapiro
1993-08-30 16:00 agate!howland.reston.ans.net!darwin.sura.net!source.asset.com!shilling
1993-08-30  3:06 cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!seas.gwu.edu!mfeld
1993-08-27 15:04 Tucker Taft
1993-08-26 16:09 agate!doc.ic.ac.uk!uknet!rsre!trout.rsre.mod.uk!trout!rigotti
1993-08-26 14:57 cis.ohio-state.edu!pacific.mps.ohio-state.edu!math.ohio-state.edu!uwm.edu
1993-08-26 11:06 cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd
1993-08-25 15:29 Michael D Shapiro
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox