Unconnected ramblings on development, technology, business, security and more by a rambling engineer.
Archive · About the Site · About the Author · Contact Me
As a developer I’ve read an awful lot of books on programming,[1] I don’t remember the first programming book I ever read but I do remember it being about about Java programming. The other thing that sticks out in my mind about it was that it, like almost every other language specific programming book I’ve ever read since then, started by discussing “Programming Paradigms”.[2] At the time I just kind of skimmed through that part of the book, I wanted to get to the meat of how to make programs and impress my friends. Nowadays based on a lot of the discussions I see occurring in the programming language holy wars these days it seems like I wasn’t the only one who skipped the discussion of programming paradigms, or forgot it as soon as I graduated. It seems a lot of engineers dismiss paradigms as an abstract concept confined to the ivory tower of academia and not relevant to the dirty business of really writing software in the trenches. Throughout my career however as I have sought increase my abilities as a craftsman[3] I have come back to realize the power of understanding programming paradigms and have gained a profound recognition of how useful a tool the various programming paradigms really are in building solutions. Consequently, as result of my trailblazing through the thick underbrush of programming theory, I have decided to share my own learnings on what I’ve discovered and the understanding I have gained to help those that come after me that I may help some other poor soul that desires this same enlightenment.[4]
This series therefore is dedicated to helping developers gain a better understanding of what a programming paradigm is, what the point of the various programming paradigms are, and to help introduce individuals to idea of thinking in different paradigms. In it this series we’ll go over the four major programming paradigms Imperative, Functional, Object Oriented, and Declarative.[5] Each article will:
This first article will discuss some brief high level concepts which will will help guide our discussion in subsequent articles. At this point I would like to include a big disclaimer: This series is not going to be perfect and totally error free, these posts aren’t meant to act as the definitive end all be all discussion on all aspects of programming paradigms. This series is instead intended to help reflect the understanding I have gained at this point in my journey as an engineer; hopefully it will help some new engineer better grasp concepts that may have eluded them up until now or make someone one of today’s luck ten thousand[7]. My hope with this work as with everything I write, is that a year from now when I look back over this article I will think to myself “Man I was an idiot back then. how could I have been so ignorant?” because if I come back having the same understanding I do know, that means I have not learned anything since then and have remained stagnant.
With that disclaimer out of the way let’s get to the meat of this discussion.
The first and most important question to this series will be defining what a programming paradigm is, as this will set the stage for the rest of our discussion. From the evidence I have seen in my life up to this point when someone is asked what a programming paradigm there is some vague noncommittal remarks about programming paradigms being something related to languages, usually some vague comments on OOP, and then something about how one paradigm is better than another, or why language X is best because it supports multiple paradigms.[8] In many cases it seems like the discussion of programming paradigms ends up as just a super-set of the programming language holy wars about which language is the best[9]. So what is a programming paradigm and why do so many people struggle to provide a clear and concise definition? Let us start by decomposing the problem into multiple smaller problems that we can solve independently and see if that helps. First let’s define the term programming. Programming can broadly be defined as solving a problem by providing a set of instructions to be execute, in our particular case we are providing the instructions to a computing device.[10] The second problem is then to define the word paradigm; this is a more esoteric term that seems to be little more than a buzzword for management to rattle off in order to obfuscate their purposes[11], but the actual definition is “a framework containing the basic assumptions, ways of thinking, and methodology that are commonly accepted by members of a scientific community.”[12] Thus if we were to combine these terms an acceptable definition for programming paradigm would be. “The general framework, assumption and ways of thinking one uses to solve a problem when providing instructions for a computing device to execute.” or to restate it in a slightly more natural manner, a programming paradigm is the overall thought process one uses to solve a programming problem.
“Big whoop” I hear you say, “we’ve successfully managed to look in a dictionary what’s your point?” Although this doesn’t seem that profound of upon first hearing of the ideas, as one continues to reflect on it the implications become more apparent. What it means is that by changing the approach we take to solve a problem, we establish the fundamental thinking around the problem. This approach, or paradigm, that we subscribe to then proceeds to dictate almost everything else about the problem, it starts by how we define the problem, it determines what it means to “solve” the problem, it guides what steps we will take in our approach and how we will handle issues as they arise as well as laying out what constraints we will, consciously or unconsciously, labor under while attempting to write our code, it also provides a unifying vision of how our code will function. In short the programming paradigm we choose to adopt for any given problem will end up dictating what the ultimate destination is for our development efforts and will defines what “progress” even is.
At this point you may be skeptical, “I’ve gotten along so far in my career without learning all about this high-falutin’ paradigm nonsense, why should I learn it now?” a worthy question by a worthy adversary. The reason it behooves a developer to learn about programming paradigms is that provides us another tool in our mental toolbox to use when it comes time to perform our labor. The work of development is in large part mental and as such the tools that work to broaden our understanding will be of most use int he long run. The fancy new framework you learn today will probably be superseded five years from now by new tech[13], but understanding universal principles will reap benefits for years to come. That is where learning about programming paradigms fall, they are one of the fundamental principles that underlay any activity taken in software development. At this point you probably don’t even realize how much your current thinking and approach to solving various problems is impacted by the paradigm you are using, you may even think that you aren’t using a particular programming paradigm you’re just doing whatever works, in this case I’d ask you, “how’s the water today?”[14] Once one can understand and identify basic programming paradigms you’ll start to to see their impact on our daily work, in the tooling you use, the architectures you design and every other development activity that goes on around you; by so doing you will come to a deeper understanding of how to develop and use software, as you will be able to see otherwise implicit assumptions and recognize techniques that would otherwise have eldued the unaware eye. In short as your understanding of various programming paradigms increase, so will your ability to ability to make informated decisions as you will have a broader understanding of the issues at hand.
At the end of this series you will not be an expert in understanding each paradigm, in fact you won’t even really be able to use them, the only way to really be able to become a functional programmer, or an imperative programmer, or an OOP programmer is to live and breathe as one, work and toil, and eventually you’ll come to a point, probably ten years down the line[15], where it all just clicks and you’ll finally be able to understand what it means to develop in an OOP mindset, or you’ll see the world from a Functional perspective and then you will truly have mastered the paradigm. I’ll be posting the follow up posts shortly. Until next time I’ll see you soon and may you find lasting success and joy in all your endeavors.