If we had a universal interpreter for all available features of programming languages we could use a specializer to generate compilers for all languages. We could simply use any language as source (or input) and any platform as target (output).

We could all write in our favorite programming language to add features to that universal interpreter because the base Abstract Syntax Tree (used by the universal interpreter) could be a target of our favorite programming language. On top of that, you could view the 'source code' of the universal interpreter in any language because the 'source code' of that universal interpreter is actually an AST.

Despite programmers having these sort of ideas for more than 40 years most of us still seem to think that we need to choose a specific textual representation and appropriate interpreter (or specialized interpreter called compiler).

I don't get why that is. There are so much programmers around and most programmers are really passionate about their ability to create. I don't understand why we fight about different programming languages, to me they seem like a different view on the same AST.

Why are we all not using the same base as a library from which we can pick language features?

closed as primarily opinion-based by James McLeod, Dan Pichelman, user40980, Tulains Córdova, gnat Feb 17 '15 at 4:53

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.

  • 7
    Well that's not the case. If you choose the AST to be assembly for an architecture then pretty much every language does indeed target the same base. If you're wondering why have different languages at all: well there are certain language features that are just not compatible. You can't have general recursion and termination, it's just not possible. Different languages are necessarily different chunks of some Platonic language of computation because it's contradictory to glom everything together into one thing. – jozefg Feb 16 '15 at 21:46
  • 3
    yes. this idea is called Lisp. Nobody who's sane thinks this is a good idea – AK_ Feb 16 '15 at 21:49
  • 4
    One common target and infrastructure for different languages? We already have this, see for example en.wikipedia.org/wiki/List_of_CLI_languages and en.wikipedia.org/wiki/List_of_JVM_languages... and don't forget LLVM en.wikipedia.org/wiki/LLVM – Doc Brown Feb 16 '15 at 21:52
  • 2
    Syntax matters. I don't want to program in ASTs. And a "universal interpreter" won't be able to fit the runtime needs of every language. For instance, garbage collectors for functional languages have very different assumptions from those in imperative languages. And what about purity and laziness? Haskell relies on these and the runtime system is built for them. How do you reconcile those needs with languages that are neither pure nor lazy? – Doval Feb 16 '15 at 21:58
  • 2
    @EECOLOR re marking features - what about the features by prohibition? Agda do guarantee to large extent the correctness of program (corrects states and termination) - if you allow it to interact arbitrarily with PHP you loose such guarantees without needed to check anything. In similar way NULL-less languages have 'fun' interacting with languages that do have a billion dollar mistake in design (see Scala and JVM). (In addition to Doc Brown examples LLVM seems to be close to arbitrary input/arbitrary output). – Maciej Piechotka Feb 16 '15 at 21:59
up vote 18 down vote accepted

You seem to think that programming languages differ only in their syntax. This is not the case. Languages can have vastly incompatible semantics as well. For example:

  • A functional language that uses lazy evaluation and an imperative language that allows side effects are difficult to combine.
  • A language that allows pointer arithmetic and a language that guarantees memory safety are difficult to reconcile.
  • A program involving infinite loops cannot necessarily be expressed in a language such as Coq.
  • A language that allows dynamic dispatch (i.e. OOP) is incompatible with a language that is completely statically typed.
  • Some languages don't offer dynamic memory allocation.
  • A program using closures does not have a straightforward representation in a language without garbage collection.

The list of incompatibilities goes on and on.

There are a couple of program representations that are common for different languages. These are called machine code or byte code. While they are functionally equivalent to the original program, most of the structure of the program is lost.

The .NET common language runtime is an interesting example of an intermediate-level language platform that supports a variety of different languages, both imperative and object-oriented (e.g. C#) and functional (e.g. F#). While programs cannot be transformed from one language to the other – slight feature mismatches exist –, different parts of the same project can be written using different languages. Due to the common feature-rich runtime, their interop facilities are practically effortless.

  • There is a finite set of these semtantics (in programming languages now) right? Couldn't we create an interpreter that deals with this? – EECOLOR Feb 16 '15 at 22:11
  • 1
    @EECOLOR There trivially are a finite number of programming languages. But no, realistically, there is far too much diversity in languages for a single AST, a single IR, or a single interpreter. – user7043 Feb 16 '15 at 22:18
  • 5
    @EECOLOR Yes, common interpreters are possible – your computer's CPU is one example. But getting a usable, high-level representation that is similar to the source representation of the program back from the common interpreter's representation is not generally possible. This becomes easier when the executable representation closely mirrors the high-level source language. But that always means this executable representation moves further away from other languages, which then do not map cleanly to that executable representation. – amon Feb 16 '15 at 22:22

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