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.


This session explores the strengths and weaknesses of different programming styles, patterns and paradigms across different programming languages, past and present.


Check out more of our talks at:
[ Ссылка ]
[ Ссылка ]

свернуть