Challenge your mindset and escape the Pensée Unique

In recent years I’ve been quite involved in alternative thinking and new ways of understanding our world, and many times I had to change my worldview because some underlying core belief I had was challenged. And this is not easy, because once you take the red pill, you’re on your own. When you no longer follow the mainstream point of view, you run the risk of being pointed at and rejected as being too different. This hits some critical spots in the Maslow pyramid: the sense of belonging and self-esteem, which works both ways: refraining people from leaving the pack, and rejecting people threatening the cohesiveness of the pack (antibodies) when they leave. And this has been going on for ages, remember Galileo’s story?

The interesting part is that this process of deconstructing my core beliefs also happened in the domain of software engineering. OOAD, UML, and Java were my daily bread, until I started to act on my intuition that something was not quite right, and there had to be other ways. In my search for something else I tried Groovy, and it did give me a sense of freshness and new powers, but not for long, it wasn’t life changing. I was yearning for more and this is when I understood I needed to look into other languages such as Scala and Clojure. The choice between both was easy for me: choose the one that is the most different to what I was used to! Also because comparisons such as the one below really makes you wonder.

In Java:

public class StringUtils {
    public static boolean isBlank(String str) {
        int strLen;
        if (str == null || (strLen = str.length()) == 0) {
            return true;
        }
        for (int i = 0; i < strLen; i++) {
            if ((Character.isWhitespace(str.charAt(i)) == false)) {
                return false;
            }
        }
        return true;
    }
}

In Clojure:

(defn blank? [s]
  (every? #(Character/isWhitespace %) s))

But I reckon choosing Clojure, a dynamic FP language, is not the typical choice for an OO/Java developer.

Engineers often choose a programming languages based on mindset

During a lunch with other software developers I asked around, for fun, to choose between Clojure or Scala. As expected those with a Java background favored Scala. Those that had Javascript or Ruby but no Java experience around the table had no clue, but when explained the difference between both they admitted their preference for a dynamically typed language like Clojure. To me this means language choice is not so much about technical merits, which it should really, but more often about mindset: OO vs. FP, static vs. dynamic, IDE vs. text editor, long loading or compilation vs. fast feedback loop (run/repl/reloading, etc.), etc.

In other words people choosing Clojure are typically already using a dynamic language for which text editors suffice. This certainly contributes to the fact that a good part of the Clojure community is made up of Ruby developers¹. Those choosing Scala are typically attached to OO, static typing, and IDEs². Overall in both cases it’s about staying in one’s comfort zone and not moving too much out of it.

This generalisation is definitely a caricature, I know. The reason I emphasise it is because I’d like to reflect on the underlying mindsets which are so strong that engineers often prefer choosing a programming language based on beliefs, prejudice, or affinity, rather than its technical merits such as its conciseness, expressiveness, lack of ceremony (signal/noise ratio), or how easy it is to shoot oneself in the foot.

What mindsets?

So what mindsets are involved when choosing between Clojure or Scala, or dynamic vs. statically typed languages?

I would argue static typing and OO corresponds to a structural mindset where the world is viewed in terms of boxes, meaning everything must fit into a box and boxes can aggregate and have relationships. Everything is an object that eventually should fit into categories or types. In UML this corresponds to the static views embodied by structure diagrams such as class diagrams, object diagrams, component diagrams. They are called static views because they represent a structure valid either at any point in time (e.g. a class diagram) or at a specific point in time (object diagram). None of these diagrams represent how things change or interact over time, there is no timeline. So in this mindset, the structural mindset, we find developers that prefer to analyse things in terms of structure, that’s what they focus on when designing and programming, which is what OO and static typing offer.

The other mindset is based on process, on how things flow and work together over time. In UML this corresponds to the behavioral diagrams where a time dimension is either explicitly there (sequence diagram) or implicit in the flow being represented (e.g. activity diagram, state diagram)³. The main point is that time is an integral part of the view. In this mindset the focus is on the dynamic and the flow rather than the structure: the dynamics of the program behavior (functions) and how they are threaded together, or the flow of data moving around the program, or even the developer flow when the language allows quick feedback cycles. Developers in this mindset tend to prefer dynamic languages and the functional programming style⁴.

Some may see in the above distinction another debatable attempt to categorise things. It’s the structural mindset trying to put things into boxes, right? What would the process mindset say then? In terms of flow and interactions I’d say both mindsets are needed and there needs to be a flow between both perspectives. Just like in UML where both types of diagrams are needed to build a richer picture of a system or domain, one needs to think both in terms of structure and process in order to build better software.

Pensée Unique

Formulated in this way, it’s clear process and structure mindsets are both needed, it’s like the positive and negative polarities, or the masculine and feminine, both are required and should interplay in order to achieve a certain balance, right? Nothing is really new here. It’s another instance of the classic process vs. structure duality. The real challenge however is in the balancing of both: our industry has focused too much on the structural approach by pushing the OO mindset so far it has become a pensée unique⁵.

Maybe this is because OO found its killer app with the GUI toolkits that became increasingly popular as personal computers sales were exploding. I mean GUI building is a domain where structure is so predominant and so much in your face, literally, that it’s no wonder that OO found its natural habitat in that domain⁶. Perhaps it’s the update in place (mutability) approach that continued from the time of scarce computing resources (limited memory and disk space) that made OO quite popular with its “encapsulation” concept. Whatever the reasons are I think we now are in a situation in this industry where a whole section of the software development community, mainly the Java community, is entirely on another planet from another section, to the point where some don’t even understand each other. I’ve been involved a lot in recruiting and interviewing lately and this has become so evident to me. Even with Scala and Clojure being around, and with Java getting more functional by the years, a majority of Java developers still do not know what FP is, and only swear by OO.

What can we do about this?

Well I can only speak from experience: don’t be afraid of changing your mindset and of leaving your comfort zone! Really, it’s that simple, not easy but simple. The rewards are plenty. It’s like those people that speak multiple languages, it opens their minds to different ways of capturing reality. It makes you a better software engineer. It’s like being high on continuous improvements: once you take the red pill, you understand that no single belief can remain unchallenged, there are always different truths, and there is no status quo. So you keep digging and improving.

If you want to enlarge your mindset then I definitely recommend watching some video presentations by Rich Hickey, which are easily found on the net. After years of C++, C#, and Java applied to various fields including broadcasting (isn’t that Sky’s business?), Rich realised he was painfully doing it wrong for 20 years. The shock of having wasted so much time was so great he took a sabbatical for 3 years and created Clojure⁷. Therefore all of his talks are really recommended in terms of their eye opening effect, in particular:

• Are we There Yet? A 2009 talk where Rich explains why OO has its limits and why he wrote Clojure.
• Simple Made Easy In the first talk mentioned above Rich interchangeably used the words simple and easy, but later he must have realised they meant different things, so he created a whole talk about this ⁸. Continuous improvements at play ;)
• The Value of Values Ever wondered about why a future version of Java may get Value Types?
• Hammock Driven Development Rich relates his experience in creating Clojure and solving problems, really good talk even if you’re not developing software.

Most of his talks do not require Java or Clojure experience, and are really recommended to all developers in all languages really. In fact rock stars in the Clojure community are well known for their great talks at various conferences⁹.

I’m still preparing a brown bag session about Clojure, but before I do so I think it would be really good to view some of these videos above.

Happy viewing and challenging mindset!

– Francois Rey