I don't mean to be snarky, but that sounds a lot like passing a closure and maybe some other state in.

I don't really agree with the OP's point in any case. Even if I have an entirely purely functional library, I still need to unit test it to make sure it does what I think it will and that it observes the edge cases I know of correctly and further so that I can regress it if I need to make changes, maybe for performance reasons at some point.

I mean, it is nice to reduce state in your code as much as possible, but its not always practical or efficient. I think it's great that people are getting more excited about Functional Programming because I believe that there are a lot of great techniques that become available when you understand it, but all that imperative knowledge is still going to have its place at the end of the day. After all, writing an in-place quicksort is always going to end up involving imperative directions to the computer!

Maybe you should try reading a bit about dependency injection. It is a declarative way to assembly pieces of software (in this case, objects) that have no knowledge of each other. You can do it manually, but this is an easier way to do it.

Dependency injection is great for testability and awful for code clarity as far as I can see.

I started using dependency injection as f(x,y, z) where x and y were generally the same.

I changed the reference in my code to y.x = x y.f(z) and it got so much clearer and dryer despite losing the dependency injection. Perhaps I'm doing this wrong but dependency injection seems like cruft from the test department. I am not an OO fanatic but OO is extremely useful for juggling a bunch of information in the best bad way possible. And juggling information in that best bad way possible is a way different problem from functional programming paradigm of finding perfect, elegant solutions to well defined problems.

I am not an OO fanatic but OO is extremely useful for juggling a bunch of information in the best bad way possible. And juggling information in that best bad way possible is a way different problem from functional programming paradigm of finding perfect, elegant solutions to well defined problems.

What's the difference between:

    data Foo = Foo { a :: String, b :: String }
    doSomething :: Foo -> String
    doSomething foo = a foo ++ b foo

and

   class Foo {
       String a;
       String b;

       String doSomething(){
           return self.a ++ self.b;
       }
   }

If there's some deep fundamental difference between functional programming and OOP, it's not this.