Object-oriented – Which paradigm to use for writing chess engine

do you also tend to select a preferred programming paradigm when coding and stick to it, or do you tend to explore more and mix different paradigms?

• Constantly exploring alternative solutions makes you a better programmer. You must be aware of available tools, it doesn't mean that you have to use them each time.

• Mixing paradigms is fine as long as it doesn't have a negative impact on quality of your code.

If you mix different paradigms, do you have the feeling that there is some overhead in terms of how fast you can write and debug code (added complexity, switching between different mindsets) or is it just a matter of learning how to do it and then you can even be more productive?

• If this is your project and nobody else will work on it, then it's absolutely fine. It might cost you later, but the good thing is that it won't affect anybody else.

• Generally, I think that teams will try not to use multi-paradigm as it is likely to have a negative impact on team's productivity. On other hand, experimenting, such as going from one paradigm to another is a great way to learn.

Or do you mix different paradigms in a more structured way, e.g. you apply each paradigm to a specific class of problems (e.g. functional for queries, object-oriented for architectural aspects, and so on)?

• No matter what you do, you need to plan for it and think what effect it might have in future. Therefore, yes, whatever you decide to do, it must be structured and planned for.

• My team has agreed on code guidelines and we have always been using these guidelines with very little if any paradigm-shifts. We also have tools that enforce these guidelines. In your specific example, ReSharper would suggest us to convert a foreach statement into a more readable LINQ statement.

To summarise, I think that exploring paradigm-shifts is a great way to learn, but it should be strictly controlled in a work environment.

Mutable state is easily avoidable using immutable objects. In the same way, global variables are usually the choice of the developer (or a poorly implemented framework).

This being said, you may also want to use additional functional paradigms in non-functional languages. It's all about the expressiveness of your code. If you see that a list comprehension in Python makes your code easy, go for it. If you find it more readable in a particular case to have an immutable structure used through method chaining, great.

But don't forget, some people find imperative variants easier than functional ones, even if it means writing three times the original LOC and risking to introduce subtle bugs. More importantly, some programmers don't understand the basic concepts. Many C# programmers struggle with lazy evaluation and are completely unable to explain why, if you take an IEnumerable<T> which returns a bunch of elements from the database and you first count the number of elements, then loop through them, there would be not one, but two queries to the database. I'm not even talking about monads and other concepts which are mostly unused in mainstream non-functional languages.

Also, don't worry that you won't work with functional languages. Non-functional languages tend to be inspired the last few years by functional ones. C# is a great example. Python and JavaScript are two other mainstream languages which tend to introduce more and more functional aspects in them. In essence, any language which support lazy evaluation and lambda expressions is a good candidate for functional-style code.