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 have serious reservations about being able to explain myself or convince anyone of anything in an HN thread. But I can certainly share my perspective.
Like I said, I'm becoming a huge fan of FP -- to the point I'm really not interested in doing a lot of OOP in the future, and I did OOP for many, many years. But that's because I work with small teams mostly.
OOP is all about the organization of the ontology of the problem domain. It's about gaining a common understanding of a general organizational philosophy that then can be scaled and coded. In OOAD you start with simple conversations and slowly created complicated structure where everything has a place. It's this process of being able to take any problem and create a complicated place for everything that is both OOP's strength and weakness.
I started with the Tao of Objects http://amzn.to/KHE5TK and the Coad Yourdon books http://amzn.to/IS9fqj and http://amzn.to/IS9oKh. I still like these because they focus more on how to mentally approach OOAD instead of the details of coding. People get lost in the details here instead of learning the key skill: how to think about problems. (which is useful no matter which type of language you use)
The best way to describe OOAD is "applied philosophy". That is, you are taking a world known only to the customer and translating it into machine code. On one hand we have the slipperiness of language and the fuzziness of human thought. On the other hand we have hard science and boolean logic. OOAD gives you a game plan for making that journey in an easy-to-use manner. FP is not like that. FP is more like building a compiler for whatever the problem is. Same result, but the thinking process is completely different. OO is concerned with top-down. 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. But when you _do_ write something, it's already broken down into tiny digestible pieces. In FP I always feel like I'm carrying the linker around in my head. :)
In some problems, it's more important to gain immediate functionality than it is to worry about scaling your code or development team. Startups are mostly like this, and FP and startups go very well together. In some problems, however, it's more important to have clear areas of responsibility and an overall plan for life, the universe, and everything. Large government or corporate projects are like this. The organization of the code units into something mirroring the domain model allows planning at a much larger scale.
As I get older I realize that I was a bit of an architecture astronaut in my younger years -- always creating a structure much more complex than was actually needed. But I also note that these projects usually went off without a hitch. We were able to hire "normal" programmers and we were able to hand the code off to "normal" maintenance programmers when we were done. 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?
So if I had a large project to do, I'd start with OOAD and then when I got into later design think seriously about which parts would deploy better FP or OOP. The browser code is going to need some kind of namespace, which is usually done with objects in Javascript. Talking from the browser to the server looks entirely functional to me. The back-end gets a bit tricky. There's nothing like a normalized database model for data analysis, but creating a business and database tier looks counterproductive in some cases. It'd depend a lot on the circumstances.
Like I said, I'm becoming a huge fan of FP -- to the point I'm really not interested in doing a lot of OOP in the future, and I did OOP for many, many years. But that's because I work with small teams mostly.
OOP is all about the organization of the ontology of the problem domain. It's about gaining a common understanding of a general organizational philosophy that then can be scaled and coded. In OOAD you start with simple conversations and slowly created complicated structure where everything has a place. It's this process of being able to take any problem and create a complicated place for everything that is both OOP's strength and weakness.
I started with the Tao of Objects http://amzn.to/KHE5TK and the Coad Yourdon books http://amzn.to/IS9fqj and http://amzn.to/IS9oKh. I still like these because they focus more on how to mentally approach OOAD instead of the details of coding. People get lost in the details here instead of learning the key skill: how to think about problems. (which is useful no matter which type of language you use)
The best way to describe OOAD is "applied philosophy". That is, you are taking a world known only to the customer and translating it into machine code. On one hand we have the slipperiness of language and the fuzziness of human thought. On the other hand we have hard science and boolean logic. OOAD gives you a game plan for making that journey in an easy-to-use manner. FP is not like that. FP is more like building a compiler for whatever the problem is. Same result, but the thinking process is completely different. OO is concerned with top-down. 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. But when you _do_ write something, it's already broken down into tiny digestible pieces. In FP I always feel like I'm carrying the linker around in my head. :)
In some problems, it's more important to gain immediate functionality than it is to worry about scaling your code or development team. Startups are mostly like this, and FP and startups go very well together. In some problems, however, it's more important to have clear areas of responsibility and an overall plan for life, the universe, and everything. Large government or corporate projects are like this. The organization of the code units into something mirroring the domain model allows planning at a much larger scale.
As I get older I realize that I was a bit of an architecture astronaut in my younger years -- always creating a structure much more complex than was actually needed. But I also note that these projects usually went off without a hitch. We were able to hire "normal" programmers and we were able to hand the code off to "normal" maintenance programmers when we were done. 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?
So if I had a large project to do, I'd start with OOAD and then when I got into later design think seriously about which parts would deploy better FP or OOP. The browser code is going to need some kind of namespace, which is usually done with objects in Javascript. Talking from the browser to the server looks entirely functional to me. The back-end gets a bit tricky. There's nothing like a normalized database model for data analysis, but creating a business and database tier looks counterproductive in some cases. It'd depend a lot on the circumstances.