Re: Command Languages Versus Programming Languages

On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 17:25:18 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

Scripting is an activity, a use case, not a language.

>
So if I write a program to for example process some files in a directory by
your argument its a script whether I write it in shell, python, C++ or
assembler.

>
I also wrote: "Scripting refers to executing commands which are so high
level that they are entire applications or functional blocks within an
application."

>
So if I write:
>
int main()
{
system("ls | wc -l");
return 0;
}
>
Thats a script?

The "ls | wc -l" part is a script, passed off for execution to a
language that mainly supports scripting.

Note the non-scripting features here like "int main",
which doesn't /do/ anything, and typically the need to compile
and link this in order to run it.

system() itself also isn't quite "command which is so high level that
it's an inter application or functional block within an application";
it's a shim whose argument might be such a command.

No? What if I use popen() or execve() then? Where do you
draw the line?

If you use popen and execve, you're using more systems programming
functional blocks that are not scripting commands.

You're just being deliberately obtuse, not to mention snippy with the
scissors.

>
I'm not being obtuse. There is no hard dividing line between scripts and

Right now you're doubling down on obtusity, by my estimate.

programs - as I said, its shades of grey.

Would you say, fifty shades?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca