Re: Command Languages Versus Programming Languages

(X-posts to comp.unix.programmer and comp.lang.misc removed.)

On 29.03.2024 02:14, Lawrence D'Oliveiro wrote:

At one time, we distinguished between “scripting” languages and
“programming” languages. [...]

Overall, this appears quite arbitrary after the past decades.

There's quite some characteristics that makes it possible to
classify languages in categories. For argumentation purposes
it appears to be better to stick to their characteristics as
opposed to a category. (Categories are good for marketing.)
Any arbitrarily chosen projection to a category is debatable.

 
But there is one distinction that I think is still relevant, and that
is the one between shell/command languages and programming languages.

That distinction may be artificial. Bolsky/Korn published in
1989 the description of their Kornshell; the book was called
"The Kornshell - Command and Programming Language". It has a
reason why they named it that way. It's not necessary that a
command language and a programming language must be disjunct
programs.

 
In a shell language, everything you type is assumed to be a literal
string, unless you use special substitution sequences.

Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

[*] This may change when you may in future program in speech
form.

[...]
 
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.

In Kornshell (or POSIX shells generally) you need not draw a
line...

You can type a simple command.
You can type complex (even multi-line) commands.
You may interactively switch to an editor to extend a simple
command to a complex command or to a shell program.
You may write a shell program to execute it.
You may encapsulate simple commands in a program.
You may retrieve interactive commands into a program.

It makes no sense to draw a line between any types of use if
the tool supports it. The way you use it is on you. The Shell
can support that, like (for example) Kornshell does. Whatever
way you use it it's the same tool, based on the same Command
and Programming Language.

[...]
 
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.

It works pretty well. Unless you want to use the shell for
purposes that it's not intended to (e.g. manipulating data
structures).

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.

If you don't come from [arbitrary] "categories" (as I called
them initially) but from the "application scenarios" then you
will have less trouble picking the right language for the
intended purpose. But, yes, I agree in this final statement.

Janis