Tell me more ×
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.
up vote 6 down vote favorite
1

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
1  
+1 dunno why everyone down voted this question – Element Mar 9 '09 at 22:16
28  
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
show 5 more comments

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

14 Answers

up vote 84 down vote

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|improve this answer
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
show 3 more comments
up vote 12 down vote

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|improve this answer
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
up vote 8 down vote

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|improve this answer
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. – DrJokepu Mar 10 '09 at 10:26
up vote 6 down vote

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

What about D?

share|improve this answer
Yes, I do agree D is a good answer, but do you see it playing a major in the upcoming years? – Yuval A Mar 9 '09 at 22:33
2  
I think if D were specified by a standard and not just Walter Bright it would catch on a lot faster. Also, if it had more support from current (open source? Maybe? Please?) compilers like GCC - I know there is a D front-end, but it's not part of the default release, probably since it's experimental. – Chris Lutz Mar 9 '09 at 22:43
It is unfortunately not. At least not yet. – Burkhard Mar 9 '09 at 23:02
up vote 6 down vote

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|improve this answer
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
show 1 more comment
up vote 5 down vote

If you want to know whether or not compiled languages are on the way out, write an operating system in Python and get back to me. </snark>

share|improve this answer
There was the Unununium project, but they wrote their lowest level code in Assembler instead of Python, which probably lead to their demise. But there's enough examples of Lisp and Smalltalk Operating Systems, that don't contain any traces of assembly or C. – Jörg W Mittag Mar 9 '09 at 23:15
1  
Even for Lisp or Smalltalk OSes, you still need something to run the Lisp and Smalltalk code. My x86 doesn't run Lisp natively, so we either need an interpreter as part of this OS, or a compiler that translates the code to machine code. – Chris Lutz May 11 '09 at 20:04
up vote 4 down vote

OCaml, ATS, BitC, Haskell?

share|improve this answer
And which one of those can you even remotely call "popular"? – Yuval A Mar 9 '09 at 22:32
4  
The question was about future languages. A language cannot be both popular and new. – Jörg W Mittag Mar 9 '09 at 23:07
ATS and BitC are quite new. OCaml is certainly remotely popular. – MichaelGG Mar 9 '09 at 23:32
1  
MS hiring him sounds like a potentially very good thing :). – MichaelGG Apr 6 '09 at 20:59
1  
Shapiro has since left Microsoft and resumed work on BitC. – Edward Kmett Aug 5 '10 at 17:11
show 1 more comment
up vote 4 down vote

What do we suppose the JVM, the CLR, and the other environments that scripted or interpreted languages use are written in? We're always going to need compiled languages.

share|improve this answer
1  
Many Lisp implementations are written 100% in Lisp, some Smalltalk implementations are written 100% in Smalltalk, some JavaScript, Ruby and Python implementations are written 50%-90% in themselves. – Jörg W Mittag Mar 9 '09 at 23:22
Just because Sun bought a Smalltalk VM written in C++ and released it as a JVM doesn't mean one couldn't write a JVM in Python. In fact, I believe someone wrote a JVM in Ruby, just for fun. Also, there's a Ruby VM written in JavaScript. – Jörg W Mittag Mar 9 '09 at 23:24
2  
You're both missing the point. Even if you were to write a VM in Ruby or Python, it would have to go through the Ruby or Python interpreter, which has to be compiled. Interpreted languages cannot exist without compiled ones, unless there is a hardware equivalent of the interpreter. Do you have a Ruby chip in your PC? – ithcy Aug 5 '10 at 19:28
up vote 2 down vote

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|improve this answer
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
up vote 2 down vote

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|improve this answer
up vote 1 down vote

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|improve this answer
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
up vote 1 down vote

Compiled languages are still useful where performance and limited resources are concerned.

For instance Python is an interpreted language but I was recently reading an article on highscalability.com where they were discussing youtube's architecture, which is written in python, they mentioned all the resource intensive bits were still written in macros or c extensions to improve efficiency, so in that regard I don't think compiled languages will ever die, they will always be used for cutting edge development that is pushing the limits of current hardware.

share|improve this answer
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 23:09
Python, in particular has multiple compiled implementations: Shedskin, for example. – Jörg W Mittag Mar 9 '09 at 23:10
up vote 0 down vote

Let's all remember that compiling is an optimization. If it weren't for performance, interpreted languages hold all of the advantages. My thoughts are we need to remove the concept of optimization from the end user and hide it from them.

So to answer your question, YES

I believe we can design a new language that seems to be interpreted, but performs just as fast as any compiled language. The trick here is the language will simply compile JIT from source code. Our computers are fast enough to do this now. There will be huge hurdles to achieve this. Firstly the compilation/link/build step cannot require any configuration. Any configuration will allow for misconfiguration which would lead to programs "not running". Any sort of configuration will need to be built into the source or "project" files. All these files will be placed in an executable container.

share|improve this answer
Clojure never interprets, it always compiles to JVM bytecode. Google's V8 JavaScript engine never interprets, it always compiles to machine code – first a fast compiler that produces slow code, then, when a method gets executed multiple times, it gets compiled again with a much slower but more ... – Jörg W Mittag Mar 9 '09 at 23:51
... aggressively optimizing compiler. In fact, the compiler is so aggressive that it sometimes makes guesses. And when it guesses wrong, well, the slow but correct code is still there. – Jörg W Mittag Mar 9 '09 at 23:52
up vote 0 down vote

As long as speed and security matters then compiled languages will always have the edge. Can't see any interpreted operating systems or real time banking systems on the horizon.

Interpreted languages have their place but there is not enough evidence to suggest they will replace compiled languages any time soon. I'd like to see a few more maintenance and upgrade cycles before I make my mind up.

share|improve this answer
You are completely confusing multiple independent axis here. First: there is no such thing as a compiled language, every language can be compiled or interpreted. Second, the question whether a language is statically or dynamically typed has nothing to do with whether it is implemented by a compiler. – Jörg W Mittag Mar 9 '09 at 23:19
1  
It still doesn't change my point about performance and security. And of course there are compiled languages, the question is what level of compilation, machine code, assembly, p-code or source text. As far as I know most, if not all, the dynamic languages are interpreted. – Leo Moore Mar 9 '09 at 23:55
9 out of 9 Python implementations are compiled, 13 out of 14 Ruby implementations contain a compiler, several JavaScript implementations are compiled, all Smalltalk implementations are compiled, many Lisp and Scheme implementations are compiled, at least one PHP implementation is compiled. – Jörg W Mittag Mar 10 '09 at 17:12
On the other hand, many Java implementations, and at least one C# implementation are interpreted. It depends a bit on the definition of "interpeted" and "compiled", of course, but there's no clear correlation. – Jörg W Mittag Mar 10 '09 at 17:14
Interpreted = More Flexible Compiled = Faster – Leo Moore Sep 18 '09 at 13:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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