>>I think that there isn't, and that the distinction is actually
 >>harmful.
 >
 > FWIW, this would also be my answer to this question.
 >
 > It's interesting how many people answered a different question from the
 > one I actually asked.  The question many people are answering in this
 > thread is: "Is there a distinction between scrtiping languages and
 > programming languages (and if so what is it)?"  But the question I posed
 > was "Is there a USEFUL distinction?"  I think it's pretty clear that
there
 > *are* distinctions (if nothing else, the fact that people make the
 > distinction is itself a distinction).  But whether any of the
distinctions
 > have practical utility is an entirely different question, one to which I
 > join Tim in answering with a resounding "NO!".

Well, I still like the discussion, even though we are answering the
wrong questions. ;-)

I have an idea: Perhaps it's better not to talk about whether there is a
useful _distinction_ between scripting languages and "ordinary"
languages. In fact, scripting languages are a useful _addition_ to
"ordinary" languages, if these ordinary languages happen to be c/l/l/g
languages. Obviously, programmers need the kind of flexibility the
additional features provide. The discussion (and the distinction) is
useless in the context of Lisp because Lisp provides these features
right away.

Again, perhaps this is going in the wrong direction. Today, I have asked
a colleague of mine who hasn't (yet ;) adopted the Lisp mindset how he
would define the term scripting languages. He said that the
distinguishing feature is that a script is actually a text file. So for
example, he would regard DOS batch files as scripts, and therefore the
DOS command set as a scripting language.

If you really are running cron specifically, then the script might
be a Lisp invocation that talks to other Lisps through an IPC or
by some other means, or else the script might start up and then
load the other Lisp application(s) into the same process, or perhaps
the Lisp is already started, and the cron job simply alerts the script
to run via an interrupt, IPC call, or by any other means you choose.

Another way to run it is to take a Lisp-is-the-operating-system
approach; the Lisp always stays running, and an application that is
equivalent to cron (only written in Lisp) invokes the script, which
in turn runs each application (still within the same lisp invocation).

I picked cron arbitrarily, but in retrospect that was a poor
example. Something like

  0 1 * * * /path/to/cmu/lisp -load /my/script.lisp -eval \(quit\)

will do what (I think) I want.

Nevertheless, I'm sure you've answered the question that I should
have asked.  Now I just have to figure out what that question is :-)

Thanks again.

It's hard to place a simple and unambiguous label on Common Lisp
from the above point of view.  It is a true and sophisticated
programming language, and at the same time it is easy to imagine it
used in the same way as REXX in a multitude of co-existing
environments (in fact, wasn't it used like that in Lisp machines?).
On the other hand, I cannot see C (or any Algol-like language) in
REXX's role at all.  But maybe Common Lisp is the exception to the
rule, as another poster suggested.

By the way, the mainframe world offers another, older example: JCL
is a scripting language but not a programming language, isn't it?
(Please note that this is quite independent of the question if it
is an awful language or not...)

I guess the simplest (and grossly simplified) rule of thumb I can
think of is: if, even for the simplest executable unit in the
language, some sort of enclosing syntactical delimiters are
mandatory (like ``begin'' and ``end''), then it is a non-scripting
language; if merely concatenating simple expressions/statements in
the language produces an executable unit, then it can qualify as a
scripting language.  In other words, my intuitive understanding of
the distinction is based at least to some extent on the syntax,
specifically the minimum amount of syntax that makes a valid
program or script.

    *    *    *

More philosophically speaking, and in a different line of thought,
I believe that scripting is one step off programming in the
direction towards planning.  What I have in mind is that the main
difference between a plan and a program (or at least one of the
main differences) is that a program is to be executed by a machine
while a plan is to be executed by an intelligent entity.  (A plan
is always underspecified and does not provide courses of action for
almost all of the infinitely many abnormal situations that may
occur, yet its execution is expected to succeed where machine
execution of a program would `produce undefined results.')  Or to
borrow the example quoted by Kaz Kylheku for a simple illustration,

  for f in *.foo; do
    base=`basename $f .foo`
    mv $f $base.bar
  done

has more the scripting nature, while

  for f in *.foo ; do
    base="$(basename -- "$f" .foo)"
    mv -- "$f" "$base.bar"
  done

has more the programming nature, as the former is less burdened
with provisions against undefined results (with the advantage of
making the essence of what is being done more conspicuous), at the
expense of requring more intelligence by the user to avoid applying
it to a situation where it may fail, or to watch for failure and
possibly take corrective action.

  I believe most people would want to know what the distinctions are before
  they judge them useful or not.  A priori usefulness tend not to exist, so
  the obvious answer to the question is "no" /before/ one does careful study.

--
Erik Naggum, Oslo, Norway

  Would it not be called just a "gram" then?

--
Erik Naggum, Oslo, Norway

ObCL: it's 'procedure ... expose' parameter passing gives you the same
choice between lexical and dynamic scope as CL.

(Not to be confused with errorgram...)