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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-05 21:41 -0400 |
| Message-ID | <muv8s4$c2s$1@speranza.aioe.org> |
| In reply to | #32808 |
On 10/5/2015 9:25 PM, Jerry Stuckle wrote: > On 10/5/2015 9:03 PM, Arne Vajhøj wrote: >> On 10/3/2015 10:52 AM, Jerry Stuckle wrote: >>> On 10/2/2015 10:53 PM, Arne Vajhøj wrote: >>>> On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >>>>> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>>>>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>>>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>>>>> 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). >>>>>> >>>>>> VB.NET compiler compiles to MSIL. >>>>>> >>>>>> There are no such thing as a VB.NET runtime executable. >>>>>> >>>>>> VB.NET only relies on .NET framework. >>>>> >>>>> Try again. VB.NET can also be compiled to an executable. >>>> >>>> There are no command line switch on the VB.NET compiler vbc to >>>> generate native code. >>>> >>> >>> Once again you show your ignorance. But that's normal. vbc is not the >>> only tool for VB; neither is it necessarily the last step in building >>> native code. >> >> vbc is the only compiler for VB.NET. >> > > Once again you show your ignorance. I didn't say that there are other > compilers for vbc. But I did say it is not necessarily the last step in > building native code. So we now agree that the VB.NET compiler (vbc) generate MSIL? The fact that there exist tools to convert MSIL to other formats is rather irrelevant for the fact that there is a VB.NET compiler that always compile to MSIL. >>>>>>>>> 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. >>>>>> >>>>>> There are no switch to the C# compiler to generate native code. >>>>>> >>>>>> It always generate MSIL. >>>>>> >>>>>> And MSIL is byte code. >>>>> >>>>> ROFLMAO! Still arguing that lost cause? Just to prove once again you >>>>> are arguing from ignorance, see >>>>> >>>>> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >>>> >>>> Maybe you should read what you link to. >>>> >>>> That link is to the NGEN utility not the C# compiler. >>>> >>>> The NGEN utility can generate native code. >>>> >>>> The C# compiler can not. >>> >>> And what does NGEN run against? Maybe .net code? >> >> Yes. It takes MSIL as input. >> >> MSIL that is output from C# compiler or .NET compiler or >> another .NET compiler. > > Gee, so you CAN generate native code from C# and other .net files then! Sure. But it has just nothing to do with what the C# compiler does. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-05 22:11 -0400 |
| Message-ID | <muvag4$ba4$4@dont-email.me> |
| In reply to | #32812 |
On 10/5/2015 9:41 PM, Arne Vajhøj wrote: > On 10/5/2015 9:25 PM, Jerry Stuckle wrote: >> On 10/5/2015 9:03 PM, Arne Vajhøj wrote: >>> On 10/3/2015 10:52 AM, Jerry Stuckle wrote: >>>> On 10/2/2015 10:53 PM, Arne Vajhøj wrote: >>>>> On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >>>>>> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>>>>>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>>>>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>>>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>>>>>> 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). >>>>>>> >>>>>>> VB.NET compiler compiles to MSIL. >>>>>>> >>>>>>> There are no such thing as a VB.NET runtime executable. >>>>>>> >>>>>>> VB.NET only relies on .NET framework. >>>>>> >>>>>> Try again. VB.NET can also be compiled to an executable. >>>>> >>>>> There are no command line switch on the VB.NET compiler vbc to >>>>> generate native code. >>>>> >>>> >>>> Once again you show your ignorance. But that's normal. vbc is not the >>>> only tool for VB; neither is it necessarily the last step in building >>>> native code. >>> >>> vbc is the only compiler for VB.NET. >>> >> >> Once again you show your ignorance. I didn't say that there are other >> compilers for vbc. But I did say it is not necessarily the last step in >> building native code. > > So we now agree that the VB.NET compiler (vbc) generate MSIL? > > The fact that there exist tools to convert MSIL to other formats is > rather irrelevant for the fact that there is a VB.NET compiler > that always compile to MSIL. > > >>>>>>>>>> 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. >>>>>>> >>>>>>> There are no switch to the C# compiler to generate native code. >>>>>>> >>>>>>> It always generate MSIL. >>>>>>> >>>>>>> And MSIL is byte code. >>>>>> >>>>>> ROFLMAO! Still arguing that lost cause? Just to prove once again >>>>>> you >>>>>> are arguing from ignorance, see >>>>>> >>>>>> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >>>>> >>>>> Maybe you should read what you link to. >>>>> >>>>> That link is to the NGEN utility not the C# compiler. >>>>> >>>>> The NGEN utility can generate native code. >>>>> >>>>> The C# compiler can not. >>>> >>>> And what does NGEN run against? Maybe .net code? >>> >>> Yes. It takes MSIL as input. >>> >>> MSIL that is output from C# compiler or .NET compiler or >>> another .NET compiler. >> >> Gee, so you CAN generate native code from C# and other .net files then! > > Sure. > > But it has just nothing to do with what the C# compiler does. > > Arne > > > You said C# could not be compiled into native code. I just proved you wrong yet again. And you can't squirm out of it this time, either - no matter how hard you try. Just another case where you show your ignorance. -- ================== 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:19 -0400 |
| Message-ID | <muvb4c$fk6$3@speranza.aioe.org> |
| In reply to | #32818 |
On 10/5/2015 10:11 PM, Jerry Stuckle wrote: > On 10/5/2015 9:41 PM, Arne Vajhøj wrote: >> On 10/5/2015 9:25 PM, Jerry Stuckle wrote: >>> On 10/5/2015 9:03 PM, Arne Vajhøj wrote: >>>> On 10/3/2015 10:52 AM, Jerry Stuckle wrote: >>>>> On 10/2/2015 10:53 PM, Arne Vajhøj wrote: >>>>>> On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >>>>>>> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>>>>>>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>>>>>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>>>>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>>>>>> 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. >>>>>>>> >>>>>>>> There are no switch to the C# compiler to generate native code. >>>>>>>> >>>>>>>> It always generate MSIL. >>>>>>>> >>>>>>>> And MSIL is byte code. >>>>>>> >>>>>>> ROFLMAO! Still arguing that lost cause? Just to prove once again >>>>>>> you >>>>>>> are arguing from ignorance, see >>>>>>> >>>>>>> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >>>>>> >>>>>> Maybe you should read what you link to. >>>>>> >>>>>> That link is to the NGEN utility not the C# compiler. >>>>>> >>>>>> The NGEN utility can generate native code. >>>>>> >>>>>> The C# compiler can not. >>>>> >>>>> And what does NGEN run against? Maybe .net code? >>>> >>>> Yes. It takes MSIL as input. >>>> >>>> MSIL that is output from C# compiler or .NET compiler or >>>> another .NET compiler. >>> >>> Gee, so you CAN generate native code from C# and other .net files then! >> >> Sure. >> >> But it has just nothing to do with what the C# compiler does. > > You said C# could not be compiled into native code. No - I said that the C# compiler did not compile to native code. > I just proved you wrong yet again. No - you just posted some irrelevant information. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-05 22:27 -0400 |
| Message-ID | <muvbf1$eve$3@dont-email.me> |
| In reply to | #32820 |
On 10/5/2015 10:19 PM, Arne Vajhøj wrote: > On 10/5/2015 10:11 PM, Jerry Stuckle wrote: >> On 10/5/2015 9:41 PM, Arne Vajhøj wrote: >>> On 10/5/2015 9:25 PM, Jerry Stuckle wrote: >>>> On 10/5/2015 9:03 PM, Arne Vajhøj wrote: >>>>> On 10/3/2015 10:52 AM, Jerry Stuckle wrote: >>>>>> On 10/2/2015 10:53 PM, Arne Vajhøj wrote: >>>>>>> On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >>>>>>>> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>>>>>>>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>>>>>>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>>>>>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> There are no switch to the C# compiler to generate native code. >>>>>>>>> >>>>>>>>> It always generate MSIL. >>>>>>>>> >>>>>>>>> And MSIL is byte code. >>>>>>>> >>>>>>>> ROFLMAO! Still arguing that lost cause? Just to prove once again >>>>>>>> you >>>>>>>> are arguing from ignorance, see >>>>>>>> >>>>>>>> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >>>>>>>> >>>>>>> >>>>>>> Maybe you should read what you link to. >>>>>>> >>>>>>> That link is to the NGEN utility not the C# compiler. >>>>>>> >>>>>>> The NGEN utility can generate native code. >>>>>>> >>>>>>> The C# compiler can not. >>>>>> >>>>>> And what does NGEN run against? Maybe .net code? >>>>> >>>>> Yes. It takes MSIL as input. >>>>> >>>>> MSIL that is output from C# compiler or .NET compiler or >>>>> another .NET compiler. >>>> >>>> Gee, so you CAN generate native code from C# and other .net files then! >>> >>> Sure. >>> >>> But it has just nothing to do with what the C# compiler does. >> >> You said C# could not be compiled into native code. > > No - I said that the C# compiler did not compile to native code. > >> I just proved you wrong yet again. > > No - you just posted some irrelevant information. > > Arne > > > > Only irrelevant to you, because it proves how wrong you were. But that's what trolls do. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-24 22:30 -0400 |
| Message-ID | <mu2bkb$g85$1@dont-email.me> |
| In reply to | #32660 |
On 09/24/2015 07:53 PM, Jerry Stuckle wrote: > On 9/24/2015 4:58 PM, Eric Sosman wrote: > >> 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. At least since 1973, see 9.1 in: Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, and compiling. Englewood Cliffs, N.J: Prentice-Hall. > > 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. > Another recent article on cljp introduced a future instructor of introductory Java programming. Would it be fair for an instructor of early students of Java to state that Java source code is compiled to bytecode that is in turn interpreted by a Java virtual machine.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-24 22:42 -0400 |
| Message-ID | <mu2c6p$h7c$1@dont-email.me> |
| In reply to | #32668 |
On 9/24/2015 10:30 PM, Jeff Higgins wrote: > On 09/24/2015 07:53 PM, Jerry Stuckle wrote: >> On 9/24/2015 4:58 PM, Eric Sosman wrote: >> >>> 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. > > At least since 1973, see 9.1 in: > Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, > and compiling. Englewood Cliffs, N.J: Prentice-Hall. > The opinion of a couple of people in one book. Not shared by most people, even in 1972, including my university professors, and in the 80's, senior programmers at IBM. >> >> 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. >> > Another recent article on cljp introduced a future instructor of > introductory Java programming. > > Would it be fair for an instructor of early students of Java > to state that Java source code is compiled to bytecode that is > in turn interpreted by a Java virtual machine. > > Yes, it would. That's how I taught it - both to early and advanced students. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-24 23:26 -0400 |
| Subject | Re: Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, and compiling. Englewood Cliffs, N.J: Prentice-Hall. |
| Message-ID | <mu2es8$oo5$1@dont-email.me> |
| In reply to | #32672 |
On 09/24/2015 10:42 PM, Jerry Stuckle wrote: > On 9/24/2015 10:30 PM, Jeff Higgins wrote: >> Would it be fair for an instructor of early students of Java >> to state that Java source code is compiled to bytecode that is >> in turn interpreted by a Java virtual machine. >> >> > > Yes, it would. That's how I taught it - both to early and advanced > students. Great! So if they need further information the can be pointed to the "questions re Javascript" thread in cljp. Rich must be gleeful.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-24 23:07 -0400 |
| Message-ID | <mu2dq0$p17$1@speranza.aioe.org> |
| In reply to | #32668 |
On 9/24/2015 10:30 PM, Jeff Higgins wrote: > On 09/24/2015 07:53 PM, Jerry Stuckle wrote: >> On 9/24/2015 4:58 PM, Eric Sosman wrote: >> >>> 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. > > At least since 1973, see 9.1 in: > Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, > and compiling. Englewood Cliffs, N.J: Prentice-Hall. Some research seems to indicate that the concept goes back to 1966 and BCPL and O-code. https://en.wikipedia.org/wiki/BCPL Arne
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2015-09-24 23:55 -0400 |
| Message-ID | <mu2gjk$sru$1@dont-email.me> |
| In reply to | #32679 |
On 09/24/2015 11:07 PM, Arne Vajhøj wrote: > On 9/24/2015 10:30 PM, Jeff Higgins wrote: >> On 09/24/2015 07:53 PM, Jerry Stuckle wrote: >>> On 9/24/2015 4:58 PM, Eric Sosman wrote: >>> >>>> 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. >> >> At least since 1973, see 9.1 in: >> Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, >> and compiling. Englewood Cliffs, N.J: Prentice-Hall. > > Some research seems to indicate that the concept goes back to 1966 > and BCPL and O-code. > > https://en.wikipedia.org/wiki/BCPL Which points to O-code. Is it really true that any HLL that is compiled to any type of IR is by definition an interpreted language?
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-27 20:46 -0400 |
| Message-ID | <mua2lg$deo$3@speranza.aioe.org> |
| In reply to | #32682 |
On 9/24/2015 11:55 PM, Jeff Higgins wrote: > On 09/24/2015 11:07 PM, Arne Vajhøj wrote: >> On 9/24/2015 10:30 PM, Jeff Higgins wrote: >>> On 09/24/2015 07:53 PM, Jerry Stuckle wrote: >>>> On 9/24/2015 4:58 PM, Eric Sosman wrote: >>>> >>>>> 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. >>> >>> At least since 1973, see 9.1 in: >>> Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, >>> and compiling. Englewood Cliffs, N.J: Prentice-Hall. >> >> Some research seems to indicate that the concept goes back to 1966 >> and BCPL and O-code. >> >> https://en.wikipedia.org/wiki/BCPL > > Which points to O-code. > > Is it really true that any HLL that is compiled to any type of IR > is by definition an interpreted language? Since interpreters do not convert to an output format at all then obviously not. Arne
[toc] | [prev] | [next] | [standalone]
| From | e.d.programmer@gmail.com |
|---|---|
| Date | 2015-09-25 05:20 -0700 |
| Message-ID | <721022ff-9cc5-4f0c-b5f7-65d791985094@googlegroups.com> |
| In reply to | #32668 |
On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins wrote: > Would it be fair for an instructor of early students of Java > to state that Java source code is compiled to bytecode that is > in turn interpreted by a Java virtual machine. I've always heard Java is an interpreted language, because it cannot run by itself. A system must have Java installed to run it and that Java install has different interpretations for the same code to run on Windows or Mac or Linux. That may be confusing because it is such a high level language that it has a compile step which produces a .class file that is not human readable, but also means nothing to the OS without a Java install. Compiled code creates .exe files on Windows which can run without installing a separate application. A mainframe wouldn't use the .exe extension but would run COBOL as compiled code. Javascript is truly interpreted code since it runs as the source text and requires an interpreter for each OS. VB Script runs as the source text though it is Windows specific.. Is Android Java considered compiled code? It doesn't require a separate install for the interpreter, it just created .apk files which are run directly by the Java based OS.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-27 20:54 -0400 |
| Message-ID | <mua345$ed4$1@speranza.aioe.org> |
| In reply to | #32687 |
On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: > On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins > wrote: >> Would it be fair for an instructor of early students of Java to >> state that Java source code is compiled to bytecode that is in turn >> interpreted by a Java virtual machine. > > I've always heard Java is an interpreted language, because it cannot > run by itself. A system must have Java installed to run it and that > Java install has different interpretations for the same code to run > on Windows or Mac or Linux. A native executable requires a CPU. Java byte code requires a JVM. Remember that VM mean Virtual Machine. The terms compiled language and interpreted language are very fuzzy. > Is Android Java considered compiled code? It doesn't require a > separate install for the interpreter, it just created .apk files > which are run directly by the Java based OS. The only reason that you don't need to install something is that Android ships with a VM. Or did ship. Dalvik was a true VM. ART is more of an extra compilation to native. Read: https://en.wikipedia.org/wiki/Dalvik_%28software%29 https://en.wikipedia.org/wiki/Android_Runtime Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-27 23:05 -0400 |
| Message-ID | <muaam1$g6h$1@dont-email.me> |
| In reply to | #32720 |
On 9/27/2015 8:54 PM, Arne Vajhøj wrote: > On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: >> On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins >> wrote: >>> Would it be fair for an instructor of early students of Java to >>> state that Java source code is compiled to bytecode that is in turn >>> interpreted by a Java virtual machine. >> >> I've always heard Java is an interpreted language, because it cannot >> run by itself. A system must have Java installed to run it and that >> Java install has different interpretations for the same code to run >> on Windows or Mac or Linux. > > A native executable requires a CPU. > > Java byte code requires a JVM. > > Remember that VM mean Virtual Machine. > So Java does not require a CPU. ROFLMAO! > The terms compiled language and interpreted language are very fuzzy. > Only to you, Arne. To most programmers, the terms are perfectly clear. But once again that's not surprising for you. <snip rest of junk> -- ================== 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 22:36 -0400 |
| Message-ID | <munf0b$gtn$1@speranza.aioe.org> |
| In reply to | #32726 |
On 9/27/2015 11:05 PM, Jerry Stuckle wrote: > On 9/27/2015 8:54 PM, Arne Vajhøj wrote: >> On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: >>> On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins >>> wrote: >>>> Would it be fair for an instructor of early students of Java to >>>> state that Java source code is compiled to bytecode that is in turn >>>> interpreted by a Java virtual machine. >>> >>> I've always heard Java is an interpreted language, because it cannot >>> run by itself. A system must have Java installed to run it and that >>> Java install has different interpretations for the same code to run >>> on Windows or Mac or Linux. >> >> A native executable requires a CPU. >> >> Java byte code requires a JVM. >> >> Remember that VM mean Virtual Machine. > > So Java does not require a CPU. ROFLMAO! Java byte code requires a JVM. I am not aware of any JVM implementation that does not use a CPU. But the point is that Java byte code only cares about the JVM interface. It does not care about whether it is JVM hardware, JVM software running in interpreted mode or JVM software using JIT compiler. In principle it is not different from what we call a native image. A native image can run on the CPU it was targeted at or it can run in a hardware simulator emulating that CPU. There is a practical difference in that in the real world Java is always run in a software JVM and native image is almost always run on its matching CPU. >> The terms compiled language and interpreted language are very fuzzy. > > Only to you, Arne. To most programmers, the terms are perfectly clear. Really. I thought most programmers were aware that you can create both compilers and interpreters for most (all?) languages. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-03 10:57 -0400 |
| Message-ID | <muoq8b$fpb$1@dont-email.me> |
| In reply to | #32769 |
On 10/2/2015 10:36 PM, Arne Vajhøj wrote: > On 9/27/2015 11:05 PM, Jerry Stuckle wrote: >> On 9/27/2015 8:54 PM, Arne Vajhøj wrote: >>> On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: >>>> On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins >>>> wrote: >>>>> Would it be fair for an instructor of early students of Java to >>>>> state that Java source code is compiled to bytecode that is in turn >>>>> interpreted by a Java virtual machine. >>>> >>>> I've always heard Java is an interpreted language, because it cannot >>>> run by itself. A system must have Java installed to run it and that >>>> Java install has different interpretations for the same code to run >>>> on Windows or Mac or Linux. >>> >>> A native executable requires a CPU. >>> >>> Java byte code requires a JVM. >>> >>> Remember that VM mean Virtual Machine. >> >> So Java does not require a CPU. ROFLMAO! > > Java byte code requires a JVM. > > I am not aware of any JVM implementation that does not use a CPU. > Ah, but you said "native executable requires a CPU" and "Java byte code (sic) requires a JVM". By deduction, you are saying Java bytecode (the correct spelling) does not require a CPU. > But the point is that Java byte code only cares about the JVM > interface. > > It does not care about whether it is JVM hardware, JVM software > running in interpreted mode or JVM software using JIT compiler. > > In principle it is not different from what we call a native > image. A native image can run on the CPU it was targeted > at or it can run in a hardware simulator emulating that CPU. > Only you and Lew would think it's not different from a native image. > There is a practical difference in that in the real world Java > is always run in a software JVM and native image is almost always > run on its matching CPU. > Exactly - and that is a huge difference. And a CPU emulator runs ANYTHING compiled for that CPU - not just Java programs. That is a huge difference than a jvm running bytecode. But once again, one you are too stoopid to understand. >>> The terms compiled language and interpreted language are very fuzzy. >> >> Only to you, Arne. To most programmers, the terms are perfectly clear. > > Really. > > I thought most programmers were aware that you can create both > compilers and interpreters for most (all?) languages. > > Arne > > Yes, only to you. Sure, you can create both compilers and interpreters for most languages. But that does not mean the terms are fuzzy. It's all in the output. -- ================== 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:10 -0400 |
| Message-ID | <muv721$95t$1@speranza.aioe.org> |
| In reply to | #32785 |
On 10/3/2015 10:57 AM, Jerry Stuckle wrote: > On 10/2/2015 10:36 PM, Arne Vajhøj wrote: >> On 9/27/2015 11:05 PM, Jerry Stuckle wrote: >>> On 9/27/2015 8:54 PM, Arne Vajhøj wrote: >>>> On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: >>>>> On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins >>>>> wrote: >>>>>> Would it be fair for an instructor of early students of Java to >>>>>> state that Java source code is compiled to bytecode that is in turn >>>>>> interpreted by a Java virtual machine. >>>>> >>>>> I've always heard Java is an interpreted language, because it cannot >>>>> run by itself. A system must have Java installed to run it and that >>>>> Java install has different interpretations for the same code to run >>>>> on Windows or Mac or Linux. >>>> >>>> A native executable requires a CPU. >>>> >>>> Java byte code requires a JVM. >>>> >>>> Remember that VM mean Virtual Machine. >>> >>> So Java does not require a CPU. ROFLMAO! >> >> Java byte code requires a JVM. >> >> I am not aware of any JVM implementation that does not use a CPU. >> > > Ah, but you said "native executable requires a CPU" and "Java byte code > (sic) requires a JVM". By deduction, you are saying Java bytecode (the > correct spelling) does not require a CPU. You deduction is hopeless flawed. >> But the point is that Java byte code only cares about the JVM >> interface. >> >> It does not care about whether it is JVM hardware, JVM software >> running in interpreted mode or JVM software using JIT compiler. >> >> In principle it is not different from what we call a native >> image. A native image can run on the CPU it was targeted >> at or it can run in a hardware simulator emulating that CPU. > > Only you and Lew would think it's not different from a native image. It does require a certain ability to understand abstract concepts, but we are not the only ones. >>>> The terms compiled language and interpreted language are very fuzzy. >>> >>> Only to you, Arne. To most programmers, the terms are perfectly clear. >> >> Really. >> >> I thought most programmers were aware that you can create both >> compilers and interpreters for most (all?) languages. > > Yes, only to you. Sure, you can create both compilers and interpreters > for most languages. But that does not mean the terms are fuzzy. It's > all in the output. That is the point. A language is not either a compiled language or an interpreted language. It is only one or another in a specific environment/tool set context. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-05 21:27 -0400 |
| Message-ID | <muv7u0$act$2@dont-email.me> |
| In reply to | #32806 |
On 10/5/2015 9:10 PM, Arne Vajhøj wrote: > On 10/3/2015 10:57 AM, Jerry Stuckle wrote: >> On 10/2/2015 10:36 PM, Arne Vajhøj wrote: >>> On 9/27/2015 11:05 PM, Jerry Stuckle wrote: >>>> On 9/27/2015 8:54 PM, Arne Vajhøj wrote: >>>>> On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: >>>>>> On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins >>>>>> wrote: >>>>>>> Would it be fair for an instructor of early students of Java to >>>>>>> state that Java source code is compiled to bytecode that is in turn >>>>>>> interpreted by a Java virtual machine. >>>>>> >>>>>> I've always heard Java is an interpreted language, because it cannot >>>>>> run by itself. A system must have Java installed to run it and that >>>>>> Java install has different interpretations for the same code to run >>>>>> on Windows or Mac or Linux. >>>>> >>>>> A native executable requires a CPU. >>>>> >>>>> Java byte code requires a JVM. >>>>> >>>>> Remember that VM mean Virtual Machine. >>>> >>>> So Java does not require a CPU. ROFLMAO! >>> >>> Java byte code requires a JVM. >>> >>> I am not aware of any JVM implementation that does not use a CPU. >>> >> >> Ah, but you said "native executable requires a CPU" and "Java byte code >> (sic) requires a JVM". By deduction, you are saying Java bytecode (the >> correct spelling) does not require a CPU. > > You deduction is hopeless flawed. > Not at all. But your English is hopelessly flawed. >>> But the point is that Java byte code only cares about the JVM >>> interface. >>> >>> It does not care about whether it is JVM hardware, JVM software >>> running in interpreted mode or JVM software using JIT compiler. >>> >>> In principle it is not different from what we call a native >>> image. A native image can run on the CPU it was targeted >>> at or it can run in a hardware simulator emulating that CPU. >> >> Only you and Lew would think it's not different from a native image. > > It does require a certain ability to understand abstract concepts, > but we are not the only ones. > An ability you do not have. >>>>> The terms compiled language and interpreted language are very fuzzy. >>>> >>>> Only to you, Arne. To most programmers, the terms are perfectly clear. >>> >>> Really. >>> >>> I thought most programmers were aware that you can create both >>> compilers and interpreters for most (all?) languages. >> >> Yes, only to you. Sure, you can create both compilers and interpreters >> for most languages. But that does not mean the terms are fuzzy. It's >> all in the output. > > That is the point. > > A language is not either a compiled language or an interpreted > language. > > It is only one or another in a specific environment/tool set > context. > > Arne > That is correct. And Java by default is converted to bytecode, which is interpreted. But I know such a concept is beyond your simple mind's comprehension, as you have repeatedly proven. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-27 23:19 -0400 |
| Message-ID | <muabg6$iho$1@dont-email.me> |
| In reply to | #32687 |
On 9/25/2015 8:20 AM, e.d.programmer@gmail.com wrote: > On Thursday, September 24, 2015 at 10:32:45 PM UTC-4, Jeff Higgins wrote: >> Would it be fair for an instructor of early students of Java >> to state that Java source code is compiled to bytecode that is >> in turn interpreted by a Java virtual machine. > > I've always heard Java is an interpreted language, because it cannot run by itself. A system must have Java installed to run it and that Java install has different interpretations for the same code to run on Windows or Mac or Linux. > That is correct. The Java compiler generates intermediate code which is then converted to machine language (interpreted) by the jvm. > That may be confusing because it is such a high level language that it has a compile step which produces a .class file that is not human readable, but also means nothing to the OS without a Java install. Compiled code creates .exe files on Windows which can run without installing a separate application. A mainframe wouldn't use the .exe extension but would run COBOL as compiled code. > Yes, but "compiler" is really an incorrect term. I think "translator" is more accurate, since the "compiler" doesn't produce machine code. > Javascript is truly interpreted code since it runs as the source text and requires an interpreter for each OS. VB Script runs as the source text though it is Windows specific.. > That is true. > Is Android Java considered compiled code? It doesn't require a separate install for the interpreter, it just created .apk files which are run directly by the Java based OS. > Not really. The .apk file is still not machine-readable; Android contains the equivalent of a jvm to process the .apk file. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Eternal Hope <laughingspam99@gmail.com> |
|---|---|
| Date | 2015-09-25 03:46 +0100 |
| Message-ID | <mu2cdf$i8a$1@dont-email.me> |
| In reply to | #32655 |
On 24/09/2015 21:58, 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 mean 'object code' I guess don't you as in the .o files produced when you compile C code but omit the linking phase ... details, the object code produced is exactly as machine specific as the resulting 'fixed up' eventual executable code, you should know this, I suspect you do. > 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? Everything eventually relies on the microcode doedn't it RISC or CISC, what's executed *in* the processor is always microcode*, that's what processors do, execute microcode, using your argument everything and anything that isn't microcode stored in ROM 'in' the processor is interpreted. [*prehistoric oddities notwithstanding] > 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? Is the emulator capable of being ru on the hardware of a different architecture without being re-compiled > 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. The only thing that's blurred here is the obfuscation emitted by your pre-processor :-) -- Laughing Spam Fritter
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-24 23:35 -0400 |
| Message-ID | <mu2fe0$s21$1@speranza.aioe.org> |
| In reply to | #32652 |
On 9/24/2015 3:10 PM, 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. >>>> >>>> "Technically" Java is a compiled language. >>> >>> Ambiguous. >> >> FWIW, my take on it is that a language that can be run without a separate >> compilation step is interpreted (bash scripts, Perl, awk, BASIC) while >> 'compiled' languages always involve a separate compilation step, before >> they can be run. > > 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. > > Anything else wasn't and isn't > > A Java compiler takes source code as input and produces output that > 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. > Thank god for the gcc compiler and the Linux kernel :-) > That is still the compiler of choice isn't it? What do you call cc1? :-) Arne
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web