Path: ...!weretis.net!feeder9.news.weretis.net!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bozo User <anthk@disroot.org>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Mon, 30 Sep 2024 20:04:53 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <vdf095$2c9hb$6@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: Mon, 30 Sep 2024 22:04:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a34d6f5221beabc0a05e77e5b08e5f7d";
	logging-data="2500139"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180/UMO/gdkXDlppFYbNkaa"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:SVNTZ4U/UujfsIHlJ2sGGJCLalc=
Bytes: 4249

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