A programmer’s story : Escaping the “bubble” of Imperative programming
Scope of the story
In this blog post you’ll find the story of my personal developer’s experience and what impact it had to adapt from a strong fundamental background of procedural programming to the “light” world of functional programming.
Disclaimer : I do not intend to compare the two programming paradigms as one being better than the other. I simply share my subjective experience (which could be very relatable if the reader also comes from a procedural programming background) by analyzing not only the difficulties, but also some of the helpful advantages that I noticed during my experience on a Full-Stack development project.
Technical introduction
In case a quick-refresh is needed on the programming paradigms and terminology used in this blog-post, I have put together a small introduction to the main topics that will be approached later on.
A programming paradigm is a classification representing a specific style of programming. It does not refer to the syntax used, but the way in which the algorithm is conceived and executed.
Procedural programming represents a programming model based upon the concept of calling a procedure. In this case, a procedure consist of a series of sequential computation steps that need to be carried out.
Functional programming on the other hand represents a programming model based upon the concept of writing mathematical functions. These functions receive input parameters and return an output and when the program is executed, this function is logically evaluated as needed.
Already analyzing these simple definitions we can deduct one of the main difference between these two paradigms is that the steps in a procedure are implicitly sequential. Whereas in functional programming, this is not implicit by default and you have to sync your algorithm’s steps, divide them or even completely rethink the algorithm.
And this is where my story begins, because I come from a procedural programming background…
My programming background
I started programming when I was around 8 years old, when my mother signed me up for an informatics club in primary school because she thought I was doing too much sport and I needed to also exercise my brain, not just my body.
It turned out to be one of the most inspiring and impactful decisions that my mother ever had on my life because from starting with drawings in Paint and storytelling in Microsoft Powerpoint, continuing with simple mathematical algorithms in Borland C++, and then 3 years later participating at the National Olympiad of Informatics in Romania where the goal was to create problem-solving algorithms in C++.
And that is where my procedural programming background started, from the problem-solving algorithms that I was coding as solutions for the informatics competitions that I was participating in.
I was taught to conceive and plan the algorithms from a procedural perspective, and I was almost always using a very well-known concept called “divide et impera” (Divide & Conquer). What this meant was to divide a huge problem into smaller problems that could be solved individually and then connect them all in a sequential order of steps, thus creating the logic of your algorithm.
And this paradigm helped me and guided my programming experience for a pretty long time… until, in my first year of University, I entered the world of Object-Oriented Programming (OOP)…
Discovering and studying OOP was a breakthrough experience for me because I was amazed by the fact that now I can not only design an algorithm, but I can also design an entire application by using these new means of encapsulating the data and the operations performed on it. Although, what I didn’t really understand at the time, is that they were both coming from the Imperative Programming principle, and thus I was applying the same fundamentals that I learned in procedural programming to create the algorithms and the business logic that was handling the Objects handled by my applications.
And this was not necessarily a bad thing, because from a scholar perspective my strong fundamentals help me a lot in understanding and applying Design Patterns on any scenario.
Whereas seeing my situation from a professional perspective, this meant that I could be a really good Backend developer, but I was captive in my own box of Imperative programming.
Opening my eyes
I called this chapter “Opening my eyes” because it refers to the moment when I first found the way out of my “Imperative bubble” that I was trapped in. And that was when I discovered the world of Full-Stack Development in my first part-time job as a Junior Developer.
The moment I first learned that a complex web application is usually designed with a separation between the backend and the frontend logic was a big eye-opener for me because I started putting myself a lot of questions :
“What really is the difference between them?”
“Which one am I good at?”
“Which one do I like more?”
“Are they different in terms of programming principles?”
And the last question is the one that popped the Imperative bubble I was trapped in and opened my eyes to the world of functional programming. And the way in which the answer to this question blossomed in my mind is when I moved from a Java framework (Spring Boot) to a Javascript framework (Angular).
Entering the world of async functions, Observable subscriptions, resolving Promises, handling events through Components… and so many other functional fundamentals made me realize that “the programming world is way bigger than the small Imperative house I was living in”… and this was not even the beginning, because I was still trying to design the logic of my algorithms in a sequential order, and even if it was difficult, this was not impossible.
But the moment I realized what functional programming truly means is when I went on a new project where even the backend stack was not based on a Java framework anymore… (calm down, try not to panic, panic a lot)
The project I am talking about was a Full-stack development project for a web application with a tech stack composed of Node JS and Angular, and this time I could not cheat with my procedural background anymore by moving all the business logic to the backend and creating more complex algorithms.
I had to actually learn to conceive the algorithms from a functional perspective and thus this brought me to the amazing world of utility functions like map(), sort(), filter() and many others.
Example : A cool example of one of the concepts that was really breakthrough for me is that I could replace my crazy stacks of for() iterations with simpler functional calls, easier to maintain and more efficient in asynchronous environments.
I know it might not look like huge difference for you if you already have a good level of programming experience in full-stack environments but bear in mind that not all programmers come from the same background and sometimes this might be the exact reason why yours or another developer’s solution might be considered “not good”, whereas in fact it is not really understood or applicable to the programming paradigm of your environment.
Conclusion
And as this whole post represents a story, then there should also be a moral to it so I can definitely say that I am truly grateful to have worked with some amazing senior developers on my past projects that knew the difference between having a wrong logic or having a wrong perspective. And what I learned from them I plan on sharing forward with these three main keynotes:
Programming experience nowadays is not a sequential algorithm anymore.
We don’t all come from the same background and thus people conceive their algorithms and solutions based on different fundamentals.
What is important is that we maintain an open mindset going into this new era of Software Development and embrace this versatility as it can lead to even more creative solutions and designs in the future.
