Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If we look at the major programming languages in use today it is pretty noticeable that the vast majority of them are, in fact, interpreted.

Looking at the largest piece of the pie we have Java and C# which are both enterprise-ready, heavy-duty, serious programming languages which are basically compiled to byte-code only to be interpreted by their respective VMs (the JVM and the CLR).

If we look at scripting languages, we have Perl, Python, Ruby and Lua which are all interpreted (either from code or from bytecode - and yes, it should be noted that they are absolutely not the same).

Looking at compiled languages we have C which is nowadays used in embedded and low-level, real-time environments, and C++ which is still alive and kicking, when you want to get down to serious programming as close to the hardware as you can, but still have some nice abstractions to help you with day to day tasks.

Basically, there is no real runner-up compiled language in the distance.

Do you feel that languages which are natively compiled to executable, binary code are a thing of the past, taken over by interpreted languages which are much more portable and compatible? Does C++ mark an end of an era?

Why don't we see any new compiled languages anymore?


I think I should clarify: I do not want this to turn into a "which language is better" discussion, because that is not the issue at hand. The languages I gave as example are only examples. Please focus on the question I raised, and if you disagree with my statement that compiled languages are less frequent these days, that is totally fine, I am more than happy to be proved mistaken.

share|improve this question

migrated from stackoverflow.com Feb 27 '11 at 23:55

This question came from our site for professional and enthusiast programmers.

closed as primarily opinion-based by gnat, GlenH7, MichaelT, Dan Pichelman, mattnz Aug 25 '13 at 8:59

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
+1 dunno why everyone down voted this question –  Element Mar 9 '09 at 22:16
30  
Because the question doesn't make any sense: there is no such thing as a "compiled language" or "interpreted language". Whether a language implementer chooses to write a compiler, an interpreter or anything in between is an implementation detail and has nothing to do with the language. –  Jörg W Mittag Mar 9 '09 at 22:56
11  
There are compiled implementations of Python, JavaScript, Ruby, PHP, Lisp, Scheme and Smalltalk and there are interpreted implementations of C and C++ –  Jörg W Mittag Mar 9 '09 at 22:57
    
Do you have a source for this pie chart? –  jdizzle Aug 5 '10 at 17:13
1  
Google-Go seems to be a compiled example. –  Elazar Leibovich Aug 5 '10 at 18:50

7 Answers 7

What about Delphi?

As a language that produces native 32 (and soon 64bit) applications it's pretty hard to go past.

It's continuing to be developed, it's constantly getting new modern features, things like Generics, anonymous methods (pre-cursor to Lamba expressions perhaps?) etc..

IMO, having a managed language like C#, or Java plus a scripting language (insert your favourite here) plus a native code language like Delphi or C++, you are set for any requirement.

share
locked by Community Aug 25 '13 at 8:59
    
I agree Delphi 7 was quite impressive for its time, it had much of the functionality that microsoft would later release with its .net languages but compiled to native win32 code. –  Element Mar 9 '09 at 22:24

Well, according to various benchmarks you can find on the Internet, interpreted languages still don't quite deliver the same performance characteristics as compiled ones. So I would say no, not yet.

