How much functional programming expertise can programmers be expected to have?

Question

I'm coding in a non-functional language with functional mechanisms (C# to be specific, but you could substitute, say C++ and use function pointers, or what have you) on a small team. It's my habit to use functional techniques -- passing delegates (objects representing functions) as arguments, using closures, occasional anonymous functions, etc -- and I try to document this better than I think a reasonable programmer would need them documented. Looking at code I see online and on Stack Exchange communities, I think my style is pretty normal among C# developers.

Our team, however, isn't sophisticated in these techniques and I end up having to explain (and defend) myself -- my high level of documentation is actually used as evidence by them that I shouldn't code the way I do for the sake of readability.

Now, given the make-up of my team, I understand that I might just give up the good fight here and code to their standards, understanding its better for the team. Does anyone have successful experience using empirical studies, accreditation criteria or best practices lists published by respectable sources that suggest that programmers today have more experience in these functional programming idioms, and that, therefore, we don't need to shy away from them for purposes of maintainability?

Answer 1

I would expect any professional C# or web developer in 2013 to be familiar with anonymous functions, closure basics, and the concept of passing methods around. .NET 3.5 has been out for years now, and should be pervasive.

I would expect most professional developers (of any sort) to understand other tangential concepts to functional programming like immutability and pure functions, and how these apply to program design. These concepts too have been around in mainstream programming for ages (and more prevalently in the past 5 or so).

That said, I would not be surprised if more than half of applicable professional developers were completely oblivious to these concepts - and you are largely correct that you should conform to what is best for the team, just like they're largely correct that high levels of documentation is a smell towards unreadable code.

So conform for now and work at training people up, likely through some combination of explicit training and gradual use of more complicated functional structures (where appropriate).

Answer 2

In C#, functional programming is a proper tool when you have to navigate through collections. In those cases, functional programming makes the code much shorter and helps focusing on the problem instead of its implementation, while reducing the risk of making mistakes.

You can hardly be accountable of reducing the codebase and the margin for errors by using a proper tool.

The issue you have with your colleagues, I have it in the company I'm currently working in. Most programmers there don't know very well neither C#, nor programming in general, which makes me a not so popular person, given that my colleagues have a hard time understanding the code which uses parallel programming, functional paradigms, code contracts and other features of .NET Framework.

One of the rules each developer should follow is that their code should be understandable in a given context. This conflicts with the fact that one shouldn't be forced to reduce code quality just because he works with unskilled people.

There are two solutions:

1. Teach your colleagues functional programming and other things you know and they don't, trying to increase their level at yours. This is what I've chosen in my case and what I would suggest to anyone.

   Pros: the quality of the codebase will only increase, and you may appreciate better to work with more skilled colleagues.

   Cons: many programmers don't want to learn things. They work for money, and they don't care about their work. Trying to teach them anything would be an extremely difficult task and one should be ready to receive heavy resistance.

2. Start writing crappy code written for beginners. Given that this may be disastrous for the motivation, this solution should be taken only when working with people who are unable and/or unwilling to learn and in a circumstance when you can quit soon.

   Pros: this can enhance relations with coworkers if they don't want to learn things and don't want to make effort reading your code.

   Cons: this will decrease the quality of the codebase. Working on badly done projects which would inevitably fail is not very motivating.

Finally, should programmers know functional programming? It depends. It would be mandatory for any person who works daily with C# to know what are anonymous types and lambda expressions and how to use them in C#; on the other hand, I wouldn't say that the same person who don't know what a monad is should be treated as an incompetent.

The difference is that anonymous types and lambda expressions are the inherent part of C# nowadays, while the term monad doesn't exist in C# world.

On the other hand, I'm expecting a developer to be familiar to functional programming concepts like monads, even if this developer never used them. This is because developers are expected not only to write code in a given language, but have enough general culture and curiosity beyond the tools they use daily.