Modern Functional Programming: The Onion Architecture • Hacker News Board

Re: Modern Functional Programming: The Onion Architecture

#71

Post by whateveracct » Fri, Sep 30, 2016, 2:10 AM UTC

gamegoblin wrote: post #63

aisofteng wrote: post #61

Earlier quoted context omitted.

Could you give a concrete example?

Most in-place algorithms. E.g. quicksort You can do merge sort in Haskell asymptotically as well as C, but not quicksort (because you can't mutate things in place). I am of course omitting things like ST which do give you this sort of ability in Haskell, but I doubt that's what the OP meant by "purely functional".

ST is exactly the same sort of thing junke was talking about, except it also uses the type system to ensure the imperative core doesn't leak into the outside world.

Re: Modern Functional Programming: The Onion Architecture

#72

Post by rjbwork » Fri, Sep 30, 2016, 2:14 AM UTC

harryjo wrote: post #32

junke wrote: post #15

Earlier quoted context omitted.

At the lowest levels, the pattern can be reversed: you provide a nice functional shell around a little bit of imperative core (e.g. implementing "map" with a loop).

You are referring to, for example: http://clojure.org/reference/transients Combining the two ideas Transient imperative logic in the core (5%), Functional mantle (90%), Side-effecting imperative crust (5%).

mmmmmmmmmmmm. Functional sandwich.

Re: Modern Functional Programming: The Onion Architecture

#73

Post by mej10 » Fri, Sep 30, 2016, 2:19 AM UTC

hota_mazi wrote: post #46

thinkpad20 wrote: post #44

Earlier quoted context omitted.

There is a very small amount of boilerplate. And I would argue strongly that it's a good thing ; it indicates to the reader of the code that an object's behavior reads from some initialized value, or equivalently that its behavior depends on some initial value which remains fixed through the computation. The reader monad gives you a simple language to express this common pattern, as well as the ability to easily set…

What if `function2` needs to log something? Without dependency injection, you need to pass that logger to the function. With dependency injection, that logger is available without having to pollute the method signature with an implementation detail.

A small example.

    class (MonadIO m) => HasLogging m where
      log :: String -> m ()
    
    data AppConfig = AppConfig { stuff :: Int }
    
    newtype MyApp a = MyApp { runApp :: ReaderT AppConfig IO a}
      deriving (Functor, Applicative, Monad, MonadIO, MonadReader AppConfig)
    
    instance HasLogging MyApp where
      log s = liftIO (putStrLn s)
    
    function2 :: Int -> MyApp String
    function2 x = do
      log "hey guys I'm logging"
      return (show x)
    
    -- or without specifying the base monad, yay abstraction
    
    function2' x = do
      log "heyooo logging here"
      return (show x)
    
    -- Haskell will infer this type:
    -- function2' :: (HasLogging m, Show a) => a -> m String

Re: Modern Functional Programming: The Onion Architecture

#74

Post by 20andup » Fri, Sep 30, 2016, 2:53 AM UTC

hota_mazi wrote: post #38

bad_user wrote: post #35

Earlier quoted context omitted.

First of all, passing parameters in functions is "dependency injection". And what you're describing is a really good thing . Lets be honest, most dependency injection frameworks and techniques are about hiding junk under the rug. But they fix the symptoms, not the disease. You see, if you find yourself having components with too many dependencies, feeling pain on initialization, the problem is that you have too many…

> First of all, passing parameters in functions is "dependency injection". And what you're describing is a really good thing. It's only injection if the parameter is passed automatically by a framework. Otherwise, it's parameter passing. And it's only a good thing if you value referential transparency over ease of testing and encapsulation. Not everybody does (and personally, sometimes I do and sometimes I don't).

"passing parameters in functions is 'dependency injection'"

No, its not.

Re: Modern Functional Programming: The Onion Architecture

#75

Post by rtpg » Fri, Sep 30, 2016, 3:37 AM UTC

harryjo wrote: post #32

junke wrote: post #15

Earlier quoted context omitted.

At the lowest levels, the pattern can be reversed: you provide a nice functional shell around a little bit of imperative core (e.g. implementing "map" with a loop).

You are referring to, for example: http://clojure.org/reference/transients Combining the two ideas Transient imperative logic in the core (5%), Functional mantle (90%), Side-effecting imperative crust (5%).

the main thing being that side effects still aren't happening in the core, so the core is still referentially transparent.

Re: Modern Functional Programming: The Onion Architecture

#76

Post by [deleted] » Fri, Sep 30, 2016, 4:00 AM UTC

20andup wrote: post #74

hota_mazi wrote: post #38

Earlier quoted context omitted.

> First of all, passing parameters in functions is "dependency injection". And what you're describing is a really good thing. It's only injection if the parameter is passed automatically by a framework. Otherwise, it's parameter passing. And it's only a good thing if you value referential transparency over ease of testing and encapsulation. Not everybody does (and personally, sometimes I do and sometimes I don't).

"passing parameters in functions is 'dependency injection'" No, its not.

[deleted]

Re: Modern Functional Programming: The Onion Architecture

#77

Post by [deleted] » Fri, Sep 30, 2016, 4:03 AM UTC

20andup wrote: post #74

hota_mazi wrote: post #38

Earlier quoted context omitted.

> First of all, passing parameters in functions is "dependency injection". And what you're describing is a really good thing. It's only injection if the parameter is passed automatically by a framework. Otherwise, it's parameter passing. And it's only a good thing if you value referential transparency over ease of testing and encapsulation. Not everybody does (and personally, sometimes I do and sometimes I don't).

"passing parameters in functions is 'dependency injection'" No, its not.

[deleted]

Re: Modern Functional Programming: The Onion Architecture

#78

Post by junke » Fri, Sep 30, 2016, 4:55 AM UTC

aisofteng wrote: post #61

junke wrote: post #37

Earlier quoted context omitted.

Yes, because some purely functional approaches cannot beat imperative ones when it comes to resource usage.

Could you give a concrete example?

I was about to cite Okasaki, but I found a detailed answer over there:

http://stackoverflow.com/a/1990580

> Note also that all of this discusses only asymptotic running times. Many techniques for implementing purely functional data structures give you a certain amount of constant factor slowdown, due to extra bookkeeping necessary for them to work, and implementation details of the language in question. The benefits of purely functional data structures may outweigh these constant factor slowdowns, so you will generally need to make trade-offs based on the problem in question.

Re: Modern Functional Programming: The Onion Architecture

#79

Post by hota_mazi » Fri, Sep 30, 2016, 5:24 AM UTC

20andup wrote: post #74

hota_mazi wrote: post #38

Earlier quoted context omitted.

> First of all, passing parameters in functions is "dependency injection". And what you're describing is a really good thing. It's only injection if the parameter is passed automatically by a framework. Otherwise, it's parameter passing. And it's only a good thing if you value referential transparency over ease of testing and encapsulation. Not everybody does (and personally, sometimes I do and sometimes I don't).

"passing parameters in functions is 'dependency injection'" No, its not.

You're agreeing with me.

I was saying that passing parameters to functions is "dependency passing", not "dependency injection".

Re: Modern Functional Programming: The Onion Architecture

#80

Post by hota_mazi » Fri, Sep 30, 2016, 5:26 AM UTC

thinkpad20 wrote: post #52

hota_mazi wrote: post #46

Earlier quoted context omitted.

What if `function2` needs to log something? Without dependency injection, you need to pass that logger to the function. With dependency injection, that logger is available without having to pollute the method signature with an implementation detail.

If `function2` needs to log something, then it should have a type signature which reflects that. Logging is a side-effect. Logging requires configuration to be passed in; it means having access to some file descriptor or other object to interact with, it could potentially fail to connect, or cause a computation to hang, or cause a service to trigger, or make a disk run out of space, etc. If a function wants to log so…

> If `function2` needs to log something, then it should have a type signature which reflects that.

Yes if you value referential transparency.

No if you value encapsulation.

The fact that `function2` is logging stuff is an implementation detail that callers shouldn't care about. They should certainly not be forced to pass that function a logger.

What if that function decides that on top of logging, it wants to store stuff in a database. Should all callers suddenly find some kind of database to pass to that function too?