C and C++: A Personal History

Programming languages are tools. But they're also much more than that. They are ways of thinking. Sometimes I think that it would be easier to change people's opinions about religion than about programming languages.

Despite that, I'm going to add my own point of view to the pile of opinions we call the Internet. Perhaps it will make someone think. If nothing else, it will at least provide some historical perspective.

The Performa 600

I was about 13 or 14 when I was first exposed to C++. I can remember the experience clearly. I was using a Macintosh Performa 600, a chunky beige machine packing 32 MHz and 4MB of RAM. If an application crashed, it often took down the whole system, since the system had no concept of protected memory or preemptive multitasking. There were two small, unlabelled buttons placed discreetly on the front panel of the machine. One rebooted the machine instantly. The other dropped you into a sort of admin console where you could peek or poke at any location in memory.

My brother and I used both buttons a lot.

At the time, computer games excited me greatly. However, my experience with games took place in a kind of parallel universe from most gamers. In the PC universe, there were tons of games of every description. The age of small independent studios was in full flower. In my universe, the Mac universe, only the very biggest games ever got ported. And the ports were often buggy, clunky affairs, seemingly done by the lowest bidder. And they often came out years after the PC originals. (Probably the PC port I loved the most was the Doom II port... weird, low-res, and buggy as it was.)

So my brothers and I had this kind of weird, quasi-Soviet gaming experience, where most of what we played was quirky knock offs of much better-known games. Well into the 1990s, a lot of the games we played were black and white, or 16 colors. A lot of the games were weird, deeply personal affairs done by small teams or individuals. I still remember a game called "nuclear war," where you could only do one thing: press a button called "nuclear war," and watch as missiles exploded all around a map of the earth. Of course, it was black and white. I'm guessing that one was written before the fall of the Soviet Union in 1989...

Anyway... due to the lack of games on my platform, I resolved to write some of my own. They definitely couldn't be any worse than "nuclear war," and maybe they would even have some colors! My dad encouraged these thoughts and bought me a C++ compiler for the Macintosh, called "Metrowerks Codewarrior."

C++: the new kid on the block.

At the time, C++ was the hot new high-level programming langage. Of course, with 4 MB of RAM and 32 MHz, "high-level" back then didn't mean what it does today. "New" was also a bit of a misnomer. C++ had existed in various forms since 1979. It was already more than a decade old by the time I got my hands on it.

However, in a very real sense, the early 1990s was when C++ hit its stride. It solved a problem that a lot of companies had at that time-- the need to develop programs faster. And it built on C, a language that most programmers knew at the time.

Development time was absolutely essential back then. The market for software was expanding exponentially, and the first company to get a product to market often had a powerful advantage.

In contrast, safety was not a big concern at that time. Although it existed in research laboratories, the Internet was not yet something that the average American knew anything about. Programs did just about whatever they wanted to do, including modifying system files or fiddling with global memory tables. If the user didn't like it, he could simply go back to whomever had sold him the floppy diskettes and complain. There were a few people downloading pirated software over BBSes, but nobody really cared about those people. They weren't paying customers, after all.

So C++ hit all the sweet spots, and its weaknesses were not really a big deal.

Are You Object Oriented?

Since the early days of programming, people have wanted to formalize and systematize the discipline. It would be nice if we could have the same level of predictability and confidence in writing a program as we do in, say, building a highway overpass.

But instead, programming is as much an art as a science. Nobody really knows how long a project will take (other than "longer than management wants") or even exactly how well it will turn out. Even modifying existing code can take longer than expected. And just as bad (from management's perspective), good programmers are hard to find.

Back in the 1960s, this led to breathless talk about a "software crisis". You can read all about it at Wikipedia. And you really should-- it is uncanny how similar the "crisis" back then is to the "crisis" today. For a more cynical view of our perpetual crisis, see Yossi Kreinin's blog.

In this kind of environment, people tend to latch on to methodologies. Software methodologies usually start with a kernel of truth, like "programs should be structured," "code should be reusable," or "processes should be documented," and build this into a giant edifice. Methodologies give people something to believe in, and a sense of confidence that they're doing the right thing (whatever that is). Nobody can blame them-- they followed all the rules!

It seems like every 5 or 10 years a new methodology crops up. It starts with books, articles, and blog entires. Then it progresses on to lectures and conferences organized by notable gurus. Startups adopt the idea and credit all their success to it. Then it gets adopted by big companies eager to hop on the success train. Finally, cynicism sets in and the methodology is debunked. People still professing the old ways are shunned like people wearing last year's fashions. Then the next methodology starts up.

Back in the early 90s, the magic words were "object oriented." Object oriented code was better in every way than the old, non-object oriented code. It was reusable and modular. It was well-documented and clean. To make everything object-oriented, it was important that you attach methods to objects. Of course, methods still had to take multiple objects as arguments. But now one object would be special-- it would be the main object that the method dealt with. The method would have full access to all parts of this object, but only partial access to the other objects that were arguments.

C++, of course, had full object oriented support. other objects it modified Formerly, methods could take Using the methodology starts to , and finally moves to Methodologies make everyone feel good. Developers feel good that they're learning about something "new" and "modern." Managers feel good that nobody can blame them-- they followed the metholodogy correctly, and should get the correct result. Personally, I tend to hold a cynical view. Programmers are always available, but just not at the prices Mark Zuckerberg and Bill Gates would like. A cynic would say that the crisis Personally, I tend to agree with Yossi Kreinin here: All this has led to breathless talk about estimates for a project are wrong, often several times deadlines often Building highway overpasses can be reduced to Programming is a difficult activity. It's hard to formalize in the way that, say, building a highway overpass inherently a hard activity. It's also not a very rigor , and people have always looked for ways to make it easier. The computer industry goes through periodic fads and phases. Object oriented Programming was a big deal in the 1990s. Of course, the term had been around for a while, but Of course, academics were furious with C++. They wrote fierce diatribes about its evils: the lack of safety, the low and inconsistent level of abstraction, the clumsy syntax. But nobody outside the ivory tower bothered to read the diatribes, much less act on them. They were too busy writing code for the burgeoning personal computer market, which seemed to be growing exponentially. C++ also checked one of the C++ was the perfect language for the early 1990s. It Buffer overflow? Well, be more careful next time! Maybe we'll issue a patch, and maybe not. You know, it's expensive to create new floppies! The fact that C++ code was unmanaged, By running your program, the user had already given you the keys to the kingdom. The program could easily delete all your files, or just grab the Finder and start modifying its memory. But the early 1990s was kind of the high point of C++ My dad loved technology. I was young, idealistic, and unqualified Remember that I was not even a teenager at this point. I was definitely not qualified to do any of this. I had received no training in anything I still remember a game called We were like Moscow residents behind the iron curtain who had heard of Pepsi-Cola and Mickey Mouse, and had sort of an idea that automobiles in the West were a lot different than what we had, but We didn't know they were knock-offs at the time, of course So my brothers and I existed in this weird In my universe, only the biggest games ever appeared Mostly, this was a theoretical Games were mostly a closed book to us, since the most exciting games never came out for Macintosh This was a machine from the dark ages of Apple. Macs were deeply uncool except among a hard-core following. System 6 was starting to show its age. One crash Even back in those days, the specifications were nothing to get excited about. This machine did have something interesting: a CD drive would be easier to change someone's opinion about his religion than to change his opinion about what programming language to use. The Internet is awash in essays about C and C++. If you look, you can find an essay with just about any point of view imaginable. It isn't easy to change people's minds about the topic