The King is dead. Long live the King!
After reading over the planned changes in the new C++0x standard, all I can say is that it seems like C++ is dead. The changes seem like feeble attempts to bring C++ up to speed with modern languages; but all they do is pile more spaghetti on the plate, making the language even more complex and difficult to use. With more powerful (and I will come to define that in a minute), modern languages now able to match, and sometimes beat, the speed of C++, I can only wonder why anyone would choose C++ anymore. I am not so naive as to think that C++ will disappear anytime soon (decades of legacy code are not going to be miraculously ported), but I wonder how many new projects will use it in the future.
Personally, I haven’t chosen to use C++ in a long while. I find that compared to more modern languages, it lacks expressiveness and efficiency. I want my code to be elegent, legible, and above all: easy to write. C++ feels like a chore with templates, inclusion guards, cyclical definitions, pointers, memory management, et cetera. I want the language to do the work for me. A powerful language is one that allows me to accomplish the most with the littlest effort. I should not have to wonder how to use RTTI with a derived template class (though, often, if you find yourself wondering about something this complicated, you are using the wrong paradigm).
Take, for example, the move towards concurrency. C++, even with open libraries and its new standard, just seems to fall behind. It was not designed for this behavior, so any attempts to do it typically leads to a garbled mess. OpenMP works, but it is not very pretty to use. Having to define critical blocks and atomic operations only slows the programmer down. Compare this with Erlang, which was designed with concurrency and parallel computation in mind, and you realize how much effort it is to use C++. Trying to force C++ to do concurrency is like trying to force a square peg through a round hole: with enough effort, you can probably do it, but it would have been a lot easier just to get a round peg in the first place.
So if C++, the undisputed King, is dead, who will take his place? My hope: nobody. In my opinion, there is no best-fit language. Languages should be designed vertically, to fill a niche need. As programmers, we should be using the right tool for the right job. Carpenters don’t use one tool for the work they do, so why do we? If I want an easy distribution paradigm, I’ll use Erlang. If I want dynamic metaprogramming, I’ll use Ruby. If I need to do work with matrices and mathematics, I will use R. Maybe I will get crazy and use J.
Rather, we should focus, as a community, as to how we can better use these languages together. Let’s say I am developing an automated trading platform. Perhaps I will choose Erlang as the backbone, allowing me to easily distribute the work and have built in redundency. Using Erlang’s strengths, I could have multiple servers running around the nation, reducing my risks if one server becomes innactive. Erlang, however, is not very nice to write high-level constructs in. Perhaps I would want to use Ruby instead, and take advantage of its metaprogramming to implement my strategies. Now, perhaps, I want a GUI. I could use C# or Java … but what if I wanted to use Cocoa on MacOSX? Or maybe Python and PyGTK?
You should note that this is not a crazy an idea. First, we had the separation of logic and data (think web-server written in C++ and website written in HTML). Now we are making a further separation: application, logic, and data (think of games: we have an engine, scripting language, and data). Does it not seem like a reasonable idea to continue the separation of the engine into modules, each implemented by the most powerful language for the job.
My point being: instead of having general purpose languages, why don’t we have several niche languages, which each have the best syntax to tackle the problem they were designed for, and then work on gluing these languages together?
