Change Displayed Text SizeGrow Displayed Text SizeShrink Displayed Text Size
 

Monday, February 23, 2004

Old School

Old School.

Recently I've become more aware of just how "old school" my programming experience and techniques are. I have a heavy background in C (and even in assembly), which formed the foundation of most of my programming experience - even though long before I knew any C, I was up to my eyeballs in LISP, Logo, BASIC, and other ancient but high level languages.

Almost all of the programmers I know professionally now have no C experience. To me, Perl, PHP, and HTML are not "real" programming languages. They're scripting languages. Put the average Perl programmer in front of an actual C (or Java) program and they will be hopelessly lost. I have nothing against Perl programmers, I'm just saying that working with a scripting language is very different than working with a compiled language.

Reading [this] brought this back to the forefront of my mind. Some of the author's comments are thoughtful, but some of them stood out to me as being very "new school". Yes, it kinda sucks that C doesn't have it's own String types, but C wasn't really made for working with strings. LISP was, Java was, Perl was. C was not. C++ tried to be everything to everyone, and has String functions up the wazoo, but that doesn't make up for how bad C++ is (after all, C++ is just an extension to C).

If anything, learning C makes you a better programmer. Yes, you can blow up the whole system with a type-o. Sure, you can do very, very bad things. Call it negative reinforcement. A lot of my time working in C was on the classic MacOS. Under MacOS 7.x, you certainly didn't have protected memory and other niceties of a "modern" operating system. When you screwed up, even in fairly innocent ways, you'd lock up the machine. Macsbug was your friend, even if the only shell commands you knew were "rs" and "es". Believe me, I screwed up all over the place. I often said my job was "finding new and interesting ways to hose the machine" because it really was.

Knowing that if you screw up, you're going to spend the next half hour or so rebooting and recovering can make you pay more attention. It really makes you see the wisdom of "measure twice, cut once". I got into the habit of doing things like making sure there was enough free memory before I allocated some. Checking to see if a file was writable before I opened it. Not doing things like making casts, assuming a pointer contained what I thought it did, and other things. I looked for functions to return status or error codes.

Now a few years later I still program that way, though not in C (I do very little C programming these days). In the past few months, on MacOS X and on BeOS I've had to port some C and C++ code over from POSIX, BeOS, etc. to the target platform. Some of the things I see in other people's code really gets me scratching my head (particularly, in C++). There are some people out there who probably have a nice little certificate hanging on their wall that says they got some degree or took a course or whatever, but it's plain from their code that they didn't learn much of anything. Just because the compiler lets you build it doesn't mean it was a good idea.

Anyway, I'm rambling. The point here is that I'm of the very old school - I prefer strongly typed languages where it's very much my responsibility to be aware of what's going on under the hood. In contrast, a lot of the code I see being produced today, and the people writing it, see the machine as black box that does magic for them. Or maybe they just don't know, or care, what's going on under the hood as long as they get their paycheck.

2/23/2004 06:03:00 PM ] [  0 comments  ]
[archives]
A good quick laugh