In previous posts, I have described features of garbage collection which I consider beneficial. Today I am going to discuss a "feature" which I think is a good reason to learn about garbage collection, but not necessarily a good thing overall. To wit: If you intend to continue working in the software development industry, you’re going to be using garbage collection, whether you like it or not.
This may be a hard pill to swallow for so-called "C++ programmers" or "Pascal programmers" who do not know any programming languages designed after the 1970s. But change is the rule in the software industry. If you are not learning new skills, you are eventually going to be left behind. (Note that I am not claiming that these older languages are going to go away; COBOL is still in use, too, but most people don’t make that a career goal.)
As far as I can tell, programming language designers do not seem to be creating non-garbage-collected, general-purpose programming languages anymore. This trend is not restricted to "scripting languages" or languages requiring a run time. Performance-oriented languages designed as potential replacements for C++, such as D and OCaml, are garbage collected, and the forthcoming version of the C++ standard will include features explicitly intended to facilitate use of a garbage collector.
I do not know what the programming language(s) of the future will be. Steve Yegge discussed the issue at some length, and came to the same conclusion as this post regarding GC:
[Next Big Language] is garbage collected. There will always be a bunch of engineers who think that’s evil, and they’ll continue to use C++.
C++ does need to get replaced someday. It’s just horrid, and everyone knows it. However, there aren’t very many people trying to replace it, either. The only contenders I’m aware of are Objective C and the D Programming Language.
D’s a really beautiful language. By rights it should be the next C++. However, C++ programmers won’t have it because it’s garbage collected (even though it can be disabled, and even though Stroustroup [sic.] himself is now advocating adding garbage collection to C++). Walter Bright is one hell of a lot smarter than the C++ programmers who won’t look at his language, and he has demonstrated that D is as fast as or faster than C++ and nearly as expressive as Ruby or Python. It’s a secret weapon just waiting to be seized by some smart company or open-source project.
But nobody ever accuses programmers of being wise.
Perhaps, some years from now, someone will invent a non-garbage-collected language which will become the dominant language of future days. But at the present time, I don’t see any non-garbage-collected candidates for the job.
This makes me a little bit uncomfortable, because, in general, I like to have options. It would be nice if, 10 years from now, I had more than one choice for heap management (presuming that we still have "heaps" in a decade…).
Although I like the concept of making garbage collection optional, it’s much harder to put that option into practice successfully. The trouble is that most people don’t just use programming languages, they also use the standard libraries and toolkits which support those languages. And while it’s fairly trivial to make use of garbage collection within a programming language optional, it’s much harder to do it well with a library. So I don’t think some kind of compiler switch or memory manager plugin will resolve this issue of choice; a real choice would be an environment constructed to work with manual memory release, and I don’t see anyone building that.
Post a Comment