I recently wrote something on Twitter. Yeah, just like everyone. But unlike the rest, I told I started to like writing C code.

The reason (that's right, I didn't lie or joke about it) is a simple interpreter I wrote a few days ago. Despite the lack of serious C knowledge and the intended simplification of this little challenge, it was somewhat eye-opening in terms of algorithm development. Before I step further in what I've done, here's the code:

http://codepad.org/CxRlN2id (sorry about the misaligned code, spacebar Nazis messed up my style with size 8 tabs)

First thing you should notice is the simplicity - a struct with 4 variables, fixed-size buffers, asserts. If your question is "why", my answer is this: I want to keep it real, as much as possible. This point marks the beginning of my rant.

---

Where have you seen a variable name that is bigger than 32 characters? Enterprise code, perhaps. The one and only source of pure bullshit, unfiltered. Where have you seen a coding example that uses more than 32 variables? Exactly, almost nowhere. If there's one thing you could blame me for, it could only be me being incredibly generous. 7 variables with names of size 1 is what I actually use there. But since this app's code uses just a little over 2 kB of memory, and since this is just a proof of concept AND since I'm already doing better than most developers, I allowed myself to be a little generous with the memory.

Yes, I think most programmers are too busy thinking about what might happen, all those "What If?" and "Perhaps I Should...?". And yes, I think they really shouldn't be. If there's one thing they should think about other than things you must do, it's only "Can I Simplify This?" or "Can I Avoid Some of This?". If we look at my code again, you will probably see one fancy, superb, universal (and I could go on and on..) structure called "buffer"...

When we think about data structures, we tend to think in terms of collections of objects or linked structures that contain objects. The common thing: everything revolves around objects. O-O-fucking-P. There are many ways to use this concept and that's the problem - people tend to assume it's good for everything. For development of high-performance, low-level stuff - it isn't. And this is why I like C - it makes you think twice about making an object. Because C code size is somewhat related to performance of that code.

Getting back to the "buffer" example, you will probably notice (I wasn't trying to hide it, you know) that all I use is buffers. It's somewhat closer (if not exactly) to the C way of writing code. There are two major buffers that I use - the variable name buffer and the operation buffer.

Variable name buffer goes like this: "nameA=nameB=nameC=<random data>", there are <varcount> variables and therefore <varcount> variable name endings, '='. Since I was also learning the C way, you'll see slightly more code than there needs be for handling of such buffers (no need to keep the null value at the end). The algorithms for handling buffers like these are simple. The character '=' is used because variable names are guaranteed, one-hundred-percent, not to have it. Expressions use the symbol so variables can't. And it's not like they need it.

Operation buffer is simply a limited text string. Since I didn't want to start big (adding a tokenizer to the list of my problems is too much to ask for from a learning-to-C programmer like myself), I gave each "token" (remember, not an actual object in the code) obvious lists of characters (numbers for numbers, y'know) that do not overlap. Which makes it easy to detect tokens from character types. Everything went somewhat naturally from that point which gave me confidence that the design was OK.

So here's a conclusion for the end: we need to have an edge in our worlds, some limits that guide us. Can't keep the world round, huge or infinite. I understand that it takes a lot to break out of that comfort zone where everything is seemingly infinite, unlimited, possible. Nothing ever is. Keeping it real is about knowing your limits and staying below or facing the consequences.

As I'm in the process of learning to write all kinds of C code, I'm also in the process of building a scripting engine. That task isn't easy, I've already failed countless times. But this project, this step I've taken... it feels right. With limits, I know where to go...