(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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.03.2024 12:09, Johanne Fairchild wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

At one time, we distinguished between “scripting” languages and
“programming” languages. [...] But there is one distinction that I
think is still relevant, and that is the one between shell/command
languages and programming languages.

[...]

Consider looking at a shell language like a domain-specific programming language. A shell is a programming language made specifically for
running programs. When you write a shell line, you're specifying the arguments of execve(2). In other words, a shell is a programming
language made to prepare the memory to be consumed by the system in a specific way---execve(2). (Of course, the idea evolves and you want to
glue programs, do variable substitution et cetera.)

I like the characterization as domain-specific programming
languages.

The "glue" is also control constructs (if/case/while/for/...),
which are typical characteristics of programming languages.

It's not only 'exec'. You can also view the exec'ed commands
as the functions from a "library" (/usr/bin, etc.), called
from the shell's control logic.

That's another view that may be better suited when inspecting
the modern more powerful shells than the legacy ones from the
1970's (which of course also had control constructs already).

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:

During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

Splitting into tokens is called "scanning". Parsing usually
follows scanning and unifies the grammar with the text.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.03.2024 22:04, Stefan Ram wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:

During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

Splitting into tokens is called "scanning". Parsing usually
follows scanning and unifies the grammar with the text.

Yes, it was inaccurate wording.

The intention was to point out that in a data morphing sequence
program text -> tokens -> syntax tree or token interpretation
the OP's "literal string" is something that is independent of
the later interpretation or parsing step, and that even shell
interpreters don't just interpret "literal strings"; it's no
criterion for "scripting" and appears to be just artificially
and unnecessary.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 30 Mar 2024 00:22:21 +0100, Janis Papanagnou wrote:

... even shell interpreters don't
just interpret "literal strings"; it's no criterion for "scripting" and appears to be just artificially and unnecessary.

Did somebody say it was some kind of criterion for “scripting”?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)