Hacker News Reader

Comment by rafekett | Hacker News Reader

i don't think you actually understand these patterns or how they're used. it's useful when you have multiple implementations of `Car` that you want to use under different circumstances. Or when `Car` is dependent on static configuration that might depend on the host it's running on, or might be different in development/testing/production.

View on HN

I don't think you understand functional programming.

    function makeAppropriateCar(cargo) {
      if(cargo == "people") return new Automobile();
      else if(cargo == "boxes") return new Truck;
      else ...
    }

    function makeLocalCar(settings) {
      var car = new Car({'color': settings.get('new_car_color')});
      car.set_origin(settings.get_hostname());
      return car;
    }

    function makeDebuggingCar() {
      if(global_settings.DEBUG && !global_settings.PRODUCTION)
        return new Car({'loglevel': LOGLEVEL_DEBUG});
      else if(global_settings.DEBUG && global_settings.PRODUCTION) // testing
        return new Car({'loglevel': LOGLEVEL_INFO});
      else  // production
        return new Car({'loglevel': LOGLEVEL_WARNING});
    }

Ok, now try maintaining that when there are 15 types of cars and cars are used in dozens of services. You're imperatively expressing a dependency graph that you could (and would benefit from) defining declaratively at a larger scale.

I'd recommend reading the user guide for Guice for balance before you respond. It's worth seeing how nice DI can be.

What does your example have to do with functional programming?

You've written two factories, pretty much exactly how AngularJS uses them, in an imperative style.

Regardless of which, this doesn't in any way solve the issue Angular Services are designed to solve (IoC).

This example actually really sucks. Advocating for case statements shows that either you've never worked on a truly large project or you've never had to go back and modify your own code 2 years after the fact.

If you really understood functional programming, you'd see an if/case statement as an opportunity to replace conditional with a function.

I started to write up an example, but since we're talking about the imaginary abstract Vehicle implementation, it's not worth dignifying.

If programmers didn't switch jobs every 12-18 months and didn't see 100K LoC as a "large project", these "all frameworks suck" rants might turn into useful discussions of how one can organize code such that it's understood by more than the original author. That goes for frameworks too. If you have to rely on one of the core developers responding to a post on Google Groups or SO as your support mechanism, you've made the world less simple.

It's a fine example. Are you saying that 3 case statements is too many?

Why optimize the code to support cases that don't actually exist yet?

Or even better, why optimize the code in ignorance to how it will need to be optimized in 2 years?

None of these are examples of functional programming except that you wrote some functions.

Reply on news.ycombinator.com