In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.

Sure, I agree it can be. But it doesn’t make it less true that “it depends” is often the answer. As I see it, my job is often to think “what applies in this case”. Including thinking about things like:

• what matches the mental model the company has about this
• what’s the shape of the problem
• what type of abstractions do we already use
• what aspect do I want to make available, how is this expected to change?
• etc

Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.

Sure. I lean towards object oriented design when things represent a simple well known object with a stable set of “nouns and verbs” that are unlikely to change. In my case this tends to be around UI elements or the data layer very basic things, where I don’t care too much about “data transformation”, but want to encapsulate an action (eg. I think being toggleable is intrinsic to a switch, so switch.toggle feels like a stable api and I can design an object like this that others can understand without having to care about the internals)

Some design patterns that come from the oop tradition (not exclusive to oop, but very much part of the toolkit) that I find exceptionally useful. For example, the strategy pattern is something I’ve used often when building things like data exporter and importer tools. I can structure my logic in this way, move all the specific logic to the leaves.

I can’t be exhaustive, but for me oop is all about encapsulation, and so I use it when it calls for that. I think it also makes APIs easy to test.

——

Functional programming I absolutely love. Whenever I’m transforming data, i think in functional terms. Composable functions, immutable data. It’s just a lot easier, and for me it makes it easier to test processes and operations. I tend to lean to this this in a business logic layer. If I can describe operations in a way that we talk about them in the company, and make those units of transformation testable, then bigger processes become safer and auditable.

Another thing from functional programming languages that I love is things like algebraic data types. It just pains me to use a language without sum types now.

——

A while back I used “aspect oriented programming”. That didn’t catch on, but moving some things like logging, event tracking, etc. to aspects makes sense to me. If a language supports function annotations, I /will/ try to move those sorts of aspects to a function annotation.

——

I spent a while doing prolog, and that language is just something else. I wish I had an easy to embed prolog that I could use for constraints on data. This one I don’t “get to mix and match” because multi purpose languages don’t include aspects of it. But thinking in terms of reversing operations (eg. Given this result, what set of constraints produce it) is still a tool that helps me understand how to shape a problem.

——

There’s a lot of nuance to this, more than can fit in a comment, and definitely nuance that doesn’t apply to imaginary problems or problems/sotuations that we don’t share. Also, you and others will probably think about it differently. to me that’s kind of the point, both thinking in terms of a diverse toolkit, and having a team with diversity of thought.

I would humbly suggest FP may seem especially natural to you precisely because that’s what you use all day.