Re: Command Languages Versus Programming Languages

On 12/10/2024 14:37, Rainer Weikusat wrote:

Muttley@DastartdlyHQ.org writes:

On Fri, 11 Oct 2024 20:58:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:

On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
>

On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net>:
>

The Perl compiler turns Perl source code into a set of (that's a

>
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler.

>
There are two parts: the interpreter interprets code generated by the compiler.

>
Code generated by a compiler does not require an interpreter.

 Indeed. As far as I know the term, an interpreter is something which
reads text from a file, parses it an checks it for syntax errors
and then executes the code as soon as enough of it has been gathered to
allow for execution of something, ie, a complete statement. This read,
check and parse, execute cycle is repeated until the program
terminates.

That would be some very old BASIC, or maybe a shell program where the input is a stream of lines, and each must be executed when they were entered (you'd never reach end-of-file otherwise!).
Most interpreters taking input from a file will compile the whole thing to some intermediate form first (eg. to internal bytecode). Then it will interpret that bytecode.
Otherwise they would be hoplessly slow.

In contrast to this, a compiler reads the source code completely, parses
and checks it and then transforms it into some sort of "other
representation" which can be executed without dealing with the source
code (text) again.

Some compilers (eg. the ones I write) can run programs from source just like an interpreted language. The difference here is that it first translates the whole program to native code rather than bytecode.
Then there are more complicated schemes which mix things up: they start off interpreting and turn 'hot' paths into native code via JIT techniques.