Subject: Re: Is there a useful distinction between "programming" and "scripting" languages?
From: Erik Naggum <erik@naggum.no>
Date: 19 Sep 2002 04:16:53 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3241397813684563@naggum.no>

* Erann Gat
| That makes a language's status dependent on the context in which it is used.
| Lisp running on Unix would be a scripting language on that definition (but
| not Lisp running on a Lisp machine).

  This just goes to show how differently we conceptualize.  I do not see a
  runtime system as an application in itself.  If, however, the application
  merely runs inside the Lisp system which is also an application from the
  operating system's point of view, the question becomes whether the Lisp
  application does the same as the LIsp system.  E.g., Emacs Lisp usually only
  enhance the operation of Emacs and relies heavily on the Emacs "machine" to
  do its work.  Therefore, Emacs Lisp is a scripting language with programming
  language capabilities, but its programs could not run without Emacs running
  first, and Emacs is a stand-alone application.  A Common Lisp system may only
  provide the environment for a Common Lisp program but would not do anything
  useful by itself.  In a sense, it has the same capacity as a shell to launch
  applications to run "in" the system, but the same way that the interactive
  loop acts as a job control language the way the shell does for Unix programs,
  the applications launched from the Common Lisp REPL are as distinct from the
  REPL as Unix programs are from the shell.

  To refine the distinction I see, a programming language has to assume control
  over the execution of the application and terminate execution when it
  returns, whereas a scripting language is subject to the control exercised by
  another application, which does not necessarily terminate when the script
  terminates.

  Now, I believe there is a distinction from some deep-rooted sense of there
  being a difference in the amount of machinery needed to support a language in
  addition to the notion of an intention of the language to be compiled into
  native machine code.  Another point of view is the intended efficiency of the
  resulting code.  Scripting languages are not expected to be compiled into
  native code that assumes full control over the machine for an extended period
  of time and only calls upon the support system, but rather the reverse: a
  script is run only occasionally as part of another application that has such
  full control.

  However, I am sure there are people who consider Common Lisp to be a "glue
  language" when they observe that low-level functionality is implemented in C
  and the higher-level application is written in Common Lisp.
  
-- 
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.