Ok, I'll get straight to the point: software compilers as we know them today are on their way out. And with them also compiled languages such as C and C++...

Don't believe it? Let's look at some facts:

Let's add these things up: it is extremely likely that 3/4 of the time is spent in generic open source code. Another way to say this, is that compilation only matters for the generic parts of an application. Yet another way to say it: most developers need not care any more, and can focus on selecting tools, designing algorithms, and implementing more powerful concepts for the field they are working in.

But there is more, much more:

To rephrase the above as arguments why compilation is about to go:

Imagine life without compilers: there would no longer be that awful schism between "developers" and "end users". The developer is still identified today as "the guy who has compilers and linkers installed on his machine". That in itself is ok, but considering how many people are introduced to computers every day, and the inevitable issue of making them do things for you (i.e. programming), it is only normal that more and more people will have no clue on what this thing called "compilation" is all about. IMO, this is good - compilation is an artifact of the way software development started out, it has been around for decades, it can now be jettisoned as no longer needed.

Thank you, everyone who made these beasts perform amazing tricks, we are all grateful for where it has taken us - now we can move on...

Wait a minute. Don't we desperately need the most advanced compiler systems for the "engines" of today? Don't we need them to produce the most advanced virtual machines, scripting environments, and operating systems? Should these all be written in assembler again?

Look at it this way: if the key performance issues are in generic code, if that code is open source, and if binary distribution becomes a standard way of deploying software... do you really think we need to distribute and maintain one or more compilers on every system? Of course not. What will happen is that the code base where performance matters will shrink, and that a few groups of people will pull every trick they know and invent to make that work fast. The rest will not ever want to get involved. With open source, they need not worry about losing control, or not being able to tweak things, they will simply not bother. I know I don't go tune my car - it's fast enough.

Furthermore, I predict that assembly language will come back more than before. Some person somewhere will invest and create some very fast special-purpose versions of algorithms, and we will be able to plug them in. This platform-specific code will be optional, with different people providing such versions for x86, PPC, Sparc, etc. When binary distribution is common, all it takes is three geniuses...

Related note: keep an eye on Forth, that language invented by Charles Moore in the 1960's. Its assembly-like qualities, and the fact that it smoothly bridges the gap from portable to CPU-tuned software, will return in force in the coming years. Not to make Forth programmers from all of us, but for some people - with 80% of all performance in generic open source code, such a temptation will make this inevitable.

Is this a revolution? Not really. We have seen exactly the same happen at the firmware level. Though proprietary, and with a level of investment which exceeds software development by far, the current chip industry (i.e. Intel, AMD, Motorola, etc) has done a good job of producing raw silicon power, and advancing that state of the art. As a programmer, would you want to get involved in VLSI chip design? Well, get ready for it: forget predominantly-compiled apps - fast!

So where does that leave today's tools and languages? My take on it:

Here ends my crystal ball gazing for now...

As someone who has invested over a decade in C and C++ each, I can't say I'd be sorry about such a trend, despite the fact that it will make my skills less relevant for the future. Today's deployment hassles are unbelievably stifling and unproductive - and anything which gets working software into the hands of people who want to use it is bound to be a major step forwards from the

build -> test -> package -> distribute -> build -> test -> use

nightmare we live in today.

November 2000