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=-1.3 required=5.0 tests=BAYES_00,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: Brian Rogoff Subject: Re: scripting/extension language for Ada (was : Re: tagged types extensions) Date: 2000/02/05 Message-ID: #1/1 X-Deja-AN: 582161855 References: <389207CC.C16D80E8@averstar.com> <38971028.BB16D8A2@earthlink.net> <3899F757.FAE131B3@free.fr> <87gvdl$qsp$1@nnrp1.deja.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 949814217 205 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-02-05T00:00:00+00:00 List-Id: On Sat, 5 Feb 2000 blaak@infomatch.com wrote: > Robert A Duff wrote: > > Ray Blaak writes: > > > 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. > > > > I've seen way too much long-lived software written in Perl, > > csh, awk, make, etc. Me too. > There is always room for a better language. Is Ada right for a > scripting language, though? IMO, no. That's why I suggested embedding a language in Ada, with that languages implementation being startlingly clear Ada code. > > Anyway, "quickly written" is irrelevant. The only time it can > > possibly make sense to use languages that are difficult to > > maintain is when you're going to quickly throw away the code > > after writing it. I've never observed the phenomena described, IME code is never quickly thrown away. > Nobody (at least not me) is advocating the use of scripting > languages that are difficult to maintain. > > The usefulness of a good scripting language is that it is well > designed for invoking OS services (expressing the piping of a > chain of processes, for example), interactive and easy to debug, > and tends to have small programs. E.g. a few K at most for a > reasonably complex script -- that's it! No build steps, object > files, link times. Just run it. All languages are pushed outside their original design limitations, so a scripting language had better be capable of growing beyond "a few KLOC". > One tends to use scripting languages to implement small little > tasks (munge a few files, spit out some email, walk a few > websites,...) > > Scripting languages should encourage programs that are easy to > write, easy to understand, and easy to change. > > Most scripting languages are atrocious (esp. sh and > friends). They don't have to be. > > What I like about scsh is that one has a real programming > language (Scheme) focused on tasks such that the limitations of > Scheme don't apply (i.e. the lack of a module or package system > for programming "in the large"). Scsh uses Scheme48, which has a fascinating and powerful module system IMO. > Now Ada is a fine language, and my language of choice for real > software systems. The problem with Ada for scripting purposes, > however, is that there is too much declarative infrastructure > needed to do simple tasks. OK so far... > Ada's strong static typing requires ones abstractions to be carefully > specified. Wrong. *Explicit* static typing, *explicit* instantiation, and a heavyweight (some say more readable :-) syntax are what make Ada painful as a scripting language. See ML, Haskell, or the DrScheme environment for counterexamples. > Dynamic typing in a scripting language, on the other hand, allows one > to just "whip off" a solution, and yet still have strong type checking > for good runtime error detection. There are good arguments for dynamic typing, but this isn't one of them. > Consider this scsh snippet: > > ;; Mail myself files matching some criteria > (with-cwd "~/myfiles" > (for-each (lambda (file) > (if (run (grep "some pattern" ,file)) > (run (mail -s "found it" blaak@home) (< ,file)))) > (directory-files))) ML or Haskell would require a few more lines to make the types right, like checking that the result of your grep isn' a null string. -- Brian