From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fa2cc518ef3b992c X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: scripting/extension language for Ada (was : Re: tagged types extensions) Date: 2000/02/04 Message-ID: <389B8544.3AB9401A@Raytheon.com>#1/1 X-Deja-AN: 581769022 Content-Transfer-Encoding: 7bit References: <389207CC.C16D80E8@averstar.com> <38971028.BB16D8A2@earthlink.net> <3899F757.FAE131B3@free.fr> <389B5C01.D484CF2@raytheon.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Aerospace Engineering Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-02-04T00:00:00+00:00 List-Id: "Stanley R. Allen" wrote: > > Ray Blaak wrote: > > > > I think that Ada as a scripting language is not a good idea. > > > > The philosophy of Ada caters to careful design and implementation, strong > > typing, etc. Ada is a language useful for making well crafted software. > > > > Scripting languages, on the other hand, tend to be used for small, quickly > > written programs, and good ones tend to have a succinct powerful notation. > > This is bad reasoning, probably based on poor observation. Scripts > are becoming a much bigger part of the software development scene, and > it's a shame that the script languages in use now are based so heavily > on the hacker mentality. In our project, scripts have gotten very large > and are used for many critical capabilities. Some are thousands of lines > long. We maintain these scripts in our CM database just like the Ada, C, > and FORTRAN code. They have long life -- over 5 years. They must be > documented because they are updated by many hands over a long period of > time. Sound familiar? > > The philosophy of Ada, if not all its details, needs to migrate to > the world of script languages, because scripts ARE software -- the same > rules and pitfalls apply. > > I question your criterion for a "good" script language -- "succinct powerful > notation". Isn't this what we've come to learn as a receipe for > incomprehensibility? My feelings exactly. I remember working on the good old Rational R1000 in the Air Force and for Link then Hughes now Raytheon. The entire operating system interface was in Ada with the speed of execution of an interpreter. I was impressed how the total immersion into Ada for the most basic user needs rapidly increased new programmer capabilties in the language. I suppose that is supported by the notion that one learns French much faster by living in France as compared to taking college courses. I have toyed with Ada/Ed as an script interpreter but its requirements to pre-analyze the code does not make it a viable candidate for shell-script replacements. Its just not fast enough. It occurs to me that an Ada interpreter can dispense with many of the compile-time checks, relying instead upon a real compiler to "verify" the script source is correct Ada. This alone would enable an interpreter to simply expand generics like macros and not bother with all the checks concerning the instantiation. If I recall correctly, the old Ada-Sage (now Sage-ST) did include a very limited Ada interpreter. This allowed one to quickly prototype the database interface with simple controlling code with very rapid turn-around. Just the sort of thing one needs with hashing out the user interface on-line with the customer. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!"