C++ programmers are people too, aren't they? You wouldn't think anyone thought so, the way the industry looks today. Java started its run in the late 90s and it rapidly became the lingua franca of programming. Over night, authors started using it for all of their examples in books and articles. Certainly this was response to the market, but Java is also a much more succinct language. If you are going to write about design, Java gives you a better chance of fitting a code snippet on a page. The net effect, however, is that if you look around for evidence of C++'s continued existence, it is pretty easy to miss it. And, if you are one of these invisible C++ programmers and you are aware of that tools are available for Java but not C++, well, you should be screaming. C++ was my first OO language and every time I go back to program in it I notice the lack of support.

A few weeks ago, I was working with a team whose code is split right down the middle. Half of the code is Java and the other half is C++. At the beginning of each iteration, the team members sign up for tasks. When someone walks into the room each morning you can pretty much tell whether they'll be working in C++ or Java. Their faces tell the story. The people who are going to be working in Java march in confidently and start up their Java-based IDE, then they go to get coffee while it loads (yes, there still are some issues in Java-land). When they get back with steaming cups in hand, they look around at the code, find the methods they need to change. They click a menu item and it shows them all of the places that send a particular message. Then they start going through the work of carving out a space to work with their code. They click the mouse around to extract interfaces and methods automatically so that they can get some tests in place for their changes. The C++ programmers come in and bring up vi or emacs (they load quickly so no coffee for the C++ guys) then they browse around the code manually and start to figure out where to make their changes. Figuring out what uses what is often a blind-alley search. When they are ready to break some dependencies, they sit there and try to manually peel off interfaces by introducing virtual functions. They create new header files and extract methods by hand, all the while hoping and praying that they aren't breaking anything. Without an automated tool to check their refactorings it is a nerve-wearing process and it's also several times slower. They know that the Java code is getting better, but it is hard to feel the progress on the C++ side. I don't think the lack of coffee has anything to do with it.

Occasionally, some C++ teams I visit don't know what refactoring tools are out there. I was showing a team a testing technique a while back. The technique was language independent, so I pulled up a Java IDE. Over the course of my coding I found a method name that I didn't like. I pulled down a menu and hit rename. When I typed in the new name it was replaced every place it was used. Not every place in the file, every place it was used. Three of the team members recognized what they saw when I did it and they shouted "NNNOOO WAAAAAYYY!!!" I think I could have induced dead faints if I'd shown an automated extract method refactoring.

The sad thing is, it shouldn't be like this.

The first research into automated OO refactoring was done by Bill Opdyke and Ralph Johnson in the early 1990s, in C++. After that, John Brant and Don Roberts developed the first Smalltalk refactoring browser. Later, Martin Fowler wrote the book 'Refactoring.' That book and Extreme Programming really put refactoring on the radar screen. Java vendors scrambled to build refactoring tools into their IDEs. After all, it was the lingua franca, the language everyone is using, right?