Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <veh9ph$fl2$1@reader1.panix.com>
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>
Injection-Date: Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="16034"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 8980
Lines: 209

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
========== REMAINDER OF ARTICLE TRUNCATED ==========