From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: Wed, 8 Sep 93 13:25:07 -0700 From: mshapiro@manta.nosc.mil (Michael D Shapiro) Subject: Re: 30 Years Message-ID: <9309082025.AA03031@manta.nosc.mil> List-Id: In 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)]