I started learning programming at age of 14. I was in high-school and the programming language did not really matter to me. For me it was all about algorithms and data structures as means to solving problems. Whether I was using FoxPro, Turbo Pascal or C, what it mattered was solving the problem and getting the results.
Then I went to the university and because of a series of unforeseen circumstances I ended up writing most of my solutions in Java. And it was all classes, interfaces and objects, OOP for short.
Almost my whole career was centered around the OOP way of solving problems. Even when I was writing JavaScript code, I was still stuck on classes , objects, fields and methods. It did not really occur to me that there was other way of thinking and designing my solutions anymore. OOP seemed so natural, it modeled real life objects and processes after all. But real life is most of the time inefficient and less than optimal, and real life solutions are based on things designs created by at least two generations before and propagated by adults that function based on the “it is known” principle. Because, after all, there is a risk involved in doing things differently, that most people prefer not to take. It is the “If it works, don’t fix it!” engineering principle.
Enter “Gica-Contra”, a Romanian term that describes people that “swim against the current”, people that feel compelled to be against the other 99%. This term has always been used by my mother to describe me because since I was a child I was quite rebellious and stubborn, and always felt the need to ask that damn question loathed by parents who thought parenting is easy: “Why?”. If you think this kind of attitude changes with age, you are mistaken. I have become the kind of adult that does the following:
- asks “Are you sure?”
- says “Let me double-check that!”
- says “Neah, there must be a different/easier way to do this!”
- asks “But, what if …?”
- asks “But how do you really know?”
- says “If too many people have the same view on this, there is something shady about it.”
- and many more.
And all that my friends, translates to a single term: skeptic.
Being so stuck on OOP, I was quite skeptical about functional programming. And rightfully so, as the only programming language I could associate it to was Turbo Pascal, and suffice to say, I did not like Turbo Pascal very much. Also there is so much hype about functional programming nowadays, that it tingles my Gica-Contra sense a little bit too much. And that’s the thing that got me worried. I’ve always considered my skepticism as a superpower, as the fuel for my out-of-the box thinking engine. But when it came to functional programming, it kept me from even taking it into consideration, it kept me in the dark. And that’s when it hit me: I was behaving exactly like the traditionalists and conservative narrow minded humans that I’ve always claimed to despise.
This had to change. I needed to come into the light. Thankfully I now work for a company that pays for independent study, we have 10 training days per year, when you are payed just to study whatever you are curious about and the conclusion of those days must be shared with your colleagues via a blog post or presentation. So I took advantage of my first training day to start learning Kotlin. And it was mind-blowing. Especially since one day earlier I also participated to a Scala workshop that went very well. All of a sudden, there was all this new information coming from comparing the two languages. It’s like the fog was lifted from my eyes and I finally could see the power and the versatility of functional programming.
And most of all, I could see the practical side of it. Solutions that needed 20 lines of code to be implemented in Java, needed only 2 lines in Kotlin, and surprisingly, they were still readable. Almost the same in Scala. Come to think of it, I have been bothered for a while by all the boilerplate code required in Java to fit the OOP principles and some coding conventions that nobody asked me about. All these getters and setters, all the bloody curly braces and all the NPEs… Kotlin and Scala reduce that. And funny enough Java is going in that direction as well, I mean with modules, you might as well just declare your fields public and avoid writing setters and getters, because if the class is not in an exported package you have nothing to worry about.
So yeah, interesting times are coming. No worries, I’ll keep you in the loop. ;)
Stay safe, stay happy!
