Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Command Languages Versus Programming Languages
Date: Fri, 29 Mar 2024 01:14:18 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <uu54la$3su5b$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 29 Mar 2024 01:14:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="521a9234fa531f5fbb354bce794424cb";
	logging-data="4094123"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+wuxgWwoUuDVN33Y1JVSxc"
User-Agent: Pan/0.155 (Kherson; fc5a80b8)
Cancel-Lock: sha1:MSokK6OP74NrPK8bKB7buVrkbuU=
Bytes: 3902

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.