Why can’t C++ be more like Python?

OK I created this, my new blog a couple of weeks ago now … probably time I posted something to it …

Question: What’s the main difference between C++ and Python?

You might be thinking I’m going to talk about Dynamic Typing or Significant White Space or maybe the pros and cons of Garbage Collection.  However (at least on this occasion), you would be wrong.  If you said “C++ is compiled, Python is interpreted” you would be right on target … well kind of.

Back when I did “Computers” at school (which was more than a few years ago let’s just say) we were taught there were two types of languages.  Compiled languages, like C, need to be compiled into machine code before they can be executed which means programs run fast but it’s more of a pain to develop in, while languages like BASIC are interpreted which means programs are slow to run but it’s much easier to use since you just “type and run”.

However here’s the thing, times change and despite all appearances to the contrary, what with most Python programs being scripts complete with shebang line, Python isn’t interpreted.  In fact with the exception of actual shell scripts most so called ‘scripting’ languages aren’t interpreted these days.  Instead recent languages use a JIT compiler, which is a really clever bit of sleight of hand.  It gives the same “type and run” feel of old fashioned interpreted languages but behind the scenes the code is compiled and runs fast.

So why then is C++ stuck back in the dark ages?  Is there some reason why C++ can’t take advantage of the JIT revolution?

Well I can’t think of any fundamental reason why C++ can’t be part of the “JITset” crowd.  For the time being though there are a couple of stumbling blocks.

Firstly compiling C++ is sloooow.  Partly this is because C++ and C before it were never really designed to be easy to compile – it’s not a clean LR(n) syntax for one and then there’s the archaic C preprocessor which means even the simplest of programs involves compiling thousands of extra lines hidden in dozens of #include’d files.  In addition, fast compiling has never really been one of the design goals of a C++ compiler which historically have focused on ever more ingenious ways of make the compiled code run faster, usually at the expense of compilation speed.  This has changed recently with GCC rival Clang which has a stated goal of being “fast, light and scalable”.

Secondly lets talk about build systems.  Whether its autotools, cmake, scons or something else that floats your boat they all have one thing in common – in a sane world they would all be unnecessary!  They all exist because unlike Python,  C++ does not have a standard run time environment.  So you have to futzy around checking if you have this library or that one, this include file or that one.  You even have to check which features the compiler supports and what options it expects to enable them…  there desperately needs to be some standardisation here!  Fortunately a lot of this is historical and intended primarily to allow programs to compile on dozens of wildly different Unix variants.  With many of these systems obsolete and the proprietary Unix market in free-fall there is at least some hope of sanity being restored at some point.

So this is me looking forward to :

$ cat >hello
#! /usr/bin/jitc
int main()
{
printf("Hello\n");
}

$ ./hello
Hello