Is it acceptable to use lambda functions\methods in business software?

Question

I've noticed posts on here demonstrating the use of delegates\lambda functions to solve the hole in the middle idea without a lot of repetition: http://www.markhneedham.com/blog/2009/04/04/functional-c-the-hole-in-the-middle-pattern/

The problem seems to be that junior developers and others don't necessarily understand what the function pointer\delegate\lambda function concept is, which seems to make reading (and possibly debugging) the code more difficult.

Should we avoid or severely limit the use of this tool in writing business software, especially in small team or sole developer shops?

Or is it acceptable to use it with appropriate comments and expect that when I'm no longer around that the next developer will understand or learn about lambda functions?

Answer 1

Yes, use them.

I am a junior developer, and I know/understand lambdas (and the other concepts you mentioned). There is nothing I could forsee preventing a junior developer from learning all of those concepts in a very short amount of time. Juniors may not have the same amount of experience/expertise when it comes to many gotchas of software development, however, concepts like lambdas can be just as easily understood by anyone with a basic understanding of programming and an internet connection. Also, it seems odd that you chose lambdas as the example, considering if you are using C# it is likely you do not even have that much of a head start on learning lambdas over the junior developers (they were only introduced in 2008, if I remember correctly).

In short, there is no need to dumb down your code for us neophytes. We will be just fine, and would actually prefer to work on the best possible implementation you can come up with. :)

Answer 2

The problem seems to be that junior developers and others don't necessarily understand what the function pointer\delegate\lambda function concept is

Quite frankly, that's their problem. That's what you ensure they have training for. You can't not use a good technique just because some people might not understand it. If they need help with it, they can come ask the author. More importantly, lambda functions are becoming extremely common language features.

Should we not use inheritance because some people don't understand it? Hell, some people refuse to believe in science or germs or any manner of ridiculous things. You have to be able to move on and not let the possibility that others won't be able to keep up with you stop you from writing the best code you can. Lambda functions are a great feature and greatly help in writing code, and you should take all the help you can get.

A developer should know how to use the language they're in- junior or not. If they don't, then fire them and find someone who does, or train them up so they do.

Answer 3

If they're a sensible solution to your problem then you should use them.

Don't artificially restrict yourself - you're more likely to end up with poor quality code that's hard to maintain.

If the code is well written with appropriate comments then those following on should be able to learn from you.

Answer 4

Put a link to the msdn documentation in comments at the top of a block that uses it then go ahead. You shouldn't be scared to use new/complex technology, its part of a developers job to learn things they don't know.

Answer 5

The problem seems to be that junior developers and others don't necessarily understand what the function pointer\delegate\lambda function concept is

Then they need to learn them. Period.

1. This is not an esoteric corner of C#. You must understand them to make use of many .Net libraries.
2. This is not an esoteric language topic, in general. Virtually every language in popular usage today has some flavor of function pointer, and most have (or are soon getting, in the case of Java and C++) closures.

Just take a few minutes to explain it to them. It's not hard.

Answer 6

You should use the right tool for the job. If there's a simpler, clearer way to solve the problem at hand, use that. If you need to get into something that you think might be an advanced topic for future maintainers, mark it clearly and include a pointer to documentation that explains the technique.

the function pointer\delegate\lambda function concept

It should be noted that those are three different things.

Answer 7

Two possible scenarios:

a) Your colleagues (or most of them) are reasonably skilled. They need to learn lambdas, they're part of the language, and sometimes, they are exactly the right tool for the job. So when they are indeed the best tool, by all means, use them. Just avoid using them because you've only just learned about them yourself and you're all excited and think they're a silver bullet.

b) You colleagues (or most of them) are incompetent. There is no way they're ever going to fully understand lambdas, closures, function pointers, or any other similar meta-coding concept. They're probably struggling to understand pointers, references, and recursion already. In this situation, the best you can do is bite the bullet, use a clumsy, verbose, lambda-free solution, and brush up your cv, because you should be job-hunting.

Answer 8

This is where consistency can help a lot. If you use it consistently with the same style, etc., then readers only have to learn it once, and then they recognize it everywhere.

Also, it might help to be explicit, at least at first. For instance, these two are equivalent:

doSomething(() => someMethod());

doSomething(someMethod);

private void doSomething(Action someAction) { ... }
private void someMethod() { ... }

... but in the first case, it's obvious, if you know the lambda syntax, what we're doing. Even if you don't know the lambda syntax, it's obvious you're seeing something new, and you have to look it up. In the second case, it kind of looks like you're passing a variable.

I know that ReSharper pushes you to change it to the second case, but I wonder if that's always a good idea. In the second case, you have to know that doSomething takes an Action.

Answer 9

itemsList.ForEach(item => DoAction(item));
...
public void DoAction(Item item) {
  //...do various things here...
}

Now, maybe here we are calling DoAction because its body is too long to fit within the lambda itself. In that case, using the ForEach() extension method to List doesn't give us a lot of benefit over using the regular foreach loop, though it does save a couple lines of code, I suppose. But in this particular case, using ForEach() may have lulled us into doing something that's actually taking more code, and causing some extra thrashing on the stack than necessary; The Argument Passed Does Not Need to Be a Lambda At All

You should simply call DoAction like this:

itemsList.ForEach(DoAction);

No Lambda at all. The key is to remember what it is you are really passing when you create a lambda expression: something of a shortcut to define a delegate instance. Yes, it also has benefits such as closure, but one should not lose site of what the method call is expecting. In this case, it's expecting an address to a method that matches the signature of Action. DoAction is already such a method, so creating the lambda is just adding in a totally unnecessary method call.

Answer 10

I often find certain concepts hard to understand because they're only described in the abstract, rather than encountering them in practical, real-life situations. So I'd personally be in favor of encountering such constructs.

The main scenario I can think of for avoiding doing this is if programming isn't the main task of the other person. For example, a system administrator, or a bioinformatician who spends most of their time doing actual experiments (a "lab rat").

Answer 11

IMHO, writing at any technical level higher than the technical level of the team, is wrong. If your team members are not really comfortable with lambda expressions and function and they don't have time to spend learning it (they should spend their time on performance tuning database, work on UI more, create components, etc.), then I strongly suggest not to use them. However, if they are willing to learn and have free time, or they already know the knowledge, then why not?

I think this is a relative issue that should be judged per team and team's technical level. And this is not only the case of lambda functions. This is the case of technical knowledge. So, for example whenever a team knows about repository pattern is has the expertise to implement and maintain it, then let'em do it. But if they don't, simply find another way. If they know about OO JavaScript, then let'em create more scalable code in JavaScript. But if they don't, simply get back to procedural JavaScript.