After graduating from school with a bachelor's degree of computer science, I must admit that I knew virtually nothing about developing *NIX based applications (that's UNIX / Linux based applications for the non-geeks out there). Granted, I did do a little bit of non-Windows based programming while in school, but it was always incredibly basic stuff: compiling one or two source files, or occasionally writing a make-file for larger projects (three or four source files). Having never had a Linux or UNIX box to play with outside of school, I just never got a chance to get my feet wet. Thankfully, my job at IBM has changed that.

Over the past few weeks, I've been doing a great deal of Linux programming, thanks to the cross-"platformedness" of one of the projects I'm working on. And this project is way more complicated than your typical school assignment. I'm now horsing around dynamically linked libraries, also known as "shared objects" in Linux land, like nobody's business. Not only that, the project itself is essentially a multi-threaded shared object, making it all the more exciting. I've learned more about g++, ld, and ldd in the past few weeks than I ever knew before.

Unfortunately, debugging multi-threaded shared objects is easier said than done. The debugging tools in Linux (at least the ones I've played with) all suck so horribly. They make you really appreciate the level of quality in Microsoft's Visual Studio debugger, or better yet, in WinDBG (this thing is hard core, and it's what the MS developers actually use in practice). Fortunately, printf() always saves the day.

One cool trick I recently employed to debug a library loading problem I was having, is the LD_DEBUG environment variable. If you set LD_DEBUG to a value of versions, the Linux dynamic linker will print all of the version dependencies for each library used for a given command. If you have a Linux box, try it out. Set the LD_DEBUG environment variable, then do an ls. You'll be amazed at the number of libraries that such a simple command involves.

Although Linux development can be frustrating at times, I've already learned a great deal and consider my experiences a great success. If I come across any more useful tips (like LD_DEBUG above), I'll try my best to post them here (as much for my sake as for yours). Until then, you'll find me knee-deep in my Linux code. I've got a few more bugs to squash.

I just saw a commercial on TV for a (presumably) local college, and they touted their program by showing a bunch of "video game developers." This motley crew of students looked no older than 20, and one girl commented "Can you believe we get paid to play games?" The people who put together this advertisement clearly understand nothing about the game development industry. I would hazard to guess that game developers spend less than 5% of their time actually playing games. Few people, if any, get paid to play games; the real glory, as well as the real money, is in development. And game development isn't an easy task.

In college, I had the privilege to take two computer graphics courses. Both were challenging, and both gave me a new appreciation for game development. The folks who create today's game engines are literally pushing the envelope in computer graphics. I shudder to think of how complex the math is behind games like Half-Life 2, Far Cry, and Quake 4. To think that your average college kid can do this fresh out of a no-name school is a little hard for me to believe.

My dad pointed me to an excellent article entitled The Perils of JavaSchools. Although it's a little lengthy, the article is an incredibly worthwhile read on why schools that teach Java as the primary programming language are, to some degree, dumbing down the future generation of computer programmers. My alma mater took this route, but I was fortunate enough to be in the class before this change was made. I picked up C++ first: both on my own (by learning Visual C++ and MFC) and in school (my first programming courses were all taught using C++). After learning the intracacies of C++, learning Java was incredibly simple (almost too simple, in fact). I believe I passed my "Java for C Programmers" course with an A+; a feat that required very little effort on my part.

Once one knows about pointers, objects in Java become rediculously easy to discuss. As does the entire programming language itself. Java is a fine programming language (it fixes a lot of the brokenness in C++), but to know C++ is to feel enabled. I can wield the mighty sword of pointers and memory management; something that many Java programmers do not, and quite possible can not, ever do. I'm not saying that Java programmers cannot become successful C++ programmers; I'm simply making the point that there are more Java programmers who cannot pick up C++ than there are C++ programmers who cannot pick up Java.

Again, I highly recommend the article. The author also has an incredibly enticing reading list, which he uses to train managers in his company. There are a number of books there that look really great. I hope to begin reading The Mythical Man Month, the masterpiece written by Fred Brooks. It's one that I've been meaning to read for a long, long time.

Before I ever began my programming career, I had a sneaking suspicion that an abundance of coding at work would lead to decreased programming activity at home. And I fear that this is indeed becoming the case with me. I write a mixture of C++ and Perl all day long, five days a week. This level of productivity really taxes my mind, and it has recently resulted in an increase of non-computing related activity each evening. I’m reading books more often (Prince Valiant has certainly helped in that arena), and I’m watching more TV than I used to. I even occasionally go outside! Things like Googlebar Lite and my toolbar tutorial are slipping as a result. I dislike it, but my motivation for programming after 5:00 PM has dropped greatly. Weekends provide some level of salvation, but is that enough?

I do a fair amount of C++ programming these days, thanks to my new career at IBM. C++ is my strongest language, and the first language I picked up when I began programming. As such, it's fairly special to me. However, the more I time I spend with C++, the more I come to see how broken it is.

For instance, why are strings not a base type? Character arrays simply do not suffice. I am aware of the STL string class (and I make use of it), but adding on this capability after the fact seems cheap. Strings should be a first-class object, and should have all the associated operators directly available (==, +=, etc.). And regular expressions should be directly available for strings, since they are so incredibly useful. There are tons of places in my code where access to regular expressions would make my life profoundly simple. For example, take Perl's match operator (m//). How many Perl programs out there do not make use of this operator? My guess is that the number is very low. It's no different in C++; reg-exes could be used all over the place.

Other glaring omissions also crop up. Where is the foreach loop construct? Why use #include instead of packages or modules? Where are the array operators (shift, unshift, pop, push)?

There's no question that C++ is a robust language. It's fast, gives the programmer complete control (both a blessing and a curse), and it has an incredible user base (which results in excellent support when you need it). But it's clearly dated. Will we still hold on to this language in 20 years? Or will something innovative finally come along to push it aside? Let's hope for the latter.