Comments on: Monads are Inversion of Control au naturel http://enfranchisedmind.com/blog/posts/monads-inversion-of-control/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Enfranchised Mind » Why We Don’t Need Anonymous Inner Classes for Groovy/Grails http://enfranchisedmind.com/blog/posts/monads-inversion-of-control/#comment-36527 Enfranchised Mind » Why We Don’t Need Anonymous Inner Classes for Groovy/Grails Fri, 24 Jul 2009 15:14:11 +0000 http://enfranchisedmind.com/blog/?p=944#comment-36527 [...] Most anonymous inner classes are really closures at heart, the same way inversion of control is really monadic handling at heart. [...] [...] Most anonymous inner classes are really closures at heart, the same way inversion of control is really monadic handling at heart. [...]

]]> By: Brian http://enfranchisedmind.com/blog/posts/monads-inversion-of-control/#comment-34705 Brian Sun, 10 May 2009 00:49:51 +0000 http://enfranchisedmind.com/blog/?p=944#comment-34705 Gustavs: I think it's more than that. Whether it's a good idea or not remains to be seen, and I think that on balance I'm negative on the idea. Simply because two concepts are powerful doesn't mean they'll place nice together. I mean, both peanut butter and bacon are tasty, but they don't go into the same dish (unless you're <a HREF="http://www.sluggy.com" rel="nofollow">Torg or Riff</A>). Gustavs: I think it’s more than that. Whether it’s a good idea or not remains to be seen, and I think that on balance I’m negative on the idea. Simply because two concepts are powerful doesn’t mean they’ll place nice together. I mean, both peanut butter and bacon are tasty, but they don’t go into the same dish (unless you’re Torg or Riff).

]]> By: Gustavs http://enfranchisedmind.com/blog/posts/monads-inversion-of-control/#comment-34641 Gustavs Sun, 03 May 2009 17:40:58 +0000 http://enfranchisedmind.com/blog/?p=944#comment-34641 @JS An alternate syntax and code manipulation stage on top of an existing Haskell implementation. @JS

An alternate syntax and code manipulation stage on top of an existing Haskell implementation.

]]> By: JS http://enfranchisedmind.com/blog/posts/monads-inversion-of-control/#comment-34554 JS Tue, 28 Apr 2009 23:17:51 +0000 http://enfranchisedmind.com/blog/?p=944#comment-34554 @Brian If... " In Lisp, all code is data" and... "Haskell, on the other hand, is precisely the other way around- all data is code." What is... http://liskell.org/ ? @Brian

If…

” In Lisp, all code is data”

and…

“Haskell, on the other hand, is precisely the other way around- all data is code.”

What is…

http://liskell.org/ ?

]]> By: Josh Suereth http://enfranchisedmind.com/blog/posts/monads-inversion-of-control/#comment-34279 Josh Suereth Sun, 15 Mar 2009 14:04:14 +0000 http://enfranchisedmind.com/blog/?p=944#comment-34279 Ok, What I don't get here is that you're saying monads are like Spring's inversion of control, but you don't use inversion of control in the post, simply the Spring JDBC libraries, which are monadic and closure based. Spring's inversion of control isn't about passing annoynmous-inner-classs-closures, but about making sure you are passed in objects instead of statically accessing them (i.e. avoiding singletons). I believe spring recognized the benefits of ARM and Closure-like syntax early, which is why it has great "wrapper" libraries for various java technologies. However, I don't think they have anything to do with the IoC container (which is dependency injection based). While I agree with the content of the post, I believe your definition for Inversion of Control is a bit off, and confused me for a bit. Yes there is an "inversion" to how you think about using objects, so in that sense it would be an inversion of control, but in the context of how it's used and taught by Spring, I believe they're mostly referring to dependency injection. Ok, What I don’t get here is that you’re saying monads are like Spring’s inversion of control, but you don’t use inversion of control in the post, simply the Spring JDBC libraries, which are monadic and closure based.

Spring’s inversion of control isn’t about passing annoynmous-inner-classs-closures, but about making sure you are passed in objects instead of statically accessing them (i.e. avoiding singletons). I believe spring recognized the benefits of ARM and Closure-like syntax early, which is why it has great “wrapper” libraries for various java technologies. However, I don’t think they have anything to do with the IoC container (which is dependency injection based).

While I agree with the content of the post, I believe your definition for Inversion of Control is a bit off, and confused me for a bit. Yes there is an “inversion” to how you think about using objects, so in that sense it would be an inversion of control, but in the context of how it’s used and taught by Spring, I believe they’re mostly referring to dependency injection.

]]>