On 2024-03-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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.

Check Emacs' eshell where you can mix pseudo-sh code with Elisp

On Mon, 30 Sep 2024 20:04:53 -0000 (UTC), Bozo User wrote:

> Check Emacs' eshell where you can mix pseudo-sh code with Elisp

Can you give examples that either support or refute my claim?

El Mon, 30 Sep 2024 20:59:16 -0000 (UTC), Lawrence D'Oliveiro escribió:

> On Mon, 30 Sep 2024 20:04:53 -0000 (UTC), Bozo User wrote:
>
>> Check Emacs' eshell where you can mix pseudo-sh code with Elisp
>
> Can you give examples that either support or refute my claim?

With eshell you can do sh like commands and put elisp (literal lisp code)
inside a loop:

https://howardism.org/Technical/Emacs/eshell-why.html

On Tue, 1 Oct 2024 20:41:11 -0000 (UTC), usuario wrote:

> With eshell you can do sh like commands and put elisp (literal lisp
> code) inside a loop:
>
> https://howardism.org/Technical/Emacs/eshell-why.html

You have to put quotes around literal strings. That still makes it a
“programming language”, not a “command language” (according to my original
definition).