Do you think natively compiled languages have reached their EOL?

views:

11722

answers:

Do you think natively compiled languages have reached their EOL?

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.

+1 A:

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.

Tim Jarvis 2009-03-09 22:01:23

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 2009-03-09 22:24:41

+5 A:

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)

DrJokepu 2009-03-09 22:02:06

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 2009-03-09 22:05:59

+1: VMs != interpreted. JITters still compile down to machine code at runtime.

Dave Swersky 2009-03-09 22:24:01

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 2009-03-09 22:57: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 2009-03-10 10:26:24

+5 A:

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.

Greg Beech 2009-03-09 22:08:53

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 2009-03-09 22:32:23

You can do exactly this with NGEN. The following page has some info about the pros and cons: http://msdn.microsoft.com/en-us/library/6t9t5wcf.aspx

Greg Beech 2009-03-09 22:42:18

Jörg W Mittag 2009-03-09 22:59:23

@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 2009-03-09 23:01:45

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 2009-03-09 23:26:42

... usually faster than compiling.

Jörg W Mittag 2009-03-09 23:27:17

+6 A:

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

What about D?

Burkhard 2009-03-09 22:16:21

Yes, I do agree D is a good answer, but do you see it playing a major in the upcoming years?

Yuval A 2009-03-09 22:33:21

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 2009-03-09 22:43:34

It is unfortunately not. At least not yet.

Burkhard 2009-03-09 23:02:06

+4 A:

OCaml, ATS, BitC, Haskell?

MichaelGG 2009-03-09 22:19:49

And which one of those can you even remotely call "popular"?

Yuval A 2009-03-09 22:32:33

The question was about *future* languages. A language cannot be both popular and new.

Jörg W Mittag 2009-03-09 23:07:09

ATS and BitC are quite new. OCaml is certainly remotely popular.

MichaelGG 2009-03-09 23:32:11

BitC-author Jonathan Shapiro joined Microsoft today,sez OSnews. Such a nice idea, oh well.

pngaz 2009-04-06 14:31:00

MS hiring him sounds like a potentially very good thing :).

MichaelGG 2009-04-06 20:59:29

Shapiro has since left Microsoft and resumed work on BitC.

Edward Kmett 2010-08-05 17:11:39

+8 A:

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.

overslacked 2009-03-09 22:19:56

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 2009-03-09 23:05:35

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 2010-08-10 05:09:36

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.

Element 2009-03-09 22:22:01

Jörg W Mittag 2009-03-09 23:09:39

Python, in particular has multiple compiled implementations: Shedskin, for example.

Jörg W Mittag 2009-03-09 23:10:32

+2 A:

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"?

jalf 2009-03-09 22:24:03

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 2009-03-09 23:13:14

+4 A:

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>

Chris Lutz 2009-03-09 22:25:05

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 2009-03-09 23:15:15

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 2009-05-11 20:04:09

+2 A:

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.

banjollity 2009-03-09 22:27:41

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 2009-03-09 23:22:01

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 2009-03-09 23:24:01

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 2010-08-05 19:28:29

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.

Leo Moore 2009-03-09 22:30:06

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 2009-03-09 23:19:28

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 2009-03-09 23:55:53

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 2009-03-10 17:12:49

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 2009-03-10 17:14:08

Interpreted = More FlexibleCompiled = Faster

Leo Moore 2009-09-18 13:03:21

+74 A:

tgamblin 2009-03-09 22:37:25

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 2009-03-09 23:17:01

Quit nitpicking. See http://en.wikipedia.org/wiki/Compiled_language. Notice judicious use of "typically" in first sentence.

tgamblin 2009-03-09 23:19:47

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 2009-03-09 23:33:56

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 2009-03-09 23:50:04

From the FAQ: "We expect that many parts of this interpreter will be used as components of a complete Fortress compiler, which is our long term goal." http://research.sun.com/projects/plrg/faq/index.html

tgamblin 2009-03-09 23:50:50

The fact that a language that was explicitly designed to be compiled can *still* be implemented by an interpreter, just proves my point: *any* language can be implemented with an interpreter, a compiler or any combination of the two.

Jörg W Mittag 2009-03-10 17:08:23

No one is disagreeing with you on that point. But if you think that implementation details don't have far-reaching effects on the design of languages, or that languages aren't designed with performance tradeoffs in mind, you're sorely mistaken. That is why people draw this distinction.

tgamblin 2009-03-10 17:19:51

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 2009-03-10 17:38:08

+2 A:

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

Javier 2009-03-09 23:03:21

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.

Pyrolistical 2009-03-09 23:04:28

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 2009-03-09 23:51:23

... 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 2009-03-09 23:52:40

I think F# + C# is quite powerful!!

2009-04-26 04:09:08

ansaurus

tags:

views:

answers:

Do you think natively compiled languages have reached their EOL?

related questions