LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 02-28-2013, 05:52 PM   #1
lukesodre
LQ Newbie
 
Registered: Feb 2013
Posts: 1

Rep: Reputation: Disabled
Compilers vs Interpreters


What are the characteristics of a language that dictate that it must be compiled or interpreted?


I'd like to know more about the language itself, independent of the use
 
Old 02-28-2013, 07:12 PM   #2
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,788

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
There is absolutely no quality of any programming language that would determine whether it must be interpreted or compiled.

Last edited by dugan; 02-28-2013 at 07:13 PM.
 
Old 02-28-2013, 08:47 PM   #3
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 584
Blog Entries: 2

Rep: Reputation: 76
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.

Last edited by psionl0; 02-28-2013 at 08:48 PM.
 
Old 03-01-2013, 04:54 AM   #4
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,827

Rep: Reputation: 507Reputation: 507Reputation: 507Reputation: 507Reputation: 507Reputation: 507
Eg, if the language has a PHP-like eval function, it hardly can be compiled.
 
Old 03-01-2013, 07:00 AM   #5
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,301

Rep: Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037
You might find this interesting http://www.perl.com/doc/FMTEYEWTK/comp-vs-interp.html
 
Old 03-01-2013, 09:33 AM   #6
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,788

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
Quote:
Originally Posted by NevemTeve View Post
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.

Last edited by dugan; 03-01-2013 at 09:43 AM.
 
Old 03-01-2013, 09:57 AM   #7
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,290

Rep: Reputation: 174Reputation: 174
Quote:
Originally Posted by dugan View Post
CoffeeScript is compiled just to JavaScript
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.
 
Old 03-01-2013, 11:19 AM   #8
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,788

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
Quote:
Originally Posted by bigearsbilly View Post
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.

Last edited by dugan; 03-01-2013 at 11:44 AM.
 
Old 03-01-2013, 11:45 AM   #9
orgcandman
Member
 
Registered: May 2002
Location: dracut MA
Distribution: Ubuntu; PNE-LE; LFS (no book)
Posts: 594

Rep: Reputation: 102Reputation: 102
Quote:
Originally Posted by psionl0 View Post
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 View Post
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?
 
Old 03-01-2013, 11:49 AM   #10
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,788

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
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.
 
Old 03-01-2013, 11:57 AM   #11
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,401

Rep: Reputation: 1120Reputation: 1120Reputation: 1120Reputation: 1120Reputation: 1120Reputation: 1120Reputation: 1120Reputation: 1120Reputation: 1120
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.
 
Old 03-01-2013, 12:07 PM   #12
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,788

Rep: Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486Reputation: 1486
Quote:
Originally Posted by sundialsvcs View Post
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.

Last edited by dugan; 03-01-2013 at 12:15 PM.
 
Old 03-01-2013, 12:34 PM   #13
bigearsbilly
Senior Member
 
Registered: Mar 2004
Location: england
Distribution: FreeBSD, Debian, Mint, Puppy
Posts: 3,290

Rep: Reputation: 174Reputation: 174
Interesting, I wouldn't have thought of a half-baked language that outputs a human readable script as compiled.
You learn something new every day.

I am enlightened.

I might replace C with it at work.
:-)
 
Old 03-01-2013, 06:32 PM   #14
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 584
Blog Entries: 2

Rep: Reputation: 76
Quote:
Originally Posted by orgcandman View Post
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.
 
Old 03-04-2013, 08:28 AM   #15
orgcandman
Member
 
Registered: May 2002
Location: dracut MA
Distribution: Ubuntu; PNE-LE; LFS (no book)
Posts: 594

Rep: Reputation: 102Reputation: 102
Quote:
Originally Posted by psionl0 View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How do interpreters work? TheIndependentAquarius Programming 7 12-28-2012 01:14 PM
Programming languages built into mainstream distros with interpreters (like Python) Blackened Justice Linux - Newbie 4 07-31-2011 06:37 PM
LXer: Perl 6 to break compatibility, support other interpreters LXer Syndicated Linux News 0 12-07-2008 09:00 AM
FREE Compilers and Cross-Compilers for LINUX and WINDOWS. Bernstein34 Linux - Software 1 05-05-2008 12:54 PM


All times are GMT -5. The time now is 02:24 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration