Why should I care if functions can be "first class objects"?

[Bert Bates]

I'm editing a few functional-programming related books that are all quite proud of the idea that functions can be "first class objects". So, for instance, you can pass a function as an argument.

This is also one of the big ideas in Java 8 correct? The so-called "lambda" release?

Here's my question: who cares? The closest I've been able to come is that this is a concise way to implement the strategy pattern... is that it?

[E Armitage]

You can separate the function from the function execution environment when clients invoke it through a delegate (as in Command)?
You could collect them into a Collection and queue them too?
Functional composition becomes easier and more intuitive to implement?

[Jayesh A Lalwani]

From speaking to people who have studied in fields that required a lot of math, and now develop software for a living, first class functions are gaining traction because syntactically they are closer to how mathematicians work. Yes, it is really a short hand way of creating an anonymous class. However, from the usability POV, the differrence is analogous to difference between doing this

a = Math.mod(b,c)

and this

a = b%c

Both option are exactly the same from a programming POV. However, the second option is cleaner to read, and more importantly, makes sense for your target audience. It takes focus off the language.

Taking simple algebriac examples, when a mathemtician says

y = x^2 + 4x + 3

The variable x can be a constant, a value, or a function. Mathematically, it doesn't make a differrence that x = 2, or x = m or x = f(m). Right now, in Java, there is a remarkable differrence in syntax when you want to support the third option, and having to support all 3 options makes the code harder to read

[Jimmy Clark]

Right now, in Java, there is a remarkable differrence in syntax when you want to support the third option, and having to support all 3 options makes the code harder to read

In this context, the concept of something being "harder" is subjective. What some individuals might find difficult, others might find very easy. Each human brain is different and human intellect varies. Certain individuals may apply a notion of mathematical correctness to a creative activity such as business software engineering and find themselves lost when challenged with something cloudy, unknown or hypothetical.

[chris webster]

If a function is a first class object, you can treat it like any other object so you can pass them around or create them on the fly, as with lambdas/closures in Python/Groovy etc, which also helps to give dynamic languages their flexibility and syntactic sugar. Even as a dumb grunt programmer, this seems much more intuitive to my limited intellect than a lot of messing about with halfway house solutions like "inner classes" whose sole purpose is to give you access to a method (function) call. Another advantage claimed for the functional approach in general is the lack of side effects i.e. the idea is that a function always produces the same results for the same input and does not accidentally affect other data.

If you have time (about an hour) you could check out Neal Ford's video talk on "Functional Thinking" at InfoQ, which looks at FP from a Java developer's perspective.

Or Rich Hickey's (Mr Clojure) great talk on the benefits of a functional approach in "Simple Made Easy", also at InfoQ.

Well, they've convinced me - now I just need to find time to learn how to do FP properly. When will those books of yours be out, Bert?

[Jayesh A Lalwani]

Just thought of this. First class functions in Java might also make Proxying simpler.. and actually might eliminate the need for java.lang.Proxy, which IMO is a bit clunky. You could implement a generic interceptor function that takes the intercepted function as a parameter and returns a function that has the code weaved in. For example, you could have

#(T(Object...params)) buildInterceptor (#(T(Object...params)) target) {
     #(T(Object...params)) interceptor = new #(T(Object...params)) {
          doBefore();
          T result = target(params);
          doAfter();
          return result;
     }
     return interceptor;
}

interface A {
   
    void foo();
    void bar(int i);
    int car();
}
class AImpl  implements A{
    void foo() {....}
    void bar(int i) {.....}
    int car(){.....}
}

class FactoryA {
   A createA() {
      A a = new AImpl();
      a#foo = buildInterceptor(a#foo);
      a#car = buildInterceptor(a#car);
      a#bar = buildInterceptor(a#bar);
   }
}

Yeah the interceptor code is hard to read if you are not familiar with the syntax, but train yourself to understand it and it's way simpler than creating Proxy