Hacker News Reader

Comment by neilk | Hacker News Reader

Look up the technique of "dependency injection" sometime. This is all the rage among Java consultants, their favorite technique to make things testable. It's an elaborately disguised way of saying "let's rewrite this function so it obtains all its state from the caller". In other words, functional programming.

In cases where passing the same list of initialized objects up and down the call stack becomes tedious, Google's Java people have invented frameworks like Guice. This makes dependency injection appear to happen by magic.

View on HN

Dependency Injection allows to assemble program on the fly. It allows to assemble programs written in different styles, including functional.

Look at Spring Dependency Injection Framework for example. It supports lot of libraries, which are written in traditional style.

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.

Reply on news.ycombinator.com