[s243a]

On of the claims about functional programming languages is that it is easier to handle concurrency because you don't have mutable states. However, their is no requirement to use mutable states in an imperative language. If all the fields are final then setter methods can return a new final object instead of mutate the old object. Granted I'm sure the code to do this in a functional language would be much cleaner but I don't think their is anything in an imperative language that precludes it from using this kind of design pattern.

[Raynes]

There is a big difference between "doesn't have to be mutable" and "you have to go out of your way to be mutable". You can do functional programming (on some level) in most languages around today. Doesn't mean it'll be fun, and it doesn't mean it'll be easy. It certainly doesn't mean you'd want to. But it most definitely doesn't mean it isn't possible.

[s243a]

Raynes, on 03 October 2010 - 06:47 AM, said:

There is a big difference between "doesn't have to be mutable" and "you have to go out of your way to be mutable".

No doubt. The latter is safer but the prior can sometimes be easier.

Quote

You can do functional programming (on some level) in most languages around today. Doesn't mean it'll be fun,

Certainly not as fun.

Quote

and it doesn't mean it'll be easy.

This is somewhat of a relative statment and depends on the task.

Quote

It certainly doesn't mean you'd want to.

Again it depends on the task. For instance in Apache collections predicate functions are defined for filtering data. I've experimented a bit with this design paradigm and found it quite useful for filtering applications. Apache commons is written in Java which is a language that doesn't even support lambda expressions.

I've been experimenting a bit with java generics to see how far I can push the functional paradigms in java. It has been a bit of a headache at times because I don't know the scope of what can be done in Java. For instance I haven't been able to implement type level peno numbers in java but I thought I'd give this a try. Some things which would be helpful are type synonyms and being able to implement the same interface with different type arguments. I also think generic declarations are overly verbose in java in that I have to type Class1<Type1,Type2,Type3 extends Class2<Type1,Type2>> instead of just Class1<Class2<Type1,Type2>>

Today, I decided to try and implement classes which represent well typed functions in java. I have applications in mind. The code is certainly longer because you are reinventing things which are already built into functional languages.

package util;

public interface Function<X,Y> {
    public Y evaulate(X arg);
}

package util;

public class Function_1D_FM_2D<X1,X2,Y> implements Function<X1,Y>{
    Function2D<X1,X2,Y> fn;
    X2 arg2;
    public Function_1D_FM_2D(X2 arg2,Function2D<X1,X2,Y> fn){
        this.fn=fn;
    }
    @Override
    public Y evaulate(X1 arg1) {
        // TODO Auto-generated method stub
        return fn.evaluate(arg1, arg2);
    }

}

package util;

public interface Function2D<X1,X2,Y> extends Function<X1,Function<X2,Y>>{
    public Y evaluate(X1 arg1, X2 arg2);
    public Function<X1,Y> evaulateSecond(X2 arg2);
    public Function2D<X2,X1,Y> swap();
}

package util;

public class Function2D_IMPL<X1,X2,Y> implements Function2D<X1,X2,Y>{

    Function<X1,Function<X2,Y>> fn;
    public Function2D_IMPL(Function<X1,Function<X2,Y>> fn){
        this.fn=fn;
    }
    @Override
    public Y evaluate(X1 arg1, X2 arg2) {
        return evaulate(arg1).evaulate(arg2);
    }

    @Override
    public Function2D<X2,X1,Y> swap() {

        return new Function2D<X2,X1,Y>(){
            @Override
            public Y evaluate(X2 arg1, X1 arg2) {

                return Function2D_IMPL.this.evaluate(arg2, arg1);
            }

            @Override
            public Function2D<X1, X2, Y> swap() {

                return Function2D_IMPL.this;
            }

            @Override
            public Function<X1, Y> evaulate(X2 arg2) {

                return new Function_1D_FM_2D<X1,X2,Y>(arg2,Function2D_IMPL.this);
            }

            @Override
            public Function<X2, Y> evaulateSecond(X1 arg1) {

                return Function2D_IMPL.this.evaulate(arg1);
            }


            
            
        };
    }

    @Override
    public Function<X2, Y> evaulate(X1 arg) {

        return fn.evaulate(arg);
    }
    @Override
    public Function<X1, Y> evaulateSecond(X2 arg2) {

        return this.swap().evaulate(arg2);
    }

}

I think there will be applications where I find this design pattern useful. I do have some modifications to the above in mind but will need to work on them later.