I used to be an oo programmer. Now I'm fully FP, and I'm never going back. When you say "not sold", I guess my question is, have you tried it?
I find some problems are solved better in an OO way such as interacting with a relational database.
Others like data processing, are better done in a functional pattern.
I look for the right tool for the job rather than some idealistic purity
I've switched to functional interactions with a database, (Elixir/Ecto) and really, it's much better. In particular the explicit and declarative nature of the database interactions combines the convenience of an ORM with "not hiding important gotchas from you". I'm not arguing for pure functional systems (which I can see going very poorly with relational databases).
There are some things that objects are good at like caching state as a model. But even here the FP systems typically do it better via FP actors and (again, impure) message passing, which enforces no-shared memory, and at least in erlang virtual machine systems, couples segregated state with limiting blast radius for your systems failure domains, which is 150% the "right thing to do". Of course if we're getting pedantic, this is even close to OO the way that Alan Kay imagined it, than what the OP and GP talk about, and I don't consider that to be OO in the contemporary, colloquial sense of "everything that happened after Bjarne Soustroup invented C++"
I highly recommend this video for a more philosophical take on how to do "impure FP" without OO that is informed by a decade of industry experience: https://www.youtube.com/watch?v=yTkzNHF6rMs which is by Gary Bernhardt (of WAT fame)
> I look for the right tool for the job rather than some idealistic purity
This is all about right tool for the job. IMO, FP code is easier to read, easier to reason about, easier to maintain. I think it's a shame that FP gets this reputation for being 'about ideological purity'. I like using "working programmer's FP", and the FP that I use are built on designs that are driven by real, customer-use-case driven concerns and real-world constraints, and how to make life easier for programmers and operators.
Why? The very best "OO" interactions I have with a database are via Linq which is a monad [1]. What it actually does is simply build the plan for what to do in the database and actually do the query at the last possible opportunity. Exactly how it would work in a purely functional setting.
[1 ]https://github.com/louthy/language-ext/wiki/Thinking-Functio...
Linq is functional, but functional-impure.
Many of the methods on those organizational classes are implemented in a functional manner.
I rely on the class/instance pattern for working with a database. static class methods for actions that work on multiple rows, instance methods for single row interactions.
This works especially well in typescript where I can set private/protected/public
That said, I rarely use inheritance except when it's obvious - no nested class hierarchies or other such traps.
Thanks for the video, I'll give it a watch.