Wow -- Slashdot again. That is always fun. I'm always amazed at the flow and I love the influx of comments both on Slashdot itself and on my blog.
One comment was from "Dave B" asking me to elaborate on some theories as to why C++ hasn't developed the same set of libraries that other environments such as Perl, Python, Java, C#, etc. have. Here are a bunch of ideas. I have no empirical data but just gut feeling.
First off, we must examine the philosophy behind different environments. I may be making broad generalizations here, but stay with me:
- Java and the CLR (C#, VB.Net): "Make the easy things easy and make the hard things possible." These environments try to avoid the inherit complexity that C++ has.
- Python and Perl (and perhaps others that I have no experience with): "Make my life easier -- I don't want to spend more time writing this fast and dirty script than I have to". Above all else users here prize being able to get something useful done now.
- C++: "Give me all of the fundamental tools and building blocks and I'll do it myself." Power trumps all. Templates and the way that people use them are a great example of this.
- (I'm sure that there are more categories for things like Lisp and Smalltalk. Filling out that part of the list is left as an exercise to the reader)
With this difference in philosophy it is no wonder that there is such - ahem - diversity in the C++ library space. Here are some more thoughts.
- There *are* good sets of libraries out there for doing stuff. One example would be boost. These have limited uptake I think for a couple of reasons. First, downloading and building these is a pain. They don't already come with your compiler. Second, these libraries are either laser focused on a specific area (libtiff?) or are more collections/algorithms base. Boost, for example, doesn't include an easy interface for dealing with zip files or for writing a single threaded select loop based network server.
- The C++ standards process is slow and ponderous. While there are downsides to these environments being controlled by a single entity or a focused group, but the end result is much faster advancement of the language/runtime/environment.
- There are so many ways to do things in C++ that invariably arguments come up over how to do something. Even within one company, people can't agree. For some reason C++ programmers seem to be more stubborn on a lot of these points. The result is that everyone just writes their own thing.
- It is way to easy to write super hard to use APIs in C++. Templates make this problem worse. If you do this stuff day in and day out you get to know it and it makes sense to you, but most C++ libraries are hard to use on a casual basis. I think that there is a disease where people think that it is their obligation to use templates in as confusing a way as possible. Any time a class has a templated base class, you are going to go right over the head of 95% of the developers out there.
- Opinions are divided around RTTI and exceptions. Code written to deal with exceptions doesn't interop well with code that turns exceptions off. Almost no one turns on RTTI. In any case, the result is that these are walls to reusing code. If you don't use exceptions you have to come up with your own error code space or use platform concepts like HRESULTs.
- Everyone likes to replace their allocator but there is no standard way to do that for various libraries. If library lets your replace the allocator it is usually something that has to be done on a library by library basis. So many problems would be solved if the CRT and language had a way to do global hooking of the malloc/free and new/delete at the link level.
- DLLs, shared libraries, compiler differences, differing STL support all make it harder to do things in a standard way.
- Windows doesn't have a good standard build system. The upshot is that libraries are only on Unix or the Windows build is cobbled together. Environments like Cygwin are really poor compromises. It would be better for everyone if the unix make/configure systems would be updated to work natively on Windows also. It isn't like Windows can change anytime soon without breaking the world. The MS compilers are now free -- the make system is really the only missing part now.
- Each codebase has its own way for deciding how header files are included. Figuring stuff like that out is just a headache.
- Lots and lots of different string types.
Does this hurt C++? Probably not -- it is just targeted at a different audience. When you need the power you need the power. If you have to hunt around for example code or a helper library and somehow jam it in to your build system and project then that is the price for playing the game.
Just some random thoughts on a Saturday morning...