I think that at one time, scripting languages was something that lived
within other programs, like Office, and couldn't be used by themselves
without running it inside that program, and as thus was a way to add
minor functions and things to that program.
Super BAT files (to use archaic MS-DOS terms)... A collection of,
essentially, individual shell commands with minimal "if" type logic and
parameter substitution (you can expand that to things like editor
scripting -- still mostly just a bunch of the same commands one would
type at a keyboard, just automated).
Python has never struck me as a "scripting" language by itself.
REXX, OTOH, still has a "scripting" feel (though not as much as the
Amiga version, ARexx) since, by default, any statement that does not
parse as a REXX statement is automatically passed to the currently
defined command shell for execution -- in effect, rather than a BAT file
being command shell statements with an extention of script-language
logic, REXX is a language with implicit command shell capability.
Assisted by the fact that the command shell can be changed mid-stream,
so any application that is REXX-aware (on the Amiga, that was nearly
everything as the mechanism was built on top of the native IPC system)
could be scripted -- and "glued" to another... Set the command shell to
a database engine, execute database queries, assign the result to a
local variable, switch command shell to word processor, issue commands
to format the database data into word processor.
REXX also had the ability to register function libraries -- so if
such were defined for the applications, one could access the
applications without passing through the command shell method. This
latter method would be closest to the M$ COM model.
--
