Here’s the thing. I tried to get attached to other programming languages, but somehow, deep inside my heart, C++ continues to reign supreme. It’s absolutely lovely, it has raw power, and you can optimize everything to hell and back. No, it’s not C; C is too low level and sometimes can harm your performance by not being able to do copy-paste the way templates do. Plus the things you need to do with macros…
But the problem is that I can’t get myself to create projects in C++. I would love working on one, but I just can’t get myself to start. I need these features which I’ll present without further ado.
The modules specifications.
Not only the modules spec should be pushed forward and fast, but it should be made mandatory and anything else obsoleted. And that includes the preprocessor from C. C++ will be a totally different language as soon as it removes the need of a very verbose, hand-generated header files.
I don’t mind if, in the back, C++ compilers will continue to support header files. It can very well do that, since old code must be supported, I don’t want to go Jonathan Blow on this and create my own language. I don’t think I want to discard the 25+ years of compiler experience from the C++ compilers. I don’t want to discard 25+ years of libraries (or do I?) but I do want to get rid of the need to read header files kludged with macros and whatnot, only to find out that those header files are from a different version of a library. And yes, I want the libraries to deliver the public interfaces as well, the way they were compiled. And I want a compiled version of the standard library.
The modules specification actually can make the C++ library writers a lot more efficient. Right now it’s a bit hard to specify in a clear manner what you want to export publicly and what you want to keep inside the library, so that people don’t count on unpublished internal interfaces that might change in time. Not only that, but also there will be no need to deliver a ‘development’ package, because you deliver it with your libraries. Just like decent people would. And, anyway, it will be easier to focus on what you expose, and think three times if something needs to be exposed or not. And that will make everyone write smaller and more efficient interfaces. Or they can go Boost on you, like they always do :(. But hey, freedom!
A new standard library
STL is as bad as a heart-attack. You can survive it, but it will affect you for eternity, and your performance will never be the same. And the C++ standard library has come to be associated with the STL. With all due respect to Mr. Stepanov, who I think is a great computer scientist, but STL is an example on how not to write a library.
C++ has the worst strings support out of the box. It’s convoluted, it’s complicated, you can’t convert properly from various encodings without some horrible gymnastics. It’s badly documented. It has an inexpressive interface. It probably is the worst string class ever designed by humans.
Then, other containers. Again, they do have the worst interfaces possible, in naming as well as concepts. push_back is the worst name you could have for an operation where you add an element. For vectors, there are 8 iterator functions, and 7 functions related to the number of elements. I emphasize on the iterator functions because nobody in their sane mind looks for ‘iterators’. I never needed an ‘iterator’ in my entire programmer life. I used them, but I never needed them in an explicit manner. They shouldn’t be there. We don’t need to see them.
The STL gives, in any usage scenario, the feeling that you’re in a construction site, and all you can build is skeletons. You don’t use finished sets of pieces, you use steel bars, and that’s all the finish you can put in your work.
And I know that the conceptual problems that C++ tries to solve are indeed complicated. That’s why you have to write seven functions for every class, constructors and assignment operators just to make sure that your class will behave properly. Hopefully. That’s why you can have a different function for const X&, const X*, X& and X* parameters. That’s why you have to learn that you can overwrite the -> operator, and it’s as insane as it sounds. C++ can and will let you do that.
The sad part
The more I write about C++, it’s obvious that I don’t really need C++. Currently, C++ is one of the least portable programming languages. It has problems behaving on the same platform with a different flavor. You can’t deliver a complete, no-nonsense C++ environment, you can’t deliver for a C++ environment. That’s why, for example, game developers are bowing to Valve for creating SteamOS – because that’s a platform they can count on.
So I guess I should go Jonathan Blow on this one. Maybe we do need a new programming language after all. Or maybe I should stop complaining and learn Haskell.