2

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?

jwrush
  • 249
  • 1
  • 10
  • 4
    You should never document "what" your code do anyway. Document "why" only. – SK-logic Aug 21 '13 at 21:13
  • Touche. I have been dutifully rebuked. – jwrush Aug 21 '13 at 21:19
  • 2
    Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. – gnat Aug 21 '13 at 21:44
  • I think this question is too broad: there isn't any set of functional programming idioms that **any** programmer is supposed to know. So it depends on the background of the programmers you are working with. E.g., to an experienced Haskell programmer, your functional programming skills in C# might look very basic. If most of your team does not use functional programming idioms you should not force them to adopt them: the programming style should be a common denominator of what the members of the team are familiar with. – Giorgio Aug 21 '13 at 22:22
  • 1
    Note that the question isn't about what concepts they are "supposed" to know, but rather what concepts they can be "expected" to know -- IE, what can I use without having to worry that a reasonable programmer will understand what I was doing. And I think that's a fair question. (Just as there are concepts of procedural or logical programming one can assume any programmer will know.) The people who do maintenance on my code will not always be the team I currently have: I must, in some sense, write towards an imaginary audience. – jwrush Aug 21 '13 at 23:48
  • I added criteria that would require references. – jwrush Aug 23 '13 at 17:12
  • 1
    _"are there any empirical studies, accreditation criteria or best practices lists published..."_ - this site is not [about] being a proxy for a search engine – gnat Aug 23 '13 at 17:29
  • Question is no longer about whether the information exists, but if anyone has expert experience in using it; a verifiable fact not based upon opinion. – jwrush Aug 23 '13 at 17:42
  • Either the shortest most maintainable code wins, or you have to get a new job. – kevin cline Aug 23 '13 at 19:33

2 Answers2

10

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).

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • I do honestly think in this case that my excessive documentation isn't because the code itself is unreadable, but because I've lost trust. Under other circumstances I would think these areas would need little to no explanation. But this is a very good answer. – jwrush Aug 21 '13 at 21:22
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.

Community
  • 1
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • Any suggestion as to how I can convince them that they just don't know C#, when they think lambda functions are black magic? – jwrush Aug 21 '13 at 21:34
  • 2
    @jwrush: don't convince them they don't know C#: they can take it negatively. Instead, have a more diplomatic approach: ask them if they want to learn a hint about the way to optimize their code, then talk about things they don't know, but in a manner of a friendly discussion, not a lecture. – Arseni Mourzenko Aug 21 '13 at 21:58
  • @jwrush maybe warn them that there are few and getting fewer opportunities for .NET 2.0 developers (which is basically what they are) and that for the sake of their careers it would be smart to move into this decade sometime soon? – Carson63000 Aug 21 '13 at 22:26
  • 1
    @Carson63000: I do not think that one should learn a programming language feature for the sake of being "modern", but rather because they think that it provides a better solution. Saying that certain features have been in C# for a while is not a convincing argument. – Giorgio Aug 21 '13 at 22:30
  • @Giorgio: I didn't say they should learn these features for the sake of being "modern". I said they should learn these features for the sake of not shacking their career to technology that is seeing rapidly diminishing demand - and this (three major versions behind current release) subset of C# *is*. As an aside, I'd largely agree with your premise if we were talking about something genuinely *new* - but .NET 3.5 released nearly *six years* ago, and in my experience 3.5+ has been almost universally adopted because it *does* provide a better solution. – Carson63000 Aug 21 '13 at 23:38
  • @Carson63000: talking about career opportunities won't work neither. Since most programmers don't know how to program, and since most companies don't care and will simply hire the one who is ready to work for an inferior wage, it's maybe people who seek to increase their skills every day who should be afraid of not having any career opportunities (unless they are ready to accept low wages). – Arseni Mourzenko Aug 22 '13 at 06:31
  • @MainMa: well, I guess if you really believe that to be true, there's little to be gained by me trying to change your mind. – Carson63000 Aug 22 '13 at 22:12