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 15:30:03 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vegp1r$oqh$1@reader1.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <vefvo0$k1mm$1@dont-email.me> <vegiqq$me2$1@reader1.panix.com> <vegmul$ne3v$1@dont-email.me>
Injection-Date: Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="25425"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 6444
Lines: 140

In article <vegmul$ne3v$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:
>On Sun, 13 Oct 2024 13:43:54 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vefvo0$k1mm$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:
>>>On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
>>>It can mean either. Essentially its a binary that contains directly runnable 
>>>CPU machine code. I'm not sure why you're having such a conceptual struggle 
>>>understanding this simple concept.
>>
>>Oh, I understand what you mean; it's your choice of non-standard
>>terminology that I object to.  Admittedly, Microsoft uses the
>
>So what is standard terminology then?

I've already explained this to you.

>>Or consider x86; most modern x86 processors are really dataflow
>>CPUs, and the x86 instruction encoding is just a bytecode that
>>is, in fact, interpreted by the real CPU under the hood.  So
>>where does that fit on your little shrink-to-fit taxonomy?  What
>
>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
compiler means, "generates object code directly runnable on a
CPU"?  If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?

>[lots of waffle snipped]

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

>>Then I can only guess that you never used either SunOS or HP-UX.
>
>"I disagree with you so you must be lying". Whatever.

Way to miss the point by fixating on random details.  Lawrence,
is that you?

>>Sorry, you've shown no evidence why I should believe your
>>assertions, and you've ignored directly disconfirming evidence
>
>Likewise.

I've cited evidence written by acknowledged experts in the
field; have you?

>>>Really? So java bytecode will run direct on x86 or ARM will it? Please give
>>>some links to this astounding discovery you've made.
>>
>>Um, ok. https://en.wikipedia.org/wiki/Jazelle
>
>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?

>>>So in your mind google translate is a "compiler" for spoken languages is it?
>>
>>To quote you above, "now you're just being silly."
>
>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.

>>>No, it was a pre-compiler. Just like Oracles PRO*C/C++.
>>
>>Nope.
>
>Yes, they're entirely analoguous.
>
>https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm

Nah, not really.

>>>I know the important ones. You've dug out some obscure names from google
>>>that probably only a few CS courses even mention never mind study the work of.
>>
>>
>>Ok, so you aren't familiar with the current state of the field
>>as far as systems go; fair enough.
>
>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."

>>Aho, Sethi, and Ullman: "Simply stated, a compiler is a program
>>that reads a program written in one language -- the _source_
>>language -- and translates it into an equivalent program in
>>another language -- the _target_ language."
>
>Thats an opinion, not a fact.
>
>>So it would seem that your definition is not shared by those who
>>quite literally wrote the book on compilers.
>
>Writing the book is not the same as writing the compilers.

Well, let's look at the words of someone who wrote the compiler,
then.  Stroustrup writes in his HOPL paper on C++ that cfront
was, "my original C++ compiler".  Quoted from,
https://stroustrup.com/hopl-almost-final.pdf (page 6).

>>Look, I get the desire to want to pin things down into neat
>>little categorical buckets, and if in one's own experience a
>>"compiler" has only ever meant GCC or perhaps clang (or maybe
>>Microsoft's compiler), then I can get where one is coming from.
>
>You can add a couple of TI and MPLAB compilers into that list. And obviously
>Arduinos , whatever its called. Been a while.
>
>>But as usual, in its full generality, the world is just messier
>>than whatever conceptual boxes you've built up here.
>
>There's a difference between accepting there are shades of grey and asserting
>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
language to a binary machine language, but that needn't be the
case.

	- Dan C.