Re: Command Languages Versus Programming Languages

At one time, we distinguished between “scripting” languages and
“programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming”
languages. Or they were slower, because they were interpreted.
>
Then languages like Perl and Java came along: both were compiled to a
bytecode, a sort of pseudo-machine-language, which was interpreted by
software, not CPU hardware. Were they “scripting” or “programming”
languages? Some might have classed Perl as a “scripting” language to
begin with, but given it is must as powerful as Java, then why
shouldn’t Java also be considered a “scripting” rather than
“programming” language? And before these two, there was UCSD Pascal,
which was probably the pioneer of this compile-to-bytecode idea.
>
So that terminology for distinguishing between classes of programming
languages became largely obsolete.
>
But there is one distinction that I think is still relevant, and that
is the one between shell/command languages and programming languages.
>
In a shell language, everything you type is assumed to be a literal
string, unless you use special substitution sequences. E.g. in a POSIX
shell:
>
    ls -l thingy
>
“give me information about the file/directory named ‘thingy’”, vs.
>
    ls -l $thingy
>
“give me information about the files/directories whose names are in
the value of the variable ‘thingy’”.
>
Whereas in a programming language, everything is assumed to be a
language construct, and every unadorned name is assumed to reference
some value/object, so you need quote marks to demarcate literal
strings, e.g. in Python:
>
    os.listdir(thingy)
>
“return a list of the contents of the directory whose name is in the
variable ‘thingy’”, vs.
>
    os.listdir("thingy")
>
“return a list of the contents of the directory named ‘thingy’”.
>
This difference in design has to do with their typical usage: most of
the use of a shell/command language is in typing a single command at a
time, for immediate execution. Whereas a programming language is
typically used to construct sequences consisting of multiple lines of
code before they are executed.
>
This difference is also why attempts to use programming languages as
though they were shell/command languages, entering and executing a
single line of code at a time, tend to end up being more trouble than
they are worth.
>
Conversely, using shell/command languages as programming languages, by
collecting multiple lines of code into shell scripts, does work, but
only up to a point. The concept of variable substitution via string
substitution tends to lead to trouble when trying to do more advanced
data manipulations.
>
So, in short, while there is some overlap in their applicable usage
areas, they are still very much oriented to different application
scenarios.