begin quoting Wade Curry as of Tue, Aug 22, 2006 at 03:48:09PM -0700: > Stewart Stremler([EMAIL PROTECTED])@Tue, Aug 22, 2006 at 11:24:46AM -0700: [snip] > > I can see an interpreted language parsing, tokenizing, and indexing, > > all without ever compiling anything. > > > This is a direct result of my own misperceptions. I was under the > impression that interpreters converting the code into some kind of binary > representation on the fly.
That would be a Just In Time compiler. :) > Now I have to ask what exactly is entailed in > interpreting/compiling code? Specifically, what distinguishes > them with respect to how the code is handled? This is where languages like Java confuse things. It "compiles" to bytecode, while GCC "compiles" to machine code. Think of compiling as translating the program to a non-human-readable format. And interpreting is a program "running" the program by looking at the source. > > I'm trying to think of what languages might do that. Smalltalk? > > Lisp? > > > > Python was what I had in mind. Run a python program and it will > leave a .pyc and/or .pyo file behind (my recollection is fuzzy). > Doesn't perl do something similar as well? Dunno. Sounds like something that I'd get annoyed at. > > Java gets compiled (i.e., transformed) into bytecode, which is a > > binary intermediate format, which then gets interpreted; Sun's > > JIT takes the bytecode and further translates it into the local > > hardware's machine instructions. > > Hmm... I'm thinking that you meant to say that the *JVM* does > further translation. If that's not what you meant, then I'm at a > loss. I thought the JIT was used in place of the regular compiler > so that the byte code was created just before the JVM ran it. The JVM "runs" the bytecodes. The JIT translates the bytecodes into machine code that can run directly on the processor. Neither the JVM nor the JIT does anything with source code -- they act only on bytecode. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
