Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #32455 > unrolled thread
| Started by | rdelaney2001@gmail.com |
|---|---|
| First post | 2015-09-01 15:26 -0700 |
| Last post | 2015-09-24 12:04 -0400 |
| Articles | 20 on this page of 105 — 10 participants |
Back to article view | Back to comp.lang.java.programmer
questions re Javascript rdelaney2001@gmail.com - 2015-09-01 15:26 -0700
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-01 23:26 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-02 10:00 +0100
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-02 05:32 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-03 20:17 -0400
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-04 05:33 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:42 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-01 20:00 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-05 20:40 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-23 16:10 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 10:40 +0100
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 11:21 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 20:10 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:18 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:40 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 01:15 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:25 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:59 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:02 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-02 16:24 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 23:02 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 13:30 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-04 21:31 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-05 07:48 +0100
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 20:53 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:46 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:00 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:19 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:26 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-24 16:58 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 21:45 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 18:27 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:53 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:03 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:34 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:46 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:56 -0400
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 10:15 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 11:44 -0400
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 14:09 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 15:15 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:45 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:48 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 03:29 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 00:02 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 11:33 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 10:44 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:42 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:51 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:38 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:59 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:47 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:48 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:53 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:52 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:03 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:25 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:41 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:11 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:19 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:27 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 22:30 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:42 -0400
Re: Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, and compiling. Englewood Cliffs, N.J: Prentice-Hall. Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:26 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:07 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:55 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:46 -0400
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-25 05:20 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:54 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:05 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:36 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:57 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:10 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:27 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:19 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:35 -0400
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:10 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:55 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 00:48 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 20:55 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 11:17 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 12:30 +0100
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:00 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:03 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:14 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 19:59 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 17:13 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 22:15 +0000
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:07 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 16:48 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:02 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:32 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:45 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:13 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 21:58 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:34 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:35 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:51 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:00 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:17 -0400
Re: questions re Javascript Tim Slattery <tim@risingdove.com> - 2015-09-24 12:04 -0400
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2015-10-02 13:02 -0700 |
| Message-ID | <e471dedf-9fa6-474c-9748-908c4ad85f47@googlegroups.com> |
| In reply to | #32659 |
On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle wrote: > >> A Java compiler takes source code as input and produces output that > > > > A Java what? What was that word? Wait, was it "compiler"? A Java "compiler"? So what does a Java "compiler" do? Could it be that it *compiles* the Java language source code? As a result of which the Java code is what? Compiled? And yet Java is not a compiled language? > > > > WTF? > > > > The Java compiler changes source code into byte code. It does NOT > create machine-readable code. > > A compiler simply changes one version of code to another; in this case > it converts source code into byte code. But that does NOT mean it is > the same as compiled code - which (until Java pundits have tried to > change the definition) has always referred to code directly executable > by the machine. It does NOT refer to "assembler code" - which actually > is just a text representative of machine code. > > >> requires interpretation by a platform specific machine that 'looks up' > >> the relevant platform specific instruction and it is that that is > >> executed on the underlying hardware. > > > > So bytecode is interpreted. Bytecode is not Java, in case you hadn't noticed. > > > > Yes, in case you haven't noticed - Java Bytecode IS Java - as opposed to > bytecode in other languages. Bytecode is not Java. The specs are different. The rules are different. languages other than Java compile (!) into bytecode. So Java bytecode is bytecode in other languages (Python, Scala, JavaScript, ...). > > Compilers don't compile into machine code. They compile into assembly code of some kind. The assembly for Java is called "bytecode". > > > > See above. But you've already shown you understand neither assembler > nor machine code - much less the difference between the two. You don't need to attack me. It shows weakness in your argument. I assert that I understand those things perfectly. > > Notice that the C compiler produces ".o" files, which are not directly runnable. > > > > No, they have to be linked to the libraries, first. But that does not > change the fact the .o code is machine executable code; it's just Yes, it does. > missing necessary libraries. But the code itself is executable machine > code. Except that you cannot execute it. > > You are right that *bytecode* is interpreted. What did bytecode get emitted by again? What was that tool called? A "compiler"? Which does what to Java code again? > > > > Bytecode is generated by the Java Compiler. The Java what, again? "Compiler", you say? What is it that the Java *compiler* does to Java, again? > But that does not mean the > result is "compiled code" as is generally recognized by experts in the Yes, actually, it does. > computer community. Only those with limited Java experience consider it > that. Again with the /ad hominem/. Your arguments must truly be weak. > > Again, not to put too fine a point on it, the *bytecode* that gets interpreted (which is NOT Java) is produced by what tool? > > > > And what is the bytecode if it is not compiled Java? Can it be > interpreted by a Basic interpreter? It can be interpreted by a bytecode interpreter. Certainly not by a Java interpreter, since bytecode isn't Java. And why couldn't you compile BASIC into bytecode? <https://github.com/teverett/jvmBASIC> Hm? > >> It doesn't really matter though does it? I mean it's not going to make > >> any difference to the future of mankind is it? I'm more concerned with If that mankind is working with the JVM, yes, it will matter. > >> preventing this solid state Asus thingy from being forcibly updated to > >> the Pay As You Spy As You Go platform called windows 10. Then why post here? > >> Thank god for the gcc compiler and the Linux kernel :-) > >> That is still the compiler of choice isn't it? > >> > >>> To me, the fact that Java has to be run in a JVM is not relevant to this > > > > Java is not run in a JVM. > > > > Then what is it run in? A BASIC interpreter? It is not run at all. It is compiled. > > Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C. > > No, Java is not compiled into machine code. Although there are Yes, actually, it is. It is compiled into machine code for the JVM. This machine code is described in a separate, completely different specification from Java. It supports code compiled from many languages (including BASIC). > third-party tools which will convert Java into machine code. the Java > compiler creates byte code. Which is machine code. > If Java were compiled into machine code, it could not run on multiple > platforms under multiple OS's. The fact it can do that proves it is not Actually, it doesn't run on any machine. Only bytecode runs on various machines. > machine code - because every platform and every OS has a different > machine code interface. For bytecode. Not for Java. The interface for Java is identical for all those machines, hence the famous slogan, "Write once, run everywhere". > >>> argument: nobody ever claimed that UCSD Pascal was interpreted despite > >>> the face that its compiler output P-code that needed a runtime translator > >>> to execute it. If you count Java and P-coded compilation systems as > >>> 'interpreted languages' then you must also include, say, 6800 assembler > >>> as an 'interpreted language' if its being run on an Intel box with the > >>> air of a 6800 emulator. > > > > WTF? > > > > I point out again that Java code is not interpreted. It is process through a tool called a "compiler", program name "javac", which "compiles" the Java source code. That makes Java "compiled". > > > > And once again you are wrong. Saying so doesn't make it so. > > Java is not interpreted. Show me where it is. Not on the JVM; the JVM doesn't run Java code. > > > > The fact it requires a JVM to run, and the same compiled code runs on The same *what* code? > multiple platforms with no change is proof. That Java is compiled, is what it proves. > But there are always noobs who think they know more than the experts. > unfortunately, Java seems to have more than its fair share. I guess > that's because java noobs don't need to understand the difference. > > Those of us who have worked for years on multiple platforms in multiple > languages understand better. Those of us who have worked on multiple platforms over many decades do indeed know better. I don't know what your derogatory attitude toward "noobs" has to do with anything. Even in your own post you refer to "compiled" Java code, yet you claim Java is not compiled. You contradict yourself. The final proof is this: Java code is not executed on the JVM. At all. Therefore it is impossible that Java code is interpreted. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-02 16:24 -0400 |
| Message-ID | <mump1n$8us$1@dont-email.me> |
| In reply to | #32762 |
On 10/2/2015 4:02 PM, Lew wrote: > On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle wrote: > >>>> A Java compiler takes source code as input and produces output that >>> >>> A Java what? What was that word? Wait, was it "compiler"? A Java "compiler"? So what does a Java "compiler" do? Could it be that it *compiles* the Java language source code? As a result of which the Java code is what? Compiled? And yet Java is not a compiled language? >>> >>> WTF? >>> >> >> The Java compiler changes source code into byte code. It does NOT >> create machine-readable code. >> >> A compiler simply changes one version of code to another; in this case >> it converts source code into byte code. But that does NOT mean it is >> the same as compiled code - which (until Java pundits have tried to >> change the definition) has always referred to code directly executable >> by the machine. It does NOT refer to "assembler code" - which actually >> is just a text representative of machine code. >> >>>> requires interpretation by a platform specific machine that 'looks up' >>>> the relevant platform specific instruction and it is that that is >>>> executed on the underlying hardware. >>> >>> So bytecode is interpreted. Bytecode is not Java, in case you hadn't noticed. >>> >> >> Yes, in case you haven't noticed - Java Bytecode IS Java - as opposed to >> bytecode in other languages. > > Bytecode is not Java. The specs are different. The rules are different. languages other than Java compile (!) into bytecode. > And how are the rules and specs different? And what do other languages have to do with it? > So Java bytecode is bytecode in other languages (Python, Scala, JavaScript, ...). > OK, if bytecode is bytecode, then I can execute Java bytecode with a Python interpreter, and vice versa. I don't think so! >>> Compilers don't compile into machine code. They compile into assembly code of some kind. The assembly for Java is called "bytecode". >>> >> >> See above. But you've already shown you understand neither assembler >> nor machine code - much less the difference between the two. > > You don't need to attack me. It shows weakness in your argument. > > I assert that I understand those things perfectly. > You have shown no understanding of either. And you've just shown that once again. >>> Notice that the C compiler produces ".o" files, which are not directly runnable. >>> >> >> No, they have to be linked to the libraries, first. But that does not >> change the fact the .o code is machine executable code; it's just > > Yes, it does. > Once again you show you don't understand machine code. >> missing necessary libraries. But the code itself is executable machine >> code. > > Except that you cannot execute it. > Except it only needs to be linked to the appropriate libraries. That does not change the fact it is machine code. >>> You are right that *bytecode* is interpreted. What did bytecode get emitted by again? What was that tool called? A "compiler"? Which does what to Java code again? >>> >> >> Bytecode is generated by the Java Compiler. > > The Java what, again? "Compiler", you say? > > What is it that the Java *compiler* does to Java, again? > Yes, I do agree it is mistakenly called a compiler. If you have two horses and a cow, and call the cow a horse, how many horses do you have? The answer is still two. Just calling a cow a horse doesn't make it a horse. A better term for it would be a Java Translator, because it translates Java source code to byte code. >> But that does not mean the >> result is "compiled code" as is generally recognized by experts in the > > Yes, actually, it does. > >> computer community. Only those with limited Java experience consider it >> that. > > Again with the /ad hominem/. Your arguments must truly be weak. > No, just the truth. Only those in the Java community with no experience in real compiled languages make statements like you do. > >>> Again, not to put too fine a point on it, the *bytecode* that gets interpreted (which is NOT Java) is produced by what tool? >>> >> >> And what is the bytecode if it is not compiled Java? Can it be >> interpreted by a Basic interpreter? > > It can be interpreted by a bytecode interpreter. Certainly not by a Java interpreter, since bytecode isn't Java. And why couldn't you compile BASIC into bytecode? > > <https://github.com/teverett/jvmBASIC> > > Hm? > So, your python interpreter can interpret the output of the Java compiler? Or a BASIC interpreter? No, I'm not talking about "jvm basic" - I'm talking about a BASIC interpreter. Do you know the difference? >>>> It doesn't really matter though does it? I mean it's not going to make >>>> any difference to the future of mankind is it? I'm more concerned with > > If that mankind is working with the JVM, yes, it will matter. > Not my post - or can yo not tell the difference? >>>> preventing this solid state Asus thingy from being forcibly updated to >>>> the Pay As You Spy As You Go platform called windows 10. > > Then why post here? > Not my post - or can yo not tell the difference? >>>> Thank god for the gcc compiler and the Linux kernel :-) >>>> That is still the compiler of choice isn't it? >>>> >>>>> To me, the fact that Java has to be run in a JVM is not relevant to this >>> >>> Java is not run in a JVM. >>> >> >> Then what is it run in? A BASIC interpreter? > > It is not run at all. It is compiled. > So it runs just fine without a jvm? I don't think so! >>> Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C. >> >> No, Java is not compiled into machine code. Although there are > > Yes, actually, it is. It is compiled into machine code for the JVM. > Bytecode is not machine code. > This machine code is described in a separate, completely different specification from Java. It supports code compiled from many languages (including BASIC). > Bytecode is not machine code. >> third-party tools which will convert Java into machine code. the Java >> compiler creates byte code. > > Which is machine code. > Bytecode is not machine code. >> If Java were compiled into machine code, it could not run on multiple >> platforms under multiple OS's. The fact it can do that proves it is not > > Actually, it doesn't run on any machine. Only bytecode runs on various machines. > Ah, so now you admit bytecode is not machine code? >> machine code - because every platform and every OS has a different >> machine code interface. > > For bytecode. Not for Java. The interface for Java is identical for all those machines, hence the famous slogan, "Write once, run everywhere". > Bytecode is not machine code. >>>>> argument: nobody ever claimed that UCSD Pascal was interpreted despite >>>>> the face that its compiler output P-code that needed a runtime translator >>>>> to execute it. If you count Java and P-coded compilation systems as >>>>> 'interpreted languages' then you must also include, say, 6800 assembler >>>>> as an 'interpreted language' if its being run on an Intel box with the >>>>> air of a 6800 emulator. >>> >>> WTF? >>> >>> I point out again that Java code is not interpreted. It is process through a tool called a "compiler", program name "javac", which "compiles" the Java source code. That makes Java "compiled". >>> >> >> And once again you are wrong. > > Saying so doesn't make it so. > And saying you're right does not make it so. >>> Java is not interpreted. Show me where it is. Not on the JVM; the JVM doesn't run Java code. >>> >> >> The fact it requires a JVM to run, and the same compiled code runs on > > The same *what* code? > >> multiple platforms with no change is proof. > > That Java is compiled, is what it proves. > A better term for it would be a Java Translator, because it translates Java source code to byte code. >> But there are always noobs who think they know more than the experts. >> unfortunately, Java seems to have more than its fair share. I guess >> that's because java noobs don't need to understand the difference. >> >> Those of us who have worked for years on multiple platforms in multiple >> languages understand better. > > Those of us who have worked on multiple platforms over many decades do indeed know better. I don't know what your derogatory attitude toward "noobs" has to do with anything. > Obviously not - or you would understand there is a difference between bytecode and machine code - which you do not. > Even in your own post you refer to "compiled" Java code, yet you claim Java is not compiled. You contradict yourself. > A better term for it would be translated code. > The final proof is this: Java code is not executed on the JVM. At all. Therefore it is impossible that Java code is interpreted. > Then it runs just fine without a jvm? I don't think so. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-02 23:02 -0400 |
| Message-ID | <mungfe$jea$2@speranza.aioe.org> |
| In reply to | #32766 |
On 10/2/2015 4:24 PM, Jerry Stuckle wrote: > On 10/2/2015 4:02 PM, Lew wrote: >> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle wrote: >>>> So bytecode is interpreted. Bytecode is not Java, in case you hadn't noticed. >>> >>> Yes, in case you haven't noticed - Java Bytecode IS Java - as opposed to >>> bytecode in other languages. >> >> Bytecode is not Java. The specs are different. The rules are different. languages other than >> Java compile (!) into bytecode. >> > > And how are the rules and specs different? And what do other languages > have to do with it? JVM specs allow constructs in its byte code that are not allowed in the Java language. And such constructs are used in other languages that do compile to byte code. >> So Java bytecode is bytecode in other languages (Python, Scala, JavaScript, ...). > > OK, if bytecode is bytecode, then I can execute Java bytecode with a > Python interpreter, and vice versa. > > I don't think so! A Python interpreter process Python code not byte code. But Jython (Java Python) can compile Python to byte code. >>>> You are right that *bytecode* is interpreted. What did bytecode get emitted by again? >>>> What was that tool called? A "compiler"? Which does what to Java code again? >>>> >>> >>> Bytecode is generated by the Java Compiler. >> >> The Java what, again? "Compiler", you say? >> >> What is it that the Java *compiler* does to Java, again? > > Yes, I do agree it is mistakenly called a compiler. Just like UCSD Pascal compiler, C# compiler, VB.NET compiler, Facebook HipHop PHP compiler and many other do. > If you have two horses and a cow, and call the cow a horse, how many > horses do you have? > > The answer is still two. Just calling a cow a horse doesn't make it a > horse. > > A better term for it would be a Java Translator, because it translates > Java source code to byte code. You may think it is a better term. But the fact is that entire IT industry is calling it compiler. So to follow your own cow-horse analogy then so should you. Arne
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-10-03 13:30 +0100 |
| Message-ID | <muohko$ek6$1@dont-email.me> |
| In reply to | #32775 |
On 03/10/2015 04:02, Arne Vajhøj wrote: > On 10/2/2015 4:24 PM, Jerry Stuckle wrote: >> On 10/2/2015 4:02 PM, Lew wrote: >>> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle >>> wrote: >>>>> So bytecode is interpreted. Bytecode is not Java, in case you >>>>> hadn't noticed. >>>> >>>> Yes, in case you haven't noticed - Java Bytecode IS Java - as >>>> opposed to >>>> bytecode in other languages. >>> >>> Bytecode is not Java. The specs are different. The rules are >>> different. languages other than > >> Java compile (!) into bytecode. >>> >> >> And how are the rules and specs different? And what do other languages >> have to do with it? > > JVM specs allow constructs in its byte code that are not allowed in > the Java language. > > And such constructs are used in other languages that do compile to > byte code. > >>> So Java bytecode is bytecode in other languages (Python, Scala, >>> JavaScript, ...). >> >> OK, if bytecode is bytecode, then I can execute Java bytecode with a >> Python interpreter, and vice versa. >> >> I don't think so! > > A Python interpreter process Python code not byte code. > > But Jython (Java Python) can compile Python to byte code. Ah Ha, here we have incontrovertible proof that java is an interpreted language. The interface to the runtime environment accepts Java bytecode. If it ain't Java bytecode it ain't getting into the runtime environemnt. You can write Java source code in the Java programming language, pass the code to a compiler that accepts Java source and emits Java Bytecode. Apparently, you can write Ptyhon code and pass it to a compiler that accepts Python source and emits Java Bytecode. I'm pretty sure that somewhere on this representation of reality we call Planet Earth there is a tool that allows you to write Java Bytecode directly, rather like when you write assembler in fact. No compiler required. I can see no reason that a Chimpanzee with a block of stone and a cold chisel could't create some 'code on a stone' that is accepted by a 'code on a stone to Java compiler' that emits Java Bytecode What is similar about all these scenarios is that they seem to indicate that "technically" 'Java' is actually the Bytecode. Anything else is just a way for human beings to write their abstractions down in a way that a particular compiler can use to create the one thing that is absolutely needed if you want to take advantage of a Java Runtime Environment. Java Bytecode which is *interpreted* by the Runtime Environment. QED. -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2015-10-04 21:31 -0700 |
| Message-ID | <81e037ef-7d81-4e35-bbc6-c32499ecc94c@googlegroups.com> |
| In reply to | #32778 |
On Saturday, October 3, 2015 at 5:30:31 AM UTC-7, Eternal Hope wrote: > Java Bytecode which is *interpreted* by the Runtime Environment. "Java Bytecode [sic]" is a misnomer.You cannot call something by the wrong name then draw conclusions based on your incorrect name for it. That's called hogwash. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-10-05 07:48 +0100 |
| Message-ID | <mut6b0$abp$1@dont-email.me> |
| In reply to | #32795 |
On 05/10/2015 05:31, Lew wrote: > On Saturday, October 3, 2015 at 5:30:31 AM UTC-7, Eternal Hope wrote: >> Java Bytecode which is *interpreted* by the Runtime Environment. > > "Java Bytecode [sic]" is a misnomer.You cannot call something by the wrong name then draw conclusions based on your incorrect name for it. That's called hogwash. > Hogwash: A subject about which your knowledge is far more profound than mine. -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-05 20:53 -0400 |
| Message-ID | <muv61f$71t$1@speranza.aioe.org> |
| In reply to | #32778 |
On 10/3/2015 8:30 AM, Eternal Hope wrote: > On 03/10/2015 04:02, Arne Vajhøj wrote: >> On 10/2/2015 4:24 PM, Jerry Stuckle wrote: >>> On 10/2/2015 4:02 PM, Lew wrote: >>>> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle >>>> wrote: >>>>>> So bytecode is interpreted. Bytecode is not Java, in case you >>>>>> hadn't noticed. >>>>> >>>>> Yes, in case you haven't noticed - Java Bytecode IS Java - as >>>>> opposed to >>>>> bytecode in other languages. >>>> >>>> Bytecode is not Java. The specs are different. The rules are >>>> different. languages other than >> >> Java compile (!) into bytecode. >>>> >>> >>> And how are the rules and specs different? And what do other languages >>> have to do with it? >> >> JVM specs allow constructs in its byte code that are not allowed in >> the Java language. >> >> And such constructs are used in other languages that do compile to >> byte code. >> >>>> So Java bytecode is bytecode in other languages (Python, Scala, >>>> JavaScript, ...). >>> >>> OK, if bytecode is bytecode, then I can execute Java bytecode with a >>> Python interpreter, and vice versa. >>> >>> I don't think so! >> >> A Python interpreter process Python code not byte code. >> >> But Jython (Java Python) can compile Python to byte code. > > Ah Ha, here we have incontrovertible proof that java is an interpreted > language. I don't think the fact that Python can be compiled to byte code indicate that Java is interpreted. > The interface to the runtime environment accepts Java bytecode. If it > ain't Java bytecode it ain't getting into the runtime environemnt. > > You can write Java source code in the Java programming language, pass > the code to a compiler that accepts Java source and emits Java Bytecode. > > Apparently, you can write Ptyhon code and pass it to a compiler that > accepts Python source and emits Java Bytecode. Yes. pythonc is part of Jython. > I'm pretty sure that somewhere on this representation of reality we call > Planet Earth there is a tool that allows you to write Java Bytecode > directly, rather like when you write assembler in fact. No compiler > required. Yes. http://jasmin.sourceforge.net/ https://github.com/Storyyeller/Krakatau > What is similar about all these scenarios is that they seem to indicate > that "technically" 'Java' is actually the Bytecode. > > Anything else is just a way for human beings to write their abstractions > down in a way that a particular compiler can use to create the one thing > that is absolutely needed if you want to take advantage of a Java > Runtime Environment. I don't like the term Java without any qualification. There is Java language, Java Virtual Machine, Java API etc.. But the notion that Java language is just a readable version of JVM byte code is not true. As I wrote above: >> JVM specs allow constructs in its byte code that are not allowed in >> the Java language. You can not always convert from byte code to Java source code. Obviously you can if the code is generated from Java by the Java compiler. But not necessarily if it is compiled from another language. And also not if the byte code has been obfuscated by one of the obfuscators that deliberately change the byte code to something that are not valid in the Java language. > Java Bytecode which is *interpreted* by the Runtime Environment. Actually it would typically be JIT compiled by the JVM. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-03 10:46 -0400 |
| Message-ID | <muopj5$dds$1@dont-email.me> |
| In reply to | #32775 |
On 10/2/2015 11:02 PM, Arne Vajhøj wrote: > On 10/2/2015 4:24 PM, Jerry Stuckle wrote: >> On 10/2/2015 4:02 PM, Lew wrote: >>> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle >>> wrote: >>>>> So bytecode is interpreted. Bytecode is not Java, in case you >>>>> hadn't noticed. >>>> >>>> Yes, in case you haven't noticed - Java Bytecode IS Java - as >>>> opposed to >>>> bytecode in other languages. >>> >>> Bytecode is not Java. The specs are different. The rules are >>> different. languages other than >>> Java compile (!) into bytecode. >>> >> >> And how are the rules and specs different? And what do other languages >> have to do with it? > > JVM specs allow constructs in its byte code that are not allowed in > the Java language. > > And such constructs are used in other languages that do compile to > byte code. > And what other languages interpreters can execute Java bytecode? Just because the bytecode is not as strict as the language means nothing. >>> So Java bytecode is bytecode in other languages (Python, Scala, >>> JavaScript, ...). >> >> OK, if bytecode is bytecode, then I can execute Java bytecode with a >> Python interpreter, and vice versa. >> >> I don't think so! > > A Python interpreter process Python code not byte code. > > But Jython (Java Python) can compile Python to byte code. > I didn't ask about Java Python. I asked about pure Python. And yes, there are translators which create Python bytecode. But you didn't respond to my comment. From what you're saying, a Python interpreter can then execute Java bytecode, right? >>>>> You are right that *bytecode* is interpreted. What did bytecode get >>>>> emitted by again? >>>>> What was that tool called? A "compiler"? Which does what to Java > code again? >>>>> >>>> >>>> Bytecode is generated by the Java Compiler. >>> >>> The Java what, again? "Compiler", you say? >>> >>> What is it that the Java *compiler* does to Java, again? >> >> Yes, I do agree it is mistakenly called a compiler. > > Just like UCSD Pascal compiler, C# compiler, VB.NET compiler, > Facebook HipHop PHP compiler and many other do. > Keep showing your ignorance, Arne. You don't understand what a compiler is, do you? >> If you have two horses and a cow, and call the cow a horse, how many >> horses do you have? >> >> The answer is still two. Just calling a cow a horse doesn't make it a >> horse. >> >> A better term for it would be a Java Translator, because it translates >> Java source code to byte code. > > You may think it is a better term. > > But the fact is that entire IT industry is calling it compiler. > > So to follow your own cow-horse analogy then so should you. > > Arne > Can calling a cow a horse does not make it a horse. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-05 21:00 -0400 |
| Message-ID | <muv6fs$7td$1@speranza.aioe.org> |
| In reply to | #32782 |
On 10/3/2015 10:46 AM, Jerry Stuckle wrote: > On 10/2/2015 11:02 PM, Arne Vajhøj wrote: >> On 10/2/2015 4:24 PM, Jerry Stuckle wrote: >>> On 10/2/2015 4:02 PM, Lew wrote: >>>> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle >>>> wrote: >>>>>> So bytecode is interpreted. Bytecode is not Java, in case you >>>>>> hadn't noticed. >>>>> >>>>> Yes, in case you haven't noticed - Java Bytecode IS Java - as >>>>> opposed to >>>>> bytecode in other languages. >>>> >>>> Bytecode is not Java. The specs are different. The rules are >>>> different. languages other than >>>> Java compile (!) into bytecode. >>>> >>> >>> And how are the rules and specs different? And what do other languages >>> have to do with it? >> >> JVM specs allow constructs in its byte code that are not allowed in >> the Java language. >> >> And such constructs are used in other languages that do compile to >> byte code. > > And what other languages interpreters can execute Java bytecode? Non that I am aware of. And I don't understand why you ask as nobody have claimed that. > Just because the bytecode is not as strict as the language means nothing. It means that Java source code and JVM byte code are two different things with different rules. >>>> So Java bytecode is bytecode in other languages (Python, Scala, >>>> JavaScript, ...). >>> >>> OK, if bytecode is bytecode, then I can execute Java bytecode with a >>> Python interpreter, and vice versa. >>> >>> I don't think so! >> >> A Python interpreter process Python code not byte code. >> >> But Jython (Java Python) can compile Python to byte code. > > I didn't ask about Java Python. Jython is what is relevant when discussing Python and Java. > I asked about pure Python. Python is Python. Python runtime env exists in multiple flavors CPython (traditional interpreter and native library), Jython (for JVM), IronPython (for .NET CLR). > But you didn't respond to my comment. From what you're saying, a Python > interpreter can then execute Java bytecode, right? I wrote: #A Python interpreter process Python code not byte code. And you read it as: #a Python interpreter can then execute Java bytecode Hmm. Do you know what the English word "not" means???? Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-05 21:19 -0400 |
| Message-ID | <muv7eb$979$1@dont-email.me> |
| In reply to | #32804 |
On 10/5/2015 9:00 PM, Arne Vajhøj wrote: > On 10/3/2015 10:46 AM, Jerry Stuckle wrote: >> On 10/2/2015 11:02 PM, Arne Vajhøj wrote: >>> On 10/2/2015 4:24 PM, Jerry Stuckle wrote: >>>> On 10/2/2015 4:02 PM, Lew wrote: >>>>> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle >>>>> wrote: >>>>>>> So bytecode is interpreted. Bytecode is not Java, in case you >>>>>>> hadn't noticed. >>>>>> >>>>>> Yes, in case you haven't noticed - Java Bytecode IS Java - as >>>>>> opposed to >>>>>> bytecode in other languages. >>>>> >>>>> Bytecode is not Java. The specs are different. The rules are >>>>> different. languages other than >>>>> Java compile (!) into bytecode. >>>>> >>>> >>>> And how are the rules and specs different? And what do other languages >>>> have to do with it? >>> >>> JVM specs allow constructs in its byte code that are not allowed in >>> the Java language. >>> >>> And such constructs are used in other languages that do compile to >>> byte code. >> >> And what other languages interpreters can execute Java bytecode? > > Non that I am aware of. > > And I don't understand why you ask as nobody have claimed that. > You have claimed that byte code is byte code. >> Just because the bytecode is not as strict as the language means nothing. > > It means that Java source code and JVM byte code are two different > things with different rules. > Only to you. Most of the world knows better. >>>>> So Java bytecode is bytecode in other languages (Python, Scala, >>>>> JavaScript, ...). >>>> >>>> OK, if bytecode is bytecode, then I can execute Java bytecode with a >>>> Python interpreter, and vice versa. >>>> >>>> I don't think so! >>> >>> A Python interpreter process Python code not byte code. >>> >>> But Jython (Java Python) can compile Python to byte code. >> >> I didn't ask about Java Python. > > Jython is what is relevant when discussing Python and Java. > And how is that? I didn't bring up Python. You did. >> I asked about pure Python. > > Python is Python. Python runtime env exists in multiple flavors > CPython (traditional interpreter and native library), > Jython (for JVM), IronPython (for .NET CLR). > >> But you didn't respond to my comment. From what you're saying, a Python >> interpreter can then execute Java bytecode, right? > > I wrote: > > #A Python interpreter process Python code not byte code. > > And you read it as: > > #a Python interpreter can then execute Java bytecode > > Hmm. > > Do you know what the English word "not" means???? > > Arne > Nope. You said that Python can be translated to bytecode, also. And bytecode is bytecode. So it only goes to say that a Python interpreter can translate Java bytecode, also. Arne, I know English isn't your first language. But you aren't nearly as conversant in it as you think you are. At least that's giving you the benefit of the doubt. The other choice is that you're a troll. Maybe you're both. I'm beginning to think so. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-05 22:26 -0400 |
| Message-ID | <muvbh0$ggd$1@speranza.aioe.org> |
| In reply to | #32807 |
On 10/5/2015 9:19 PM, Jerry Stuckle wrote: > On 10/5/2015 9:00 PM, Arne Vajhøj wrote: >> On 10/3/2015 10:46 AM, Jerry Stuckle wrote: >>> On 10/2/2015 11:02 PM, Arne Vajhøj wrote: >>>> On 10/2/2015 4:24 PM, Jerry Stuckle wrote: >>>>> On 10/2/2015 4:02 PM, Lew wrote: >>>>>> On Thursday, September 24, 2015 at 4:40:21 PM UTC-7, Jerry Stuckle >>>>>> wrote: >>>>>>>> So bytecode is interpreted. Bytecode is not Java, in case you >>>>>>>> hadn't noticed. >>>>>>> >>>>>>> Yes, in case you haven't noticed - Java Bytecode IS Java - as >>>>>>> opposed to >>>>>>> bytecode in other languages. >>>>>> >>>>>> Bytecode is not Java. The specs are different. The rules are >>>>>> different. languages other than >>>>>> Java compile (!) into bytecode. >>>>>> >>>>> >>>>> And how are the rules and specs different? And what do other languages >>>>> have to do with it? >>>> >>>> JVM specs allow constructs in its byte code that are not allowed in >>>> the Java language. >>>> >>>> And such constructs are used in other languages that do compile to >>>> byte code. >>> >>> And what other languages interpreters can execute Java bytecode? >> >> Non that I am aware of. >> >> And I don't understand why you ask as nobody have claimed that. > > You have claimed that byte code is byte code. JVM byte code is JVM byte code. MSIL byte code i MSIL byte code. X byte code is X byte code. I do not remember anybody but you indicating that all sorts of byte code should be identical. >>> Just because the bytecode is not as strict as the language means nothing. >> >> It means that Java source code and JVM byte code are two different >> things with different rules. >> > > Only to you. Most of the world knows better. Are you claiming that the world believe that Java source code and JVM byte are the same???? I don't think you can find many that support that. > >>>>>> So Java bytecode is bytecode in other languages (Python, Scala, >>>>>> JavaScript, ...). >>>>> >>>>> OK, if bytecode is bytecode, then I can execute Java bytecode with a >>>>> Python interpreter, and vice versa. >>>>> >>>>> I don't think so! >>>> >>>> A Python interpreter process Python code not byte code. >>>> >>>> But Jython (Java Python) can compile Python to byte code. >>> >>> I didn't ask about Java Python. >> >> Jython is what is relevant when discussing Python and Java. >> > > And how is that? I didn't bring up Python. You did. Yes. Because Python is one of the many examples where a compiler can compile to byte code (in this case JVM byte code). >>> I asked about pure Python. >> >> Python is Python. Python runtime env exists in multiple flavors >> CPython (traditional interpreter and native library), >> Jython (for JVM), IronPython (for .NET CLR). >> >>> But you didn't respond to my comment. From what you're saying, a Python >>> interpreter can then execute Java bytecode, right? >> >> I wrote: >> >> #A Python interpreter process Python code not byte code. >> >> And you read it as: >> >> #a Python interpreter can then execute Java bytecode >> >> Hmm. >> >> Do you know what the English word "not" means???? > > Nope. You said that Python can be translated to bytecode, also. And > bytecode is bytecode. So it only goes to say that a Python interpreter > can translate Java bytecode, also. So you don't know what "not" means. OK. And the claim that all forms of byte code is identical is as stated above something that you have brougth up. Arne
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-09-25 15:32 +0100 |
| Message-ID | <mu3lpe$k7i$1@dont-email.me> |
| In reply to | #32654 |
On 24/09/2015 21:18, Lew wrote: > On Thursday, September 24, 2015 at 12:10:51 PM UTC-7, Eternal Hope wrote: >> On 24/09/2015 12:21, Martin Gregorie wrote: >>> On Thu, 24 Sep 2015 10:40:01 +0100, Eternal Hope wrote: >>> >>>> On 24/09/2015 00:10, Lew wrote: >>>>> On Saturday, September 5, 2015 at 12:40:19 PM UTC-7, Eternal Hope >>>>> wrote: >>>>>> ... technically Java is also an interpreted language although >>>>>> optimizations like Just In Time compilers tend to blur the distinction >>>>>> somewhat. > Java is compiled. The output of the compiler is run in the machine, JUST LIKE WITH C. Ignoramus -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-24 16:58 -0400 |
| Message-ID | <mu1o2i$ljj$1@dont-email.me> |
| In reply to | #32652 |
On 9/24/2015 3:10 PM, Eternal Hope wrote:
>
> Well when I went to school (jeez, was it *that* long ago) a compiled
> language was one where the compiler took source code as input and
> produced native machine code that was directly executable on the
> underlying hardware as output.
In -- let's see, 2015 minus 1966 that's forty-nine years --
of writing computer programs for many machines in many languages,
I have encountered only two compilers of that description. (Most
folks would have called them "assemblers" rather than "compilers,"
but an assembler is just a compiler for a particularly low-level
source language.) All the other compilers I've met have produced
some kind of intermediate output that required further processing --
"linking" or "loading" at the very least -- before execution.
Nearly that long ago I encountered my first microcoded machine.
Riddle me this: If compiling/linking/loading fills such a machine's
memory with instructions and starts them running, are they "native"
or are they just being interpreted by the microcode?
Also, at about that time I ran into my first emulator: It ran
on an IBM S/360 and impersonated an IBM 1620. What does this do
to your definition of "compiler?" Does the 1620's compiler cease
to be a compiler if its output is run on the emulator instead of
on the 1620 hardware? And if you then run it on the 1620 again,
does the non-compiler regain its former compilerhood?
The distinction between "compiler" and "interpreter" has been
blurred over the years, as layers of abstraction have grown deeper
and as the underlying hardware has gotten ever more "under" with
each technology generation. Nowadays, it's turtles all the way down.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-24 21:45 +0000 |
| Message-ID | <mu1qst$mkk$1@dont-email.me> |
| In reply to | #32655 |
On Thu, 24 Sep 2015 16:58:44 -0400, Eric Sosman wrote: > In -- let's see, 2015 minus 1966 that's forty-nine years -- > of writing computer programs for many machines in many languages, > I have encountered only two compilers of that description. (Most folks > would have called them "assemblers" rather than "compilers," but an > assembler is just a compiler for a particularly low-level source > language.) All the other compilers I've met have produced some kind of > intermediate output that required further processing -- "linking" or > "loading" at the very least -- before execution. > I've met exactly two. The first, in 1967, was Algol 60 for the Elliott 503. The output from this compiler was directly runnable without a further step, but it did cheat a little. The Elliott's Reserved Area Program (a very primitive OS) had the ability to load more than one program into memory (though IIRC they had to be compiled for the address region they occupies) and it allowed these programs to call each other. Elliott Algol used these support programs for i/o (now we'd call them i/o drivers) and it had another program containing matrix operations (which we'd call a set of library functions) and core backing store access. The other, in 1977, was PL/9. Tgis is a language developed for the MC6809 mpu as a clone of PL/M. PL/9 was implemented as an IDE combining editor/ compiler/debugger. It generated binary code that could be run inside or outside the IDE without any further processing: there was no linker or any equivalent. However, a reasonable collection of library code, providing i/o support and string handling was part of the PL/9 package, but this was all in the form of PL/9 source files that could be included at compile time, IOW every part of a compiled binary had been generated during a single compiler run. PL/9 was quite fast because it compiled from RAM into RAM - included source was read from floppy as required, symbol tables were in-RAM and the completed binary was only written to disk once the compilation was complete. Apart from these, I can't think of another compiled HLL I've used that could be run without the aid of a linker and/or loader. Assemblers are, of course, capable of outputting directly executable binary but, unless the OS is no more complex than Flex09, CP/M etc, or you're using the assembler to generate data modules such as device descriptors or code to be burnt into an EEPROM, you'll probably still need to link the output before using it just to pick up interface code for the OS's APIs. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-24 18:27 -0400 |
| Message-ID | <mu1tbi$cjr$1@dont-email.me> |
| In reply to | #32655 |
On 09/24/2015 04:58 PM, Eric Sosman wrote: ...Nowadays, it's turtles all the way down. Thanks for the prompt and place to park a memento for me. <https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_free>
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-24 19:53 -0400 |
| Message-ID | <mu22an$scg$1@dont-email.me> |
| In reply to | #32655 |
On 9/24/2015 4:58 PM, Eric Sosman wrote: > On 9/24/2015 3:10 PM, Eternal Hope wrote: >> >> Well when I went to school (jeez, was it *that* long ago) a compiled >> language was one where the compiler took source code as input and >> produced native machine code that was directly executable on the >> underlying hardware as output. > > In -- let's see, 2015 minus 1966 that's forty-nine years -- > of writing computer programs for many machines in many languages, > I have encountered only two compilers of that description. (Most > folks would have called them "assemblers" rather than "compilers," > but an assembler is just a compiler for a particularly low-level > source language.) All the other compilers I've met have produced > some kind of intermediate output that required further processing -- > "linking" or "loading" at the very least -- before execution. > You're about two years ahead of me. I only have 47 years or so of experience. And I know this post is going to get me into trouble with some. But I've run into multiple compilers which meet that description - starting with the FORTRAN II compiler when I started, to COBOL and PL/I compilers when I was working at IBM (not to add PL/S, which was an interesting internal language), to PASCAL, Smalltalk, C, C++ and many other compilers. And this was under multiple operating systems. Yes, all of them produced "object code" - but that was simply executable code without necessary libraries. You had to link the compiler libraries - but this only produced linkages between the machine code generated by the compiler with the machine code in the libraries. It did not change the compiled output, other than to fill in pointers. The step also creates the executable. Even assembler language programs which require no external libraries require linking, just to put them into executable format. > Nearly that long ago I encountered my first microcoded machine. > Riddle me this: If compiling/linking/loading fills such a machine's > memory with instructions and starts them running, are they "native" > or are they just being interpreted by the microcode? > If the resultant code is machine code, they are native. Microcode is internal to the chip and not part of the consideration. > Also, at about that time I ran into my first emulator: It ran > on an IBM S/360 and impersonated an IBM 1620. What does this do > to your definition of "compiler?" Does the 1620's compiler cease > to be a compiler if its output is run on the emulator instead of > on the 1620 hardware? And if you then run it on the 1620 again, > does the non-compiler regain its former compilerhood? > Yes, it is still a compiled language. If it's running on a foreign machine, the machine is emulating the original machine. That does not change the fact it is compiled. > The distinction between "compiler" and "interpreter" has been > blurred over the years, as layers of abstraction have grown deeper > and as the underlying hardware has gotten ever more "under" with > each technology generation. Nowadays, it's turtles all the way down. > It has only been blurred by Java noobs who don't know or understand the difference. But I've found that to be common amongst people who have never programmed anything but Java. They think Java is the answer to the life, the universe and everything - and nothing else counts. Those of use who have programmed otherwise in multiple languages on multiple hardware platforms and multiple operating systems understand better. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-24 22:03 -0400 |
| Message-ID | <mu2a20$icf$1@speranza.aioe.org> |
| In reply to | #32660 |
On 9/24/2015 7:53 PM, Jerry Stuckle wrote: > On 9/24/2015 4:58 PM, Eric Sosman wrote: >> On 9/24/2015 3:10 PM, Eternal Hope wrote: >>> Well when I went to school (jeez, was it *that* long ago) a compiled >>> language was one where the compiler took source code as input and >>> produced native machine code that was directly executable on the >>> underlying hardware as output. >> >> In -- let's see, 2015 minus 1966 that's forty-nine years -- >> of writing computer programs for many machines in many languages, >> I have encountered only two compilers of that description. (Most >> folks would have called them "assemblers" rather than "compilers," >> but an assembler is just a compiler for a particularly low-level >> source language.) All the other compilers I've met have produced >> some kind of intermediate output that required further processing -- >> "linking" or "loading" at the very least -- before execution. >> > > You're about two years ahead of me. I only have 47 years or so of > experience. And I know this post is going to get me into trouble with some. > > But I've run into multiple compilers which meet that description - > starting with the FORTRAN II compiler when I started, to COBOL and PL/I > compilers when I was working at IBM (not to add PL/S, which was an > interesting internal language), to PASCAL, Smalltalk, C, C++ and many > other compilers. And this was under multiple operating systems. Nope. > Yes, all of them produced "object code" - but that was simply executable > code without necessary libraries. You had to link the compiler > libraries - but this only produced linkages between the machine code > generated by the compiler with the machine code in the libraries. It > did not change the compiled output, other than to fill in pointers. The > step also creates the executable. The term, being discussed was "directly executable on the underlying hardware". Object code does not meet that criteria. It is rather close, but close it not meeting a criteria. >> The distinction between "compiler" and "interpreter" has been >> blurred over the years, as layers of abstraction have grown deeper >> and as the underlying hardware has gotten ever more "under" with >> each technology generation. Nowadays, it's turtles all the way down. >> > > It has only been blurred by Java noobs who don't know or understand the > difference. But I've found that to be common amongst people who have > never programmed anything but Java. They think Java is the answer to > the life, the universe and everything - and nothing else counts. Given that the naming convention is also used in C#, VB.NET, PHP, UCSD Pascal, then I think that it is you that are way behind in knowing about other programming languages. > Those of use who have programmed otherwise in multiple languages on > multiple hardware platforms and multiple operating systems understand > better. You seem to be seriously lacking in that regard. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-24 22:34 -0400 |
| Message-ID | <mu2bnj$geu$1@dont-email.me> |
| In reply to | #32666 |
On 9/24/2015 10:03 PM, Arne Vajhøj wrote: > On 9/24/2015 7:53 PM, Jerry Stuckle wrote: >> On 9/24/2015 4:58 PM, Eric Sosman wrote: >>> On 9/24/2015 3:10 PM, Eternal Hope wrote: >>>> Well when I went to school (jeez, was it *that* long ago) a compiled >>>> language was one where the compiler took source code as input and >>>> produced native machine code that was directly executable on the >>>> underlying hardware as output. >>> >>> In -- let's see, 2015 minus 1966 that's forty-nine years -- >>> of writing computer programs for many machines in many languages, >>> I have encountered only two compilers of that description. (Most >>> folks would have called them "assemblers" rather than "compilers," >>> but an assembler is just a compiler for a particularly low-level >>> source language.) All the other compilers I've met have produced >>> some kind of intermediate output that required further processing -- >>> "linking" or "loading" at the very least -- before execution. >>> >> >> You're about two years ahead of me. I only have 47 years or so of >> experience. And I know this post is going to get me into trouble with >> some. >> >> But I've run into multiple compilers which meet that description - >> starting with the FORTRAN II compiler when I started, to COBOL and PL/I >> compilers when I was working at IBM (not to add PL/S, which was an >> interesting internal language), to PASCAL, Smalltalk, C, C++ and many >> other compilers. And this was under multiple operating systems. > > Nope. > Contradiction without backup. Just like a troll. >> Yes, all of them produced "object code" - but that was simply executable >> code without necessary libraries. You had to link the compiler >> libraries - but this only produced linkages between the machine code >> generated by the compiler with the machine code in the libraries. It >> did not change the compiled output, other than to fill in pointers. The >> step also creates the executable. > > The term, being discussed was "directly executable on the underlying > hardware". > > Object code does not meet that criteria. > > It is rather close, but close it not meeting a criteria. > Object code is simply machine code without required libraries linked in. It is completely different from bytecode. And yes, object code is considered machine code by virtually programmers with reasonable experience in multiple platforms and languages. Only Java programmers and troll try to make the distinction. >>> The distinction between "compiler" and "interpreter" has been >>> blurred over the years, as layers of abstraction have grown deeper >>> and as the underlying hardware has gotten ever more "under" with >>> each technology generation. Nowadays, it's turtles all the way down. >>> >> >> It has only been blurred by Java noobs who don't know or understand the >> difference. But I've found that to be common amongst people who have >> never programmed anything but Java. They think Java is the answer to >> the life, the universe and everything - and nothing else counts. > > Given that the naming convention is also used in C#, VB.NET, PHP, > UCSD Pascal, then I think that it is you that are way behind > in knowing about other programming languages. > Wrong answer. VB.NET and PHP are interpreted languages. UCSD Pascal (which, unlike you, I DID use) compiled to P-code. And C# is it's own thing. It compiles to an executable, but requires the .NET framework. Really not that much different than requiring OS libraries, except that .NET is shipped separately. >> Those of use who have programmed otherwise in multiple languages on >> multiple hardware platforms and multiple operating systems understand >> better. > > You seem to be seriously lacking in that regard. > > Arne > > Again, another troll comment - a contradiction without backup. Arne, I've been programming for 47 years now. I've programmed in more languages than you've ever heard of (20+ that I can think of right now), on more platforms than you've ever heard of. I spent 8 years programming as an IBM employee, followed by 25 years as a consultant for mostly Fortune 500 companies in the North America, Europe and Asia. I know what I'm talking about. What's your experience - 5 months of Java? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-24 22:46 -0400 |
| Message-ID | <mu2cj1$msa$1@speranza.aioe.org> |
| In reply to | #32669 |
On 9/24/2015 10:34 PM, Jerry Stuckle wrote: > On 9/24/2015 10:03 PM, Arne Vajhøj wrote: >> On 9/24/2015 7:53 PM, Jerry Stuckle wrote: >>> Yes, all of them produced "object code" - but that was simply executable >>> code without necessary libraries. You had to link the compiler >>> libraries - but this only produced linkages between the machine code >>> generated by the compiler with the machine code in the libraries. It >>> did not change the compiled output, other than to fill in pointers. The >>> step also creates the executable. >> >> The term, being discussed was "directly executable on the underlying >> hardware". >> >> Object code does not meet that criteria. >> >> It is rather close, but close it not meeting a criteria. >> > > Object code is simply machine code without required libraries linked in. > It is completely different from bytecode. > > And yes, object code is considered machine code by virtually programmers > with reasonable experience in multiple platforms and languages. Only > Java programmers and troll try to make the distinction. The fact that you call it machine code does not make it directly executable. The question was not whether it was byte cod eor machine code. The question was whether it was directly executable. It is not. >>>> The distinction between "compiler" and "interpreter" has been >>>> blurred over the years, as layers of abstraction have grown deeper >>>> and as the underlying hardware has gotten ever more "under" with >>>> each technology generation. Nowadays, it's turtles all the way down. >>>> >>> >>> It has only been blurred by Java noobs who don't know or understand the >>> difference. But I've found that to be common amongst people who have >>> never programmed anything but Java. They think Java is the answer to >>> the life, the universe and everything - and nothing else counts. >> >> Given that the naming convention is also used in C#, VB.NET, PHP, >> UCSD Pascal, then I think that it is you that are way behind >> in knowing about other programming languages. > > Wrong answer. VB.NET and PHP are interpreted languages. Wrong. VB.NET is compiled. By the VB.NET compiler - the vbc command. Compilation of PHP is not standard, but FaceBook compiles PHP code. > UCSD Pascal > (which, unlike you, I DID use) compiled to P-code. Which is byte code. > And C# is it's own > thing. It compiles to an executable, Wrong. It compiles to MSIL byte code. > but requires the .NET framework. > Really not that much different than requiring OS libraries, except that > .NET is shipped separately. ,NET uses the same model as Java. > Arne, I've been programming for 47 years now. I've programmed in more > languages than you've ever heard of (20+ that I can think of right now), > on more platforms than you've ever heard of. I spent 8 years > programming as an IBM employee, followed by 25 years as a consultant for > mostly Fortune 500 companies in the North America, Europe and Asia. Possible, but just shows that people with many years of work experience can be factually wrong about what they post. See above. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-25 09:56 -0400 |
| Message-ID | <mu3jmu$dep$1@dont-email.me> |
| In reply to | #32676 |
On 9/24/2015 10:46 PM, Arne Vajhøj wrote: > On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >> On 9/24/2015 10:03 PM, Arne Vajhøj wrote: >>> On 9/24/2015 7:53 PM, Jerry Stuckle wrote: >>>> Yes, all of them produced "object code" - but that was simply >>>> executable >>>> code without necessary libraries. You had to link the compiler >>>> libraries - but this only produced linkages between the machine code >>>> generated by the compiler with the machine code in the libraries. It >>>> did not change the compiled output, other than to fill in pointers. >>>> The >>>> step also creates the executable. >>> >>> The term, being discussed was "directly executable on the underlying >>> hardware". >>> >>> Object code does not meet that criteria. >>> >>> It is rather close, but close it not meeting a criteria. >>> >> >> Object code is simply machine code without required libraries linked in. >> It is completely different from bytecode. >> >> And yes, object code is considered machine code by virtually programmers >> with reasonable experience in multiple platforms and languages. Only >> Java programmers and troll try to make the distinction. > > The fact that you call it machine code does not make it directly > executable. > > The question was not whether it was byte cod eor machine code. > > The question was whether it was directly executable. > > It is not. > It shows how little you know - but that's also obvious from so many other posts you've made. In ANY operating system, code is compiled into an object file. The result is machine code. However, an additional step is required to link in necessary libraries and other files. That does not mean the output of the compiler is not machine code. It's just not executable-ready machine code. Once the link step is done, the program is ready to run without any other program such as a jvm. >>>>> The distinction between "compiler" and "interpreter" has been >>>>> blurred over the years, as layers of abstraction have grown deeper >>>>> and as the underlying hardware has gotten ever more "under" with >>>>> each technology generation. Nowadays, it's turtles all the way down. >>>>> >>>> >>>> It has only been blurred by Java noobs who don't know or understand the >>>> difference. But I've found that to be common amongst people who have >>>> never programmed anything but Java. They think Java is the answer to >>>> the life, the universe and everything - and nothing else counts. >>> >>> Given that the naming convention is also used in C#, VB.NET, PHP, >>> UCSD Pascal, then I think that it is you that are way behind >>> in knowing about other programming languages. >> >> Wrong answer. VB.NET and PHP are interpreted languages. > > Wrong. > > VB.NET is compiled. By the VB.NET compiler - the vbc command. > Yes, but it is not executable code. It still requires the vb runtime executable (not just libraries). > Compilation of PHP is not standard, but FaceBook compiles PHP code. > Yes, there are a couple of compilers around for PHP. But now you got caught, so you're changing the subject. >> UCSD Pascal >> (which, unlike you, I DID use) compiled to P-code. > > Which is byte code. > That is true - and it required the p-code runtime exeuctable to do it. >> And C# is it's own >> thing. It compiles to an executable, > > Wrong. > > It compiles to MSIL byte code. > C# can also be compiled to executable code. It just requires the .net libraries. But it is an executable, not byte code as you claim. >> but requires the .NET framework. >> Really not that much different than requiring OS libraries, except that >> .NET is shipped separately. > > ,NET uses the same model as Java. > Again, it shows how little you know. I can call .NET from C/C++ and assembler, for instance. And those are all compiled (or in the case of assembler, assembled) languages. >> Arne, I've been programming for 47 years now. I've programmed in more >> languages than you've ever heard of (20+ that I can think of right now), >> on more platforms than you've ever heard of. I spent 8 years >> programming as an IBM employee, followed by 25 years as a consultant for >> mostly Fortune 500 companies in the North America, Europe and Asia. > > Possible, but just shows that people with many years of work > experience can be factually wrong about what they post. > > See above. > > Arne > > And it shows once again how little you understand outside of Java. You really shouldn't try to contradict those more knowledgeable than yourself. It only highlights your ignorance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web