Conclusion of Exercises in Programming Style

Over the course of the last several months, we worked through chapters of the Exercises in Programming Style book. Each chapter proposes a different style to solve the same problem - counting the words of a text sample. The book uses Python to achieve that, while I used Kotlin.

Now, everything has to come to an end. And yet, before writing about other subjects, I’d like to dedicate this week’s post to some general thoughts.

The lost chapters

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.

A bit about me

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:

  • Code could be factored into functions
  • Flow was not based on the order it was written, but explicitly called

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.

There’s no place like the present

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 20th post in the Exercises in Programming Style focus series.Other posts include:

  1. Introducing Exercises in Programming Style
  2. Exercises in Programming Style, stacking things up
  3. Exercises in Programming Style, Kwisatz Haderach-style
  4. Exercises in Programming Style, recursion
  5. Exercises in Programming Style with higher-order functions
  6. Composing Exercises in Programming Style
  7. Exercises in Programming Style, back to Object-Oriented Programming
  8. Exercises in Programming Style: maps are objects too
  9. Exercises in Programming Style: Event-Driven Programming
  10. Exercises in Programming Style and the Event Bus
  11. Reflecting over Exercises in Programming Style
  12. Exercises in Aspect-Oriented Programming Style
  13. Exercises in Programming Style: FP & I/O
  14. Exercises in Relational Database Style
  15. Exercises in Programming Style: spreadsheets
  16. Exercises in Concurrent Programming Style
  17. Exercises in Programming Style: sharing data among threads
  18. Exercises in Programming Style with Hazelcast
  19. Exercises in MapReduce Style
  20. Conclusion of Exercises in Programming Style (this post)
The complete source code for this post can be found on Github.
Nicolas Fränkel

Nicolas Fränkel

Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Also double as a trainer and triples as a book author.

Read More
Conclusion of Exercises in Programming Style
Share this