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.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 01:14 this Friday (GMT):
> 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.

Interesting, I never thought of it like that.
--
user <candycane> is generated from /dev/urandom

On Fri, 29 Mar 2024 01:14:18 -0000 (UTC)
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

My rule of thimb is that a scripting language is one whereby the source code
can be run immediately by the interpreter, eg perl, python, regardless of
what happens internally. A full fledged programming language is one that
requires a compile/debug/link step first with the compiler and runtime (if
required) being seperate. eg Java, C

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.)

A scripting language is a programming language made for a hypothetical
machine, not too different from a programming language made for a real
machine, one made of hardware.

You seem to find trouble with using a programming language in a REPL.
It seems to contradict be the overall feeling of so many people who
understand a lot about programming---who made all of these things
actually work (and fun).

On 29.03.24 10:55, Muttley@dastardlyhq.com wrote:
> On Fri, 29 Mar 2024 01:14:18 -0000 (UTC)
> 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
>
> My rule of thimb is that a scripting language is one whereby the source code
> can be run immediately by the interpreter, eg perl, python, regardless of
> what happens internally. A full fledged programming language is one that
> requires a compile/debug/link step first with the compiler and runtime (if
> required) being seperate. eg Java, C

I second that.

My 2€cts,
Josef

Muttley@dastardlyhq.com writes:
> My rule of thimb is that a scripting language is one whereby the source code
> can be run immediately by the interpreter, eg perl, python, regardless of
> what happens internally. A full fledged programming language is one that
> requires a compile/debug/link step first with the compiler and runtime (if
> required) being seperate. eg Java, C

C can be a scripting language by that rule:

$ cat t.c
#!/usr/bin/tcc -run
#include <stdio.h>

int main(void) {
return printf("Hello, world\n");
}
$ ./t.c
Hello, world

--
https://www.greenend.org.uk/rjk/

On Fri, 29 Mar 2024 11:40:03 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote:
>Muttley@dastardlyhq.com writes:
>> My rule of thimb is that a scripting language is one whereby the source code
>> can be run immediately by the interpreter, eg perl, python, regardless of
>> what happens internally. A full fledged programming language is one that
>> requires a compile/debug/link step first with the compiler and runtime (if
>> required) being seperate. eg Java, C
>
>C can be a scripting language by that rule:

No definition is perfect in this case, its all shades of grey.

On 29/03/2024 02:14, Lawrence D'Oliveiro 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.

I don't think there has ever been a clear distinction.

A "script" is usually small and often written for a particular task on a
particular system, while a "program" might be bigger and more generic,
runnable on multiple systems by multiple people. But there is no
dividing point in the type of code, and plenty of overlap - even though
the difference is often clear ("This is a script for making backups of
my servers - it uses the rsync program to do the bulk of the work").

Similarly, there are not "scripting languages" and "programming
languages". There are languages that are more suitable for script work,
and languages that are more suitable for programming work, and languages
that are suitable for both.

Then there are "interpreted" languages and "compiled" languages. As you
say, this is not a binary distinction - there are shades between this,
especially with byte compiling. Some languages, such as Python, are
used like interpreted language (you "run" the source code) but are
byte-compiled on the fly. Some, like Java, are used like compiled
languages but generate byte code that is interpreted. Others use some
byte-compiled code along with JIT machine code to blur the lines even more.

It is fair to say that "scripts" are usually written in interpreted
languages (or languages designed to look like they interpreted, by
compiling or byte-compiling on the fly). "Programs" can be written in
interpreted or compiled languages - there is no consensus.

>
> 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.
>

Such classification is just wrong, IMHO. You can write scripts in Perl,
and you can write programs in Perl. "APL" is invariably (AFAIK)
interpreted, and it is for programming rather than scripting - the
acronym stands for "A Programming Language".

And of course there are many computer languages whose prime purpose is
other tasks, even though they can be used for programming - TeX and
Postscript are examples.

> So that terminology for distinguishing between classes of programming
> languages became largely obsolete.

I am not at all convinced it was ever relevant to distinguish between
"scripting languages" and "programming languages". It was useful to
distinguish between "interpreted" and "compiled" languages, and the
overlap and blurring has increased there.

>
> 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.

That is arguably a useful distinction in the style of programming
languages, and this difference makes the language more or less suited to
particular tasks (such as typical short scripts).

Again, however, there are exceptions that mean a clear binary
distinction is not possible. Knuth did a lot of work on "literary
programming", where documentation and source is combined along with
executable code, and used such languages and tools for programs like TeX
and Metafont. ("Linux from Scratch" is another example.)

TCL is a language that might be considered half-way between your
categories here.

>
> 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.

<https://en.wikipedia.org/wiki/List_of_programming_languages_by_type>
gives something like 40 categories of programming languages, of which
"scripting languages" is one type. I think any attempt at dividing up
programming languages will either be so full of grey areas as to be
almost useless, or have so many categories that it is almost useless.
The best you can do is pick some characteristics of languages, or some
typical use-cases of languages, and ask if any given language fits there.

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> My rule of thimb is that a scripting language is one whereby the
> source code can be run immediately by the interpreter, eg perl,
> python, regardless of what happens internally. A full fledged
> programming language is one that requires a compile/debug/link step
> first with the compiler and runtime (if required) being seperate. eg
> Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged
programming languages" o_O Johanne's definition of a "scripting
language" as a DSL designed for directing the actions of the operating
system makes much more sense, IMHO.

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:
>On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> My rule of thimb is that a scripting language is one whereby the
>> source code can be run immediately by the interpreter, eg perl,
>> python, regardless of what happens internally. A full fledged
>> programming language is one that requires a compile/debug/link step
>> first with the compiler and runtime (if required) being seperate. eg
>> Java, C
>
>By *that* logic, even Lisp and Forth don't count as "full-fledged
>programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp. Forth maybe,
no idea.

On Fri, 29 Mar 2024 16:02:13 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> On Fri, 29 Mar 2024 08:44:54 -0700
> John Ames <commodorejohn@gmail.com> wrote:
> >
> >By *that* logic, even Lisp and Forth don't count as "full-fledged
> >programming languages" o_O Johanne's definition of a "scripting
>
> As a counter point, good luck writing a device driver in lisp. Forth
> maybe, no idea.

Well, suffice to say that Forth is bare-metal enough to serve as the
foundation for OpenFirmware systems... ;P

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Fri, 29 Mar 2024 11:40:03 +0000
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>Muttley@dastardlyhq.com writes:
>>> My rule of thimb is that a scripting language is one whereby the source code
>>> can be run immediately by the interpreter, eg perl, python, regardless of
>>> what happens internally. A full fledged programming language is one that
>>> requires a compile/debug/link step first with the compiler and runtime (if
>>> required) being seperate. eg Java, C
>>
>>C can be a scripting language by that rule:
>
> No definition is perfect in this case, its all shades of grey.

Yes, a definition can be close to perfet here:

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

Scripting refers to executing commands which are so high level that they
are entire applications or functional blocks within an application.
Scripting automates applications or groups of applications.

A language can /support/ scripting (and other paradigms).

If a language only supports scripting well, and nothing else, then it's
a scripting language. That's exactly the same as that a language can be
functional, or multi-paradigm with support for functional programming.

Scripting tend to have the attribute that they would never be used (and
possibly could not be used) to write the functional building blocks
which their commands execute. It's possible for an application to be
written in a language in which it is scripted, but then that's almost
certainly not a scripting language.

Yes, an aspect of scripting is that scripts are taken as-is, in the
representation in which they are written. Or at least, can be. If there
is a compiling step, it is either optional, or hidden by the
implementation. The requirement for some ahead-of-time compilation
ritual to prepare the script for execution by translating it to a
different file in a different format is anti-scripting, in a sense.

The ordinary meaning of the word "script" refers to a dialog followed by
an actor, in the same form in which it was written. The programming
word was almost certainly coined in reference to that.

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

On 2024-03-29, John Ames <commodorejohn@gmail.com> wrote:
> On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
> Muttley@dastardlyhq.com wrote:
>
>> My rule of thimb is that a scripting language is one whereby the
>> source code can be run immediately by the interpreter, eg perl,
>> python, regardless of what happens internally. A full fledged
>> programming language is one that requires a compile/debug/link step
>> first with the compiler and runtime (if required) being seperate. eg
>> Java, C
>
> By *that* logic, even Lisp and Forth don't count as "full-fledged
> programming languages" o_O Johanne's definition of a "scripting
> language" as a DSL designed for directing the actions of the operating
> system makes much more sense, IMHO.

Common Lisp requires the implementation to be able to read
and execute printed expressions, without having them placed into
a file that must be translated to a compiled file.

The most prominent CL implementations compile every form before
executing it, even at the interactive prompt. It's invisible to the
user.

Scripting doesn't mean that the commands cannot be transparently
translated into antoher language before being executed.

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

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Fri, 29 Mar 2024 08:44:54 -0700
> John Ames <commodorejohn@gmail.com> wrote:
>>On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
>>Muttley@dastardlyhq.com wrote:
>>
>>> My rule of thimb is that a scripting language is one whereby the
>>> source code can be run immediately by the interpreter, eg perl,
>>> python, regardless of what happens internally. A full fledged
>>> programming language is one that requires a compile/debug/link step
>>> first with the compiler and runtime (if required) being seperate. eg
>>> Java, C
>>
>>By *that* logic, even Lisp and Forth don't count as "full-fledged
>>programming languages" o_O Johanne's definition of a "scripting
>
> As a counter point, good luck writing a device driver in lisp.

The Lisp machines had operating systems and device drivers written in
Lisp, interrupt-driven and all. Where do you perceive the difficulty?

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

On Fri, 29 Mar 2024 17:09:56 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Fri, 29 Mar 2024 11:40:03 +0000
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>Muttley@dastardlyhq.com writes:
>>>> My rule of thimb is that a scripting language is one whereby the source
>code
>>>> can be run immediately by the interpreter, eg perl, python, regardless of
>>>> what happens internally. A full fledged programming language is one that
>>>> requires a compile/debug/link step first with the compiler and runtime (if
>
>>>> required) being seperate. eg Java, C
>>>
>>>C can be a scripting language by that rule:
>>
>> No definition is perfect in this case, its all shades of grey.
>
>Yes, a definition can be close to perfet here:

Define perfect. Yours isn't.

>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.

Umm, no, try again.

On Fri, 29 Mar 2024 17:13:47 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Fri, 29 Mar 2024 08:44:54 -0700
>> John Ames <commodorejohn@gmail.com> wrote:
>>>On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
>>>Muttley@dastardlyhq.com wrote:
>>>
>>>> My rule of thimb is that a scripting language is one whereby the
>>>> source code can be run immediately by the interpreter, eg perl,
>>>> python, regardless of what happens internally. A full fledged
>>>> programming language is one that requires a compile/debug/link step
>>>> first with the compiler and runtime (if required) being seperate. eg
>>>> Java, C
>>>
>>>By *that* logic, even Lisp and Forth don't count as "full-fledged
>>>programming languages" o_O Johanne's definition of a "scripting
>>
>> As a counter point, good luck writing a device driver in lisp.
>
>The Lisp machines had operating systems and device drivers written in
>Lisp, interrupt-driven and all. Where do you perceive the difficulty?

Were the mucky bits actually written in Lisp or was Lisp simply calling some
routines written in assembler? In the same sense that Python doesn't actually
"do" AI, its way too slow, the AI but is done in libraries written in C++ that
Python simply calls.

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Fri, 29 Mar 2024 17:09:56 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Fri, 29 Mar 2024 11:40:03 +0000
>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>>Muttley@dastardlyhq.com writes:
>>>>> My rule of thimb is that a scripting language is one whereby the source
>>code
>>>>> can be run immediately by the interpreter, eg perl, python, regardless of
>>>>> what happens internally. A full fledged programming language is one that
>>>>> requires a compile/debug/link step first with the compiler and runtime (if
>>
>>>>> required) being seperate. eg Java, C
>>>>
>>>>C can be a scripting language by that rule:
>>>
>>> No definition is perfect in this case, its all shades of grey.
>>
>>Yes, a definition can be close to perfet here:
>
> Define perfect. Yours isn't.
>
>>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."

If you write the program in assembler, are the instructions
"commands which are so high level that they are entire applications
or functional blocks within an application?"

In the assembly language program, mulitiple instructions, irrelevant
to the file processing task, are required just to correctly set up a
function call with parameters and return from it.

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

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

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Fri, 29 Mar 2024 17:13:47 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Fri, 29 Mar 2024 08:44:54 -0700
>>> John Ames <commodorejohn@gmail.com> wrote:
>>>>On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
>>>>Muttley@dastardlyhq.com wrote:
>>>>
>>>>> My rule of thimb is that a scripting language is one whereby the
>>>>> source code can be run immediately by the interpreter, eg perl,
>>>>> python, regardless of what happens internally. A full fledged
>>>>> programming language is one that requires a compile/debug/link step
>>>>> first with the compiler and runtime (if required) being seperate. eg
>>>>> Java, C
>>>>
>>>>By *that* logic, even Lisp and Forth don't count as "full-fledged
>>>>programming languages" o_O Johanne's definition of a "scripting
>>>
>>> As a counter point, good luck writing a device driver in lisp.
>>
>>The Lisp machines had operating systems and device drivers written in
>>Lisp, interrupt-driven and all. Where do you perceive the difficulty?
>
> Were the mucky bits actually written in Lisp or was Lisp simply calling some
> routines written in assembler?

Sorry, could you demarcate where exactly the goalposts are? Which mucky
bits?

In kernels written in C, there are mucky bits in assembler, like
entry and exit into an trap/interrupt handler. You usually can't save
the machine state in an interrupt handler without some instruction that
is of no use in general code generation, not to mention detailed access
to all the working registers that are not normally manipulated from the
HLL.

Yes, the mucky bits of communicating with the device, like passing
frames to and from an ethernet card, would be written in Lisp.

Assembly routines in Lisps, though not Lisp, can at least be written
in Lisp notation and assembled within Lisp.

In machine-compiled Lisps, there is the possibility of inline code,
like in C or other languages.

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

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

> As a counter point, good luck writing a device driver in lisp.

Mmh--anybody know whether that was done for Lisp machines?

--
Christian "naddy" Weisgerber naddy@mips.inka.de

The distinctions between script and programming languages made sense when
they were first introduced. Later, the ability to compile scripts followed
by the things like java bytecode, and then the use of microcode in to make
"machine language" act like a script have made the distinction murky to
the point of effectively being useless at the technical level.

From the user's point of view, text files the are executed by passing them
to an interpreter are best called scripts, and anything that goes through
some sort of compilation to a binary file that then gets executed are best
called programs.

The terminology will continue to be used, but the distinction does not matter,
except from a speed of processing difference.

Regards, Dave Hodgins

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

[...]

> The terminology will continue to be used, but the distinction does not
> matter, except from a speed of processing difference.

Just to share that I, personally, don't use the distinction. For
instance, I say that

"the answer is %.2f\n"

is a program that builds a string given its usual context. I say that

awk '1; { print "" }'

is a program to double-space a file. I haven't said ``script'' in
years.

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:
>A scripting language is a programming language made for a hypothetical
>machine, not too different from a programming language made for a real
>machine, one made of hardware.

C is clearly a programming language, yet its specification
says, "The semantic descriptions in this document describe
the behavior of an abstract machine". And you cannot buy
this abstract C machine as a piece of hardware anywhere!

On Fri, 29 Mar 2024 13:47:07 +0100, David Brown wrote:

> TCL is a language that might be considered half-way between your
> categories here.

TCL is definitely an interesting in-between case. In my limited use, I
recall it was awkward with data structures, just like shell languages. So
maybe that puts it more on the shell side than the programming side.

On Fri, 29 Mar 2024 10:37:22 +0100, Janis Papanagnou wrote:

> Program text is initially text.[*] During parsing (either in
> an interpreted or in a compiled language) you split the text
> in tokens.

And then, how do you interpret the tokens? In a shell language, you have
the assumption that “everything is literal text until indicated
otherwise”; in a programming language, you have the assumption that
“everything is a program construct until indicated otherwise”.

On Fri, 29 Mar 2024 08:09:46 -0300, Johanne Fairchild wrote:

> Consider looking at a shell language like a domain-specific programming
> language. A shell is a programming language made specifically for
> running programs. ... (Of course, the idea evolves and you want to
> glue programs, do variable substitution et cetera.)

That’s the thing. The design for a “language made specifically for running
programs” always seems to start with the assumption that what the user
types is to be passed as literal text, unless special markers are present
to indicate that they want to “glue programs, do variable substitution et
cetera”. Notice your use of the term “variable substitution”, which is
characteristic of a shell language: in a programming language, you don’t
call it “substitution”, you call it “evaluation”.

> A scripting language is a programming language made for a hypothetical
> machine, not too different from a programming language made for a real
> machine, one made of hardware.

In our CS classes we learned to think about “abstract machines”, and
forget the distinction between “software” and “hardware”. Instead, we
build layers of abstract machines, one on top of the other, getting more
and more specialized towards the particular class of problems we want to
solve at any particular time.

Command languages are just another such “abstract machine”, and the
scripts we write in them are another layer on top.

The layering only stops when you get to a GUI; they can’t be used to build
any further “machines” on top.

> You seem to find trouble with using a programming language in a REPL.

I find REPLs annoying and inconvenient. If I want to do “scratchpad”
programming, I do it in a Jupyter notebook.