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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,93bb6e0ed74c3155 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: general-purpose vs domain-specific programming languages Date: 1998/01/10 Message-ID: <01bd1df4$7b020e80$86f282c1@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 314708273 Content-Transfer-Encoding: 7bit References: <98010813283131@psavax.pwfl.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: UUNet UK server (post doesn't reflect views of UUNet UK) Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-01-10T00:00:00+00:00 List-Id: I've often found there is much mileage in developing very simple interpreters, which are written in Ada, but which provide a separate environment and language for doing a very specific job. The 'environment' is typically line-oriented interaction (about as simple as it can get); sometimes 'batch' file capability needs to be added (also very simple: just read a named text file instead of current input). As long as the syntax is kept very simple (cf. the 'ed' of UNIX), the interpreter is easy to maintain, yet provides the thing it most needs to: convenience. It is likely to be less convenient to have to write and compile an Ada program to do something that would be a one-liner for such an interpreter. The biggest drawback tends to be psychological: persuading people to learn the new syntax. Programmers seem to have a pathological neophobia when it comes to this sort of thing! -- Nick Roberts Croydon, UK Proprietor, ThoughtWing Software; Independent Software Development Consultant * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 * *** Eats three shredded spams every morning for breakfast ***