Programming Paradigms Lost

It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a programming paradigm also represents a way of thinking. Having only one way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving; it contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.

Many developers hold too narrow a view of a paradigm. For instance, the idea that using lambdas are specific to functional programming, and that if you’re using them then you must be doing functional programming — although true that if you’re functional programming you’ll be using lambdas, the converse is not true. Perhaps even more problematic than being stuck with a narrow view of a paradigm, is being stuck with a dysfunctional view of a paradigm. For instance, many developers working in languages and frameworks that support object orientation lack a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.

Video producer: