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