Origins

I first started learning to code more or less on a whim. I’d always been curious, but was held back by my unfounded conception that learning to code must begin with a mind-numbing slog of syntax memorization. I had no concept that a trained programmer could essentially understand code based on its structure, even with little or no prior exposure to the specific named functions and variables constituting the code.

Eventually my jealousy of all the tech wizardry surrounding me – at the time I was living in the Seattle area – got the better of me. A friend of mine expressed interest and we decided to take the plunge together, to both work through the same beginner’s coding tutorial online. But which language? There were so many to choose from.

My friend weighed the decision carefully. He investigated various options for their ease of use, versatility, novelty, etc. I suffered less indecision. I knew I wanted a language which would draw me in closer to the heart of the computer than the others. I cared not if it was 20 times harder to use, I wanted more control at a lower level. After a perfunctory period of pretending to weigh different options, I made my decision: I would learn C++.

The List

In my first heady months of learning to code, I was entranced with the idea of the linked list. What a perfect distillation of the computer’s raw power, that a list can exist in which the memory location of each element could be totally random and disjoint, and yet the list still affords the ability to iterate over the elements with ease. On top of that, a linked list can be sliced and diced and grown and shrunk in any which way and with no greater perturbation in memory than that to the individual elements themselves. How elegant. How flawless. What structure could possibly surpass the linked list.

So imagine my chagrin when I gradually became aware that the foundational data structure used in many dynamically resizable objects was the linked list’s arch nemesis, the contiguous array. What a vile, bloated structure; carelessly wasting space; wantonly occupying the processor by copying every element into new memory at unpredictable junctures. If ever there was a structure that lacked elegance, this was it. And for what reason might it be preferred? Multiplication-based indexing? I scoffed at the notion. How frequently can applications avoid iterating over every element anyway, I asked.

The Array

And yet for all my loathing of the resizable contiguous array, something began nagging at me early on in my coding journey. Ever so slowly, a nascent idea formed that maybe, just maybe, the contiguous array actually was a superior foundational data structure. Initially, the part of me that entertained this thought was the same part of me that liked to write triply, quadrupley, quintupley nested loops. Who cares if its impossible to read and maintain, it probably executes a tiny bit more efficiently than nested function calls, right? But my real paradigm shift, came only after I slowly developed a learned preference for simplicity in design above all else. This came through more hours spent debugging hopelessly convoluted code than I care to admit.

It was only after experiencing this paradigm shift, that I began to understand the true elegance of the contiguous array. It has some rough edges, as identified previously, but what convention for accessing any single element could be simpler than performing a single multiplication. The simplicity of this one inherent characteristic of the contiguous array opens up whole new worlds of possibility. Take logarithmic search and self-contained binary tree structure, for instance. Once I gained a rudimentary understanding of the greater efficiency of accessing locally contiguous memory contiguity, due to caching, I was sold on the superiority of the contiguous array.

Takeaways

As time has passed, I’ve come around more and more to the conclusion that it’s all good. Sometimes I want a linked list, and sometimes I want a contiguous array. As long as I’m waxing poetic, here are a few more tidbits of wisdom:

• Premature optimization is a terrible idea.
• If you want to worry about efficiency, worry about time complexity, not so much other stuff.
• Coding a complex solution is satisfying for a little while, until you have to debug it. Finding a simple solution in place of one that is complex is when coding is really fun.

Now that you’ve traveled with me through this brief text-based journey. Perhaps you are wondering, what was this post actually about? Not much, really. Just some of my reminiscence about my early history as a coder, using a couple basic data structures as milestones along the way. I enjoyed writing it, for what that is worth. If you were in the unenviable position of being compelled to read it, I hope it was tolerable. At any rate, thanks for reading. Cheers!