> So whenever I post on OOADP, seems like everybody gets in a bit of a snit with me :) (not you, just a small minority of the community. Perhaps these are dange

> So whenever I post on OOADP, seems like everybody gets in a bit of a snit with me :) (not you, just a small minority of the community. Perhaps these are dangerous political waters!) But I'll explain a bit more. Please remember, though, that this is long-format material. I appreciate it, and I recognize that there's sometimes a bit of knee-jerk snittiness that can come across in these OOP vs FP debates, including in my post. If you've written about this in a longer format somewhere else, or plan to, I would be interested. > FP makes little blocks and then fits them together into bigger units. In OOP you might spend a lot of time on structure without ever writing any code that does anything at all. This is getting closer to the crux of things. The bottom-up FP style just fits my own workflow and habits better. Spending a lot of time building structure without writing code that does anything seems like dangerous premature design. Thinking about the problem and about problem solving ahead of time is important, but I'm not sure that building structure is. > In FP I always feel like I'm carrying the linker around in my head. :) I'm not really sure what you mean. > OOP, to me at least, is much more about the people part of programming than it is the technical part. FP guys are always making these technical arguments about their language, and they miss the point entirely: the problem that OOADP solves isn't a technical one, it's an organizational one. Where does stuff go? I think it's possible to answer this question in a functional program, as another commenter said, Clojure namespaces provide an answer to questions like "where". I think bigger picture design like MVC can be useful here, see ClojureScript One for one (relatively simplistic, but very interesting nonetheless) example. So I guess if OOP/OOADP is about solving a nontechnical problem, my question would be if we can solve those same social problems while writing FP code? If we want to avoid object oriented hierarchies and graphs that are interconnected and complected, can we still address the social and nontechnical problems you think OO solves? Surely that's possible? It seems that relying on OO to solve these problems drags in an awful lot of baggage (like introducing a lot of mutable state that is problematic for very technical reasons). Thanks for the pointers to those books, I'll check them out.