Re: Scripting vs. Programming language vs. 4GL?

prener@watson.ibm.com (Dan Prener)
Mon, 23 Aug 1993 04:59:03 GMT

          From comp.compilers

Related articles
Scripting vs. Programming language vs. 4GL? tellab5!odgate!dbk@uunet.UU.NET (1993-08-20)
Re: Scripting vs. Programming language vs. 4GL? prener@watson.ibm.com (1993-08-23)
Re: Scripting vs. Programming language vs. 4GL? prechelt@ira.uka.de (1993-08-23)
Re: Scripting vs. Programming language vs. 4GL? damurphy@wc.novell.com (Duane Murphy) (1993-08-25)
Re: Scripting vs. Programming language vs. 4GL? lwall@netlabs.com (1993-08-29)
Re: Scripting vs. Programming language vs. 4GL? TDARCOS@MCIMAIL.COM (Paul Robinson) (1993-08-29)
Re: Scripting vs. Programming language vs. 4GL? julian@feenix.metronet.com (Phillip Julian Eby) (1993-08-31)
Re: Scripting vs. Programming language vs. 4GL? ch+@cs.cmu.edu (1993-08-30)
[7 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: prener@watson.ibm.com (Dan Prener)
Keywords: interpreter
Organization: IBM T.J. Watson Research Center, Hawthorne, New York
References: 93-08-096
Date: Mon, 23 Aug 1993 04:59:03 GMT

  tellab5!odgate!dbk@uunet.UU.NET (Dan Keith) writes:


> I'm embroiled in a debate with my colleagues over the difference between
> the term "programming language" and the term "scripting language". I think
> that a scripting language is a very limited, high-level language that is
> application-specific and intended to be for simple repetition and
> sequencing of the application's commands (i.e., a macro language is a
> scripting language). On the other hand, a programming language usually
> contains all of the requisite components that allow a sophisticated,
> Turing-equivalent, program to be built; components such as definable
> functions, variables, arrays, and the like.


    [ ... ]


>From looking at the resulting languages, rather than from any information
about other people's design processes, I conclude the following.


The typical scripting language that is not explicitly designed to be
a general-purpose programming language is motivated by considerations
such as


      (1) We know exactly what users will want to do, so we'll incorporate
                clear, simple, intuitive access to all these things.


      (2) But, somewhere there is someone who will want to do something
                a little bit different, so we'll build in an escape mechanism,
                off in some corner of the language.


When people don't realize that they are designing a general-purpose
language, what happens is not so much that they end up with only
a special-purpose language, but rather that they end up with a bad
general-purpose language.


Turing completeness, though extremely important, is not the primary
stumbling block. Usability is.
--
                                                                      Dan Prener (prener@watson.ibm.com)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.