Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 29 Mar 2024 10:37:22 +0100
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <uu624j$792q$1@dont-email.me>
References: <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 09:37:24 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e69c431b514d7dea0b983a8ae814ccd0";
	logging-data="238682"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19tS3MgYiZ2WqQlujPnfq4V"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:1mjZDY7XE4SQjiEe9UOQ3aHGoIY=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <uu54la$3su5b$6@dont-email.me>
Bytes: 4398

(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