ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It's pretty much a choice. You can have interpreters that read source code and execute on the fly (BASIC was one of the earliest examples) or compilers/linkers that convert source code into machine code that can be loaded and executed directly by the CPU. Then there are intermediate examples like Java which compile the source code into a byte code which must be read by an interpreter. Of course, there are compilers that will convert source code intended for an interpreter into executable machine code (though it can be difficult to make them work properly sometimes).
The main advantage of compiled languages is speed of execution and the fact that you don't need to install special interpreting software to run the program but it can be a more difficult path from source to executable.
Eg, if the language has a PHP-like eval function, it hardly can be compiled.
CoffeeScript is compiled (just to JavaScript, not to to assembly). It has eval (which compiles directly into JavaScript's eval statement). CoffeeScript is a compiled language whose eval statement evals the language that it compiles to.
So it is still an interpreted language, not what is generally understood as compiled.
It doesn't run on bare metal.
I wouldn't really count it as a language if it renders down to javascript.
So it is still an interpreted language, not what is generally understood as compiled.
CoffeeScript is compiled to an interpreted language, but it's not an interpreted language itself. This is consistent with the correct definitions of a compiler and an interpreter.
Quote:
I wouldn't really count it as a language if it renders down to javascript.
This brings up the question of "what is a programming language." Which I'm not prepared to answer.
The main advantage of compiled languages is speed of execution and the fact that you don't need to install special interpreting software to run the program but it can be a more difficult path from source to executable.
This is not true. "Speed of execution" has more to do with optimization and code structure than which particular language one uses. In fact, it's possible to write software which amortized over time yields faster execution than 'native' code, since the interpreter can peek into which branches are actually being taken. GCC/G++ have a heuristics pass that most people aren't even aware exists which can take this information and produce 'faster' code, as well. I'll still counter with proper coding is always faster than improper, except in very specific and naive cases.
Quote:
Originally Posted by bigearsbilly
It doesn't run on bare metal.
What does that even mean? I can assure you, that all of the software running on your computer is actually running on your computer. If you want to say "Well, it's not being executed by the chip" my only counter is "Neither is x86/x86_64" since the microcode actually being 'run' is risc-like. What is bare metal? What about virtual machines? just-in-time compilation?
@OP:
This is generally a gray area that tends to devolve into flame-wars, trolling, and semantic arguments.
Does it matter than a front-end produces code in x86 bytes vs. say shockwave bytes?
The answer the OP most likely wanted to hear is that statically typed languages are more likely to be implemented as compiled, and weakly typed languages are more likely to be implemented as interpreted. Note the precision in my wording. Of course, Googling for "C interpreter" shows exceptions to this immediately.
Even traditional compilers provide the feature of generating "p-code," for all or part of the program. This is then interpreted at run-time by a short embedded program.
This notion has a long history. When Steve Wozniak was designing the venerable Apple ][, and cramming Integer Basic into that ROM, he invented a p-machine called "Sweet16" to significantly reduce the size of the Integer Basic code at a basically-inconsequential difference in speed.
So, the pragmatic distinction between the two technologies is much more blurry and indistinct than you might suppose. Sometimes the "target" is directly executable machine-code (a classic "compiler"); sometimes it is a data-structure (a classic "interpreter"); but very often it is both at once. At the end of the day, there's actually not too much "versus" about it!
Last edited by sundialsvcs; 03-01-2013 at 11:59 AM.
Even traditional compilers provide the feature of generating "p-code," for all or part of the program. This is then interpreted at run-time by a short embedded program.
And, highly relevant to a point that was brought up earlier, this is exactly how PHP works.
FaceBook also, famously, uses an actual PHP-to-machine-code compiler.
This is not true. "Speed of execution" has more to do with optimization and code structure than which particular language one uses. In fact, it's possible to write software which amortized over time yields faster execution than 'native' code, since the interpreter can peek into which branches are actually being taken. GCC/G++ have a heuristics pass that most people aren't even aware exists which can take this information and produce 'faster' code, as well. I'll still counter with proper coding is always faster than improper, except in very specific and naive cases.
Code which has to be fed into other code which then produces machine code that is executed by the CPU can not by definition be faster than code which can be executed directly by the CPU. Your re-definition of "compiled" only hides this point.
It is true that modern optimizing compilers can produce code that runs faster than that produced by the average assembly language programmer but that doesn't prove that interpreted code is faster than compiled code.
Code which has to be fed into other code which then produces machine code that is executed by the CPU can not by definition be faster than code which can be executed directly by the CPU. Your re-definition of "compiled" only hides this point.
I'm unaware that I've redefined anything. I took your implied definition of 'interpreted' meaning a virtual machine which executes the software. I said nothing of 'compiled'.
Additionally, your first sentence doesn't even make sense. What 'code' is 'directly executed' by your CPU? What does 'directly executed' mean? You are attempting to set me up as disagreeing with you. I'm doing neither. I'm merely pointing out that there are problems trying to blanket statement anything as "faster" when it comes to execution time, and that proper coding is always better than a perceived optimization which obscures the code. I can speak more to this, including pointing out various benchmarks and optimization studies which show that there is no difference in execution times depending on the data structures, algorithms, and machines being used to execute say C++ vs Java vs C. It is certainly a great way for people to generate white papers.
Anyway, this discussion boils down to building a theoretical construct that may being used as a lens to analyze development methods. While that can be useful for someone, my own thought on the matter is that this discussion typically gets people riled up and doesn't really help anyone TODAY. Maybe in the future such a discussion will have many merits, but even today we can't agree what is an interpreter, compiler, virtual machine, actual machine, etc. For any definition you give, I'll bet I can find a way to make something from a different category fit (that's not a challenge).
I could write on this topic for a long time, but at this point I've said enough of my piece. You can choose to take the time and understand what I'm writing, or you can continue to believe that I'm redefining things and trying to prove that something is 'faster' than something else.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.