Conclusion of Exercises in Programming Style

First, I must acknowledge I didn’t go through all the chapters of the book, even though I read them. There are several reasons for that.

For example, a chapter is dedicated to adding types to Python. Since Python is a dynamically-typed language, that makes a lot of sense. On the opposite, if one is programming using a statically-typed language, one is automatically covered. In some of the earlier chapters, the Any type is used to implement the solution because types are more a hindrance than a help.

Also, a couple of chapters are devoted to handling failure. For example, one is about checking the validity of the input, and throwing an exception that bubbles up to the top of the call stack if it’s not valid. Again, I think that most JVM developers are pretty familiar with this concept. Another chapter returns default values instead. IMHO, this is not interesting enough to write a complete post about it.

Finally, the before-last chapter is about writing a GUI on top, while the last one focuses on REST calls: I didn’t find much value in that, but of course nothing prevents you from implementing those.

My first programming language was BASIC, and though I was young, its structure shaped my way to understand the flow of a program. When I later learned Pascal in the university, it was a completely different way to write code:

It took quite some time to get used to this new approach, but in the end, it became the way. Interestingly enough, I believe I could still write some simple BASIC program if I wanted, but that would definitely feel weird.

Afterwards, I was taught C and C++. While C was similar to Pascal, C++ introduced the notion of Object-Oriented Programming. I didn’t understand related concepts in lessons: as of today, I still believe that C++ is not the right language to teach OOP concepts. However, during my internship, I read a lot about OOP and it all clicked together. It seemed so simple, even natural.

When I was much later introduced to Functional Programming in the Coursera’s Scala course, it took me a while to familiarize myself with this new approach. I have to admit I didn’t retain everything from the course, but the notions of immutability and side-effects surely changed my way to code Java.

That digression about my path on learning code leads us to this: from my perspective, it seems that the current trend in the world of programming is about OOP losing traction in favor of FP. Practitioners of OOP try to keep it on top, while practitioners proselitize its usage. This in general leads to sterile "debates" (read fights) where there’s a lot more dogmatism than pragmatism.

I hope this series proved that there are lot more styles than just OOP and FP. I hope it also introduced you dear readers to some style you didn’t know about - I for sure learned a lot. Finally, I hope that it showed that styles can be combined together: for example, objects don’t need to be mutable, and while they have state, this state doesn’t need to change. Exception handling and types that I mentioned above can be used in all styles.

Above all, remember that there’s so single one-size fits all solution to a problem in regard to a context. If that would be the case, then the said solution would have won because of its evident superiority. Since it’s not the case, then the context probably plays a huge role in the relevance of a style.

I’ve probably written it a thousand times before, but let’s write it once more just to be sure the message is clear enough: the more tools in one’s toolbelt, the more adequate the tool one has for a specific job.

This is the 20^th post in the Exercises in Programming Style focus series.Other posts include: