Dammit, I used to be good at this...
So here I sit, working on my generalized version of the pathfinding code. The original that I blogged about was both inefficient, leaked memory, and only worked for the very simple map I had created.

I want a pathing program that is flexable enough to work with whatever I throw at it. And I want it to be very portable and usable for almost any environment, so I'm coding it in straight C.

A flexible pathfinder. Working with unknown map types. Using lists or trees that also have to deal with any kind of data.

In C.

If any Real Programmers are reading this, they're probably yelling at the screen, "You fool! Your dealing with objects! That code should be object-oriented. Save yourself the pain and use a better language! Fool! Amature! Naive amature!"

Well... what are my alternatives? C++?

C++ and I go waaay back. When I first met C++ I thought it was the greatest, bestest programming language ever! All the familarity of C with all the coolness of object-oriented programming! My first C++ programs showed me a brand new world, and I was smitten. As my programs got more complicated, I started having troubles. "No problem!", I thought. As I learn more of the language, this too shall pass.

I even got into an argument with my Computer Science professor (CS 101) about it. He hated C++. Thought it was an abomination. I thought he was just from an earlier generation of computer scientists that just couldn't see this Wonderful New World that had overtaken their stodgy, ancient ideas.

(Any Real Programmers reading this are probably laughing their asses off at my expense. And they have every right to.)

It wasn't until I worked for Real Networks that the curtains of infatuation were ripped down and I got my first view of The Truth About C++. Real had this tendancy to hire brilliant programmers. I felt like a fraud just walking among them. For the first time in my life I met coders that I would assign the title "Master". They were that good.

Then I was thrown into the abyss of the RealPlayer source code.

See, here's the thing... pure object-oriented programming in C++ is insane. When you throw away the last threads of pure C and work with a fully object-oriented programming model in C++... well, it's difficult to describe to someone who's never used C++ this way. Most C++ coders who still like the language mainly write C code with a few useful snippets of C++ thrown in. They don't know, as I know now, the madness that lies down that path.

At Real, I would work on the source code, putting in my assigned tasks and thinking, "This codebase is madness! MADNESS!! There has to be a better way to implement this particular thing I'm looking at!"

Then I would go home and try to work out a better model.

What I would wind up with would be almost exactly like what they had already written, but more clunky and less flexable. That "insane" code I had seen that day at work was actually the best possible solution. It was written by Masters, after all. I was not better than them because they were "brilliant", whereas I am merely "smart".

This, my friends, is when The Truth About C++ began to reveal itself to me. I was enlightened.

Crap. So C++ is out. What else could I use? Objective-C? It's the native language of the Macintosh now, but you don't see it on many other platforms. My code would be far less portable and tied to this one system. I also don't know how much overhead it would add to the pathfinding code, especially since I'm very new to Objective-C and don't really know how to wield it correctly.

C#? Started out as a Windows-only thing but it's been implemented for Unix (and thus all newer Macs that run OS X). But I've used C# in my last programming job and there are things about it that bug me.

I don't know Lisp or Smalltalk, and I don't know if those languages are fast enough for the uses I'm going to be putting my pathfinding code to. Nor do I know if they're even well-suited for the task.

So C it is.

This, of course, brings along its own problems. What part of the program owns what memory? What if two or more parts of the program use it? Which part is responsible for finally freeing the memory when it's no longer needed? If I'm dealing with data of an unknown type, how do I work with it?

My first stab at this project had me writing what basically amounted to an object-oriented framework for C, only without type-checking and adding data and code overhead (therefore being both slower and using more memory). I might as well use C++ if I'm going to go down that path. And I am not going down that path. Never again will I go down that path.

Ironically enough, this is forcing me to become a Real Programmer. At least for the C programming language. It's been so long since I did any actual programming that I can feel my brain stretching. I have to take breaks because my brain gets tired. And I can feel myself getting better at this. Piece by piece. Bit by bit (punny!).

So it's cool. My stint as a professional programmer both burned me out on programming and also totally destroyed my ability to write good software. True programming is an art form. In the "real world" you just have to get the code out the door under deadline, no matter how sloppy or ugly it is, and just hope that the client never uses it under conditions where any hidden bugs will make it explode and dump core / segfault / general-protection-fault / halt-and-catch-fire.

But now it's just me and the machine. No deadlines. I can take the time to try to craft the code, instead of just slapping down something that works under simplified test cases. It's fun again!

My code is still... I would consider it functional and sort of elegant, but still merely "okay". I still have a long ways to go in regaining my former skills (and hopefully surpassing them), but for the first time in years, I'm looking forward to it.