(Just for the record, you shouldn't mix bytecode compiled environments with interpreted environments - there is a HUGE difference)

share
locked by Community Aug 25 '13 at 8:59
    
I totally agree that they are not the same, I am just pointing at a lack of languages which compile to executable, binary code. –  Yuval A Mar 9 '09 at 22:05
    
+1: VMs != interpreted. JITters still compile down to machine code at runtime. –  Dave Mar 9 '09 at 22:24
    
Your answer doesn't make any sense: there is no such thing as a "compiled language" or "interpreted language". Whether a language implementer chooses to write a compiler, an interpreter or anything in between is an implementation detail and has nothing to do with the language. –  Jörg W Mittag Mar 9 '09 at 22:57
    
Jörg W Mittag: I think you are nitpicking here. I think you exactly understand what I meant. An interpreted language is a programming language that is generally not compiled to machine code or byte code. –  Tamas Czinege Mar 10 '09 at 10:26

C# is not an interpreted language - it is JIT compiled to native code. As are many other CLR languages such as VB.NET and F# (I say 'many other' rather than 'all other' as I'm not familiar enough with the DLR architecture to know whether DLR languages are interpreted on top of the CLR). So given that there are a number of widely used compiled languages, no I don't think compiled languages are a thing of the past.


Note: While Jorg is technically correct that a language is neither compiled nor interpreted as this is an implementation detail, the terms "compiled language" and "interpreted language" are common use when talking about a language and its de-facto execution context. I'm assuming that the common use of the terms is what is implied by the question, and for comprehensibility I have used the same terminology in my answer.

share
locked by Community Aug 25 '13 at 8:59
    
I've heard this before, but why should it be compiled each time it runs by the JIT? Why do the compilation the JIT did is not persistent? –  OscarRyz Mar 9 '09 at 22:32
    
You can do exactly this with NGEN. The following page has some info about the pros and cons: msdn.microsoft.com/en-us/library/6t9t5wcf.aspx –  Greg Beech Mar 9 '09 at 22:42
1  
Your answer doesn't make any sense: there is no such thing as a "compiled language" or "interpreted language". Whether a language implementer chooses to write a compiler, an interpreter or anything in between is an implementation detail and has nothing to do with the language. –  Jörg W Mittag Mar 9 '09 at 22:59
    
@Oscar Reyes: because if you delay compilation as much as possible, the optimizer has much more information to work with – information about how exactly the program behaves at runtime, for this particular workload. That's why modern JVMs beat C in benchmarks, for example. –  Jörg W Mittag Mar 9 '09 at 23:01
    
Most DLR languages have a compiler: they compile to DLR trees and then there is an aggressively optimizing compiler built into the DLR that compiles DLR trees to CIL bytecode. However, many languages alternatively also have an interpreter, because for code that is seldomly executed, interpreting is –  Jörg W Mittag Mar 9 '09 at 23:26

Simple answer: no. Of course not.

Firstly I disagree with your assertion that "the major programming languages in use today it is pretty noticeable that the vast majority of them are, in fact, interpreted" ... I suppose in terms of number-of-languages-created-in-the-last-10-years you'd be right, but in terms of developer hours/year I would be shocked if development in interpreted languages vastly surpassed development in compiled languages.

Secondly, most work is maintaining existing projects. For a long time we'll be fixing and improving the projects that are out there in C, C++, Delphi, etc. Not developing those skills because you believe they're dying would be, in my opinion, career suicide.

Lastly, compiled code and interpreted code each have their place. Need to write a fast fresh UI? C/C++ is a terrible choice. Need to write a realtime device driver? Java is a terrible choice.

share
locked by Community Aug 25 '13 at 8:59
1  
People have been writing real-time device drivers in Java just fine, and in Smalltalk before that and in Lisp before C was even invented and many StackOverflow users were born. I would go so far and say that writing a real-time device driver in a weakly-typed language like C is a terrible choice. –  Jörg W Mittag Mar 9 '09 at 23:05
1  
I don't think that's his point here. The point is that languages in general have their own purpose. Not necessarily deriving that purpose from their mode of interpretation or implementation. –  jphenow Aug 10 '10 at 5:09

I'm not sure I see your criteria for determining "runner-up". One category includes a seemingly arbitrary number of interpreted and just-in-time compiled languages, new and old, widely and rarely used, in a big mix. The other includes C and C++.

What would it take for you to consider a compiled language a "runner-up"? Why were the languages you mentioned as interpreted included for consideration, but other compiled languages were not? While I think it's obvious that for many purposes, interpreted or JIT'ed languages are more productive to work with than compiled ones, I really don't understand the argument you're trying to make.

Your question seems to be why there are no new compiled languages coming out. And then as part of your proof that interpreted is more common, you include Perl, which is, well, ancient. Why? As an aside, do new revisions of existing languages count as "new"? If so, how about C++0x?

And of course many, if not most, languages can be compiled to either native machine code or bytecode of some kind. .NET languages can be compiled with ngen to produce a native image. C++ can be compiled to Flash bytecode, and run in your browser! Java can be compiled to machine code as well. So what exactly is "a compiled language"?

share
locked by Community Aug 25 '13 at 8:59
    
I agree 100%. Whether an implementation uses a compiler or interpreter or something in between is an implementation detail and completely independent of the language. There are interpreters for C, for example, and there's several discussions about those on StackOverflow. –  Jörg W Mittag Mar 9 '09 at 23:13

No. Two comments:

  1. Looking at the largest piece of the pie we have Java and C# which are both enterprise-ready, heavy-duty, serious programming languages which are basically compiled to byte-code only to be interpreted by their respective VMs (the JVM and the CLR).

    JIT Compilation is NOT interpretation. If you remember the early days of Java, people found it to be very (if not unacceptably) slow. It was still a nice environment to program in, and it was portable for simple applications, but I claim that a huge part of what makes Java and C# so widespread today is the success of JIT compilers on the server-side.

    You wouldn't see Java and C# scaling to run on large enterprise systems without the work of all those JIT engineers. Also, look at the lengths that people go to to get JIT-level performance for their various interpreted languages. Python files are compiled to bytecode and potentially optimized. JRuby takes advantage of Java JITs. None of those interpreted languages you cited are really so interpreted either.

  2. Why don't we see any new compiled languages anymore?

    Don't assume your domain is representative. I realize that most people on here do business programming. But, in other domains there are lots of other languages, not nearly all of which are interpreted.

    In High-Performance Computing, there's been an ongoing language implementation competition put on by DARPA to create High Productivity Computer Systems. Out of this came not one but three new compiled languages:

    1. X10
    2. Chapel
    3. Fortress

    Most of these are geared towards effective ways to write parallel programs for very large, parallel computers. This is a field where every ounce of performance still counts, noise (from VMs, OSs, etc) matters, and no one would dream of starting up a C# or Java VM on their compute cluster (caveat: X10 is based on Java -- but it's tuned).

    Similarly, there have been other relatively recent attempts at Partitioned Global Address Space languages, many of which are actively developed and used:

    And then there are tons of other parallel and/or functional compiled languages:

    Seriously. Don't fall into the "no one in my domain does X so X must be dead!" trap. There are tons of good things about moving towards scripting languages, managed runtimes, and all the other rapid development techniques used in business computing, but remember that there are other domains that require other solutions before you make these kinds of blanket assertions.

share
locked by Community Aug 25 '13 at 8:59
4  
Again: there is no such thing as a compiled language, that's an implementation detail. Case in point: the first implementation of Fortress was an interpreter. Yet, it's still the same language. –  Jörg W Mittag Mar 9 '09 at 23:17
9  
Quit nitpicking. See en.wikipedia.org/wiki/Compiled_language. Notice judicious use of "typically" in first sentence. –  tgamblin Mar 9 '09 at 23:19
4  
You cited Fortress as an example of a compiled language. Yet, 50% of Fortress implementations are interpreted. In contrast, 9 out of 9 Python implementations, 13 out of 14 Ruby implementations, several JavaScript implementations, most Scheme implementations have compilers. How many is "typically"? –  Jörg W Mittag Mar 9 '09 at 23:33
3  
Read the Fortress spec. One of the key design goals was to allow compiler optimizations across library boundaries. It is DESIGNED to be compiled. There is only a reference interpreter because their DARPA contract was not renewed. –  tgamblin Mar 9 '09 at 23:50
4  
the big contribution of this answer is "look beyond your desk", not the language enumeration. we all agree that C is 'more compiled' than Python or Java. –  Javier Mar 10 '09 at 17:38

Device drivers and OSs aren't the only places for hardcore compiled languages: most GUI frameworks these days are clunky and slow because they're implemented mostly in the bytecoded language it supports: neither Java nor C# GUI frameworks can hold a dim candle to Qt. even wx is snappier in most setups.

bytecodes and JITs are great; but as soon as you move out of their zone of comfort, you have to go compiled.

another good example: Clojure. it targets the JVM, so it's crippled. a real LISP compiler goes either to its own bytecode or to machine code. that simply means that there's no 'universal bytecode' unless you argue that x86 is today's VM

share
locked by Community Aug 25 '13 at 8:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.