How programming languages may look in future.

Created by Peter Kankowski
Last changed
Filed under Interpreters and compilers

Share on social sitesReddit Digg Delicious Buzz Facebook Twitter

The future of compilers

In past, there was a clear difference between compiled languages and interpreted languages. The former were statically typed, often had manual memory management and powerful optimizing compilers (C, Pascal, Ada). The later were dynamically (often weakly) typed, interpreted, and were used for scripting and learning (BASIC, AWK, Unix shells). Today, the distinction is blurred: interpreters became fast enough by using just-in-time compilation (JavaScript, Lua) and compilers got convenient features making them more usable for scripting (automatic memory management, type inference). In this article, I tried to imagine how programming languages will look in future.

No explicit types

First, there will be no syntactic difference between statically and dynamically typed languages. You will not have to specify type for any variable explicitly. A simple language implementation will use dynamic typing, and a more complex one will statically infer the types to generate better code. For example, to count the number of unique elements in array, you now have to write:

// C++
using namespace std;

int count_unique_words(vector words) {
	map unique_words;
	for(vector::const_iterator it = words.begin(); it != words.end(); it++)
        unique_words[*it] = true;
	return unique_words.size();

Type inference can be used in C++0x to deduce the type of iterator, but not the type of unique_words or words. The language is verbose and nagging.

// Python
def count_unique_words(words):
	unique_words = {}
	for word in words:
		unique_words.setdefault(word, True)
	return len(unique_words)

Python code is close to ideal, but the interpreter have to check the variable types at runtime. In future, it will be as efficient as C++ by using type inference. If the count_unique_words function is called twice — with an array of integers and an array of strings, — the compiler will generate two separate functions (similar to C++ templates).

Choosing the optimal data structure

High-level scripting languages used to be slower, because the interpreters have to use the most common type required by the language semantics. For example, if arrays are always associative (as in PHP and AWK), they have to use a hash table even for arrays indexed by small integers. That's why Python and Perl introduce a special type for associative arrays (Python also has "optimized" tuples and iterators). Lua solves the problem by splitting an array into two parts (an array and a hash table) and dynamically choosing in which part to put the element.

In future, compilers will be able to statically analyze the code and choose the most appropriate data structure. For example, if an array is only used as stack (by calling push and pop methods), a linked list may be better than a hash table or an array.

Background incremental compilation

For most programming languages, compiler is a separate command-line program. A programmer types the source code in IDE, then waits while it is compiled:

Sequentially: programmer writes the code, compiler transforms it to machine code

Modern IDEs such as Visual Studio 2010 analyze your code, check its syntax and remember symbols for IntelliSense tooltips. A full compiler can be implemented in the same way: it can try to compile the function you are typing now (or just have finished to type). If any global definitions are changed, it recompiles the affected code. Global optimizations can be enabled by storing call graph and recompiling the affected functions. For example, if the current function is inlined, all functions that call it must be recompiled. A compiler can store their ASTs to speed up the process.

In parallel: programmer writes the code and compiler transforms it to machine code piece-by-piece

This incremental compiler will have to do more work than the current compilers, because the previous versions of compiled functions will be often thrown away. However, it will compile the code while it is edited, so the programmer will not have to wait for the compilation. Multicore processors can compile several functions simultaneously (already implemented in MSVC++). The symbol table, which is updated as you type the code, can be used for IntelliSense-like tooltips. Furthermore, unit tests can be run in background after finishing compilation.


The ideas described above will make a compiler more complex, but the current compilers are already very sophisticated, so we can expect that incremental compilation and intelligent choice of data structure will be implemented in the nearest future.

Peter Kankowski
Peter Kankowski

About the author

Peter is the developer of Aba Search and Replace, a tool for replacing text in multiple files. He likes to program in C with a bit of C++, also in x86 assembly language, Python, and PHP. He can be reached at kankowski@gmail.com.

Created by Peter Kankowski
Last changed


It´s no future !,

The future will remain the same!

The future will continue exactly as it is ... that is, JAVA is who will lead the programming market ...

And why?

Because Java was simply the programming language chosen by the IT industry ... that is, she was voted the "darling" among

all languages ​​available ...

With this election, JAVA can have at their disposal the best brains in the area, massive capital investments and everything else that is

required to maintain "the leadership" of the software production area ...

This "phenomenon" is not only observed in the IT market ... all other industries also have their "elected" without

no apparent reason, nothing to justify ... just the fact that a group met and elected someone as "the darling of the area"!

Manish Patel,

Hi Peter,

Interesting article.

As compilers get "smarter", programmers might get dumber, because they will have to think less. Don't you think it might give rise to a "trial-and-error" programming approach, especially among beginners? What will happen to their abilities of thinking through the problem before starting to type the code?

Or should we leave it to features like IntelliSense and incremental compiling? I have seen so many programmers depending on IDEs to tell them what they are doing wrong and fixing their code along the way, rather than thinking about what they should be doing right in the first place.

And, why should a compiler decide whether a linked-list or array should be used in a given situation? Shouldn't the programmer not know, or care about which one to use? How many new data structures have been invented since in the last 3 decades anyway?

Finally, I think learning the art of programming is far easier that learning to use the increasingly complex IDEs.

Maybe, that's what the big boys want - dumb down the process enough to lead the sheep to their respective lairs, aka platforms.

Peter Kankowski,

Hi Manish,

unfortunately, it already happened. Today, young developers start with web programming (JavaScript, PHP, Ruby, etc.) and never use low-level languages, so many of them don't understand algorithms, data structures, and performance tuning. That's why we see slow apps and stupid code.

On the brighter side, a lot of programs that were unrealistic to write are possible now due to new programming languages and smart IDEs.

Thank you for your reply.

Manish Patel,

I agree with you that new programming languages allow writing modern-day applications. One such language that comes to mind is Lingo (a scripting language developed by Macromedia->Adobe for their Director multimedia presentation application). Had Macromedia, and now, Adobe given more attention to this language, it would have challenged Python in every conceivable feature.

However, I don't understand how smart IDE's help create smart programs. At best, I feel they can improve overall programmer efficiency by automating tasks.

Your name:


Please ignore this field: