Re: Command Languages Versus Programming Languages

In article <vegqu5$o3ve$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:

In article <vegmul$ne3v$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

So what is standard terminology then?

>
I've already explained this to you.

>
No you haven't. You explanation seems to be "anything that converts from one
language to another".
>

What happens inside the CPU is irrelevant. Its a black box as far as the
rest of the machine is concerned. As I said in another post, it could be
pixies with abacuses, doesn't matter.

>
So why do you think it's so important that the definition of a

>
Who said its important? Its just what most people think of as compilers.
>

CPU"?  If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?

>
You're the one making a big fuss about it with pages of waffle to back up
your claim.
>

[lots of waffle snipped]

>
In other words, you discard anything that doesn't fit with your
preconceptions.  Got it.

>
No, I just have better things to do on a sunday than read all that. Keep
it to the point.
>

So its incomplete and has to revert to software for some opcodes. Great.
FWIW Sun also had a java processor but you still can't run bytecode on
normal hardware without a JVM.

>
Cool.  So if I run a program targetting a newer version of an
ISA is run on an older machine, and that machine lacks a newer
instruction present in the program, and the CPU generates an
illegal instruction trap at runtime that the OS catches and
emulates on the program's behalf, the program was not compiled?
>
And again, what about an emulator for a CPU running on a
different CPU?  I can boot 7th Edition Unix on a PDP-11
emulator on my workstation; does that mean that the 7the
edition C compiler wasn't a compiler?

>
Its all shades of grey. You seem to be getting very worked up about it.
As I said, most people consider a compiler as something that translates source
code to machine code and writes it to a file.
>

Why, whats the difference? Your definition seems to be any program that can
translate from one language to another.

>
If you can't see that yourself, then you're either ignorant or
obstinant.  Take your pick.

>
So you can't argue the failure of your logic then. Noted.
>

Yes, they're entirely analoguous.
>
https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm

>
Nah, not really.

>
Oh nice counter arguement, you really sold your POV there.
>

Who cares about the current state? Has nothing to do with this discussion.

>
In other words, "I don't have an argument, so I'll just lamely
try to define things until I'm right."

>
Im just defining things the way most people see it, not some ivory tower
academics. Anyway, lifes too short for the rest.
>
[tl;dr]
>

that a compiler is pretty much any program which translates from one thing to
another.

>
No.  It translates one computer _language_ to another computer
_language_.  In the usual case, that's from a textual source

>
Machine code isn't a language. Fallen at the first hurdle with that
definition.
>
>

Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Summary:
Expires:
References: <uu54la$3su5b$6@dont-email.me> <vegmul$ne3v$1@dont-email.me> <vegp1r$oqh$1@reader1.panix.com> <vegqu5$o3ve$1@dont-email.me>
Sender:
Followup-To:
Distribution:
Organization:
Keywords:
Cc:

In article <vegqu5$o3ve$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:

In article <vegmul$ne3v$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

So what is standard terminology then?

>
I've already explained this to you.

>
No you haven't. You explanation seems to be "anything that converts from one
language to another".

The context of this specific quote, which you snipped, was your
insistence on the meaning of the term, "standalone binary."
There are a number of common terms for what you are describing,
which is the general term for the executable output artifact
from a software build, none of which is "standalone binary".

Common terms are "executable" or "executable file" (that's what
the ELF standard calls it, for instance), but also "binary",
"image", etc.

What happens inside the CPU is irrelevant. Its a black box as far as the
rest of the machine is concerned. As I said in another post, it could be
pixies with abacuses, doesn't matter.

>
So why do you think it's so important that the definition of a

>
Who said its important? Its just what most people think of as compilers.

Well, you seem to think it's rather important.

CPU"?  If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?

>
You're the one making a big fuss about it with pages of waffle to back up
your claim.

I just don't like misinformation floating around unchallenged.

You have cited nothing to back up your claims.

So its incomplete and has to revert to software for some opcodes. Great.
FWIW Sun also had a java processor but you still can't run bytecode on
normal hardware without a JVM.

>
Cool.  So if I run a program targetting a newer version of an
ISA is run on an older machine, and that machine lacks a newer
instruction present in the program, and the CPU generates an
illegal instruction trap at runtime that the OS catches and
emulates on the program's behalf, the program was not compiled?
>
And again, what about an emulator for a CPU running on a
different CPU?  I can boot 7th Edition Unix on a PDP-11
emulator on my workstation; does that mean that the 7the
edition C compiler wasn't a compiler?

>
Its all shades of grey. You seem to be getting very worked up about it.

Nah, I don't really care, aside from not wanting misinformation
to stand unchallenged.

As I said, most people consider a compiler as something that translates source
code to machine code and writes it to a file.

Sure, if you're talking informally and you mention "a compiler"
most people will know more or less what you're talking about.
But back in <vebffc$3n6jv$1@dont-email.me> you wrote,

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

I said that was a bad distinction, to which you replied in
<vebi0j$3nhvq$1@dont-email.me>:

|A proper compiler writes a standalone binary file to disk.

Except that, well, it doesn't.  Even the "proper compilers" that
you claim familiarity with basically don't do that; as I pointed
out to you, they generate object files and a driver invokes a
linker.

For that matter, the compiler itself may not even generate
object code, but rather, may generate textual assembly and let a
separate assembler pass turn _that_ into object code.

So yeah.  What you've defined to be a "proper compiler" isn't
really what you seem to think that it is.

[snip]

Who cares about the current state? Has nothing to do with this discussion.

>
In other words, "I don't have an argument, so I'll just lamely
try to define things until I'm right."

>
Im just defining things the way most people see it, not some ivory tower
academics. Anyway, lifes too short for the rest.

The people who create the field are the ones who get to make
the defintiions, not you.

Machine code isn't a language. Fallen at the first hurdle with that
definition.

Oh really?  Is that why they call it "machine language"?  It's
even in the dictionary with "machine code" as a synonymn:
https://www.merriam-webster.com/dictionary/machine%20language

- Dan C.