On 02/03/2010 07:20 AM, Carlos Konstanski wrote: > An interpreted language does all the work of translating the > high-level, complex, abstract programming statements written in a > human-readable language into machine code (the only kind of code a > computer can_actually_ execute) at runtime, right when a result is > needed. A compiled language translates the human-written source code > into machine code beforehand, so that at runtime the computer can > execute the ready-made machine code hell-bent-for-leather. > > There is an in-between compromise called bytecode. Languages like java > and C# are not compiled into directly executable machine > code. Instead, they are compiled into a form that is still interpreted > at runtime, but it is highly optimized to interpret very > quickly. These languages use a virtual machine, or "runtime", to > "execute" the bytecode. What the runtime actually does is read > segments of bytecode and compile them into real machine code on the > fly, the results generally not being stored on disk. This is where we > get the term "Just In Time Compilation", or JIT. > > An interpreted language will always run more slowly than a compiled > language because of all the extra work that has to be done at > runtime. There may be some oddball cases like TinyBasic, but we're > talking about high-level application programming languages here. >
Lovely clear explanation, Carlos. The only thing i'd add is the relatively recent addition of support for typically interpreted languages (e.g., Python, Ruby) on both the Java Virtual Machine and the .NET Common Language Runtime. This approach is a great middle ground that provides the usability/development efficiency of higher-level "scripting" languages with the performance of bytecode compilation and the safety/security/sandboxing (somewhat debatable but generally better than the default interpreters) of the JVM and CLR. In larger enterprises, this approach also allows standard deployment and management (i.e. as .NET or Java EE applications) on existing server infrastructure - the operations teams don't need to deal with another platform, even though the application code is written in JRuby or Iron Python. Given that CPU cycles are far cheaper than developers and operations staff, the productivity/performance tradeoff of higher-level languages is a no-brainer for most businesses. BTW, your initial remark, "don't engineer your software better, instead make your crap execute faster. Oracle might be interested in this," had me laughing out loud. Joe _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
