So true. Generally, whichever one best matches the feeling best is how I go.

Some things really feel like objects, they've got little personalities, friends, parents... a whole list of talents and characteristics. OOP it is.

Other things are more like physics. It doesn't really need to have a name to exist, there doesn't need to be a container, it always acts predictably. Time to get functional.

I've also been using a tactic which I have no idea what it's really called, but I call it augmentation. I think of them like those crystals you add to your weapons in diablo or other RPGs. The gist is: a public readonly member which takes the object that holds it as an argument and has extra functionality. So like:

``` class Staff { public readonly flamePower = new FlameAugment(this); } (new Staff()).flamePower.doSomethingSpecialInvolvingStaff(); ```

FYI: Code markup on HN works with two spaces at the start of the line, your example is probably meant to look more like this:

  class Staff {
    public readonly flamePower = new FlameAugment(this);
  }
  
  (new Staff()).flamePower.doSomethingSpecialInvolvingStaff();

Wouldn’t that just be a form of inversion of control? It feels a lot like dependency injection, though maybe I’m misunderstanding from the example.

Definitely like a form of inversion of control. Wouldn't think to call it that because the inversion is so shallow, and the control is always accessed from the context of the typical controller. It doesn't feel like what I use IOC for, though there is a similarity.

This way of doing mixins is nice, reliable, testable way of reusable logic and works well with structural type system. I think going this obvious way would be better than hooks for React. We will see.

Isn't this basically what an Entity Component system is?

Bingo. Just looked it up, and that looks like exactly what I'm talking about. I can't say for certain as I haven't ever used/read code that was described as an Entity Component system, so there may be some crucial differences I'm overlooking. But I'm pretty sure you nailed it.

EDIT: Just read into this a bit more (http://vasir.net/blog/game-development/how-to-build-entity-c...). It's something different. Kind of a mix between this and IOC.

I think that you mean the Decorator pattern

It's like decorator. My experience with decorators are that they modify prototype, which is something I'm not a fan of. They also have a tendency to create too many layers, like overused inheritance.

Python is kind of a strange beast - definitely imperative but with some FP-ish features: functions first-class citizenship, list comprehensions, generator functions/expressions (and there is the functools module). It is gaining more and more native immutable collections with each release. This multi-paradigm approach is what makes it one of the best glue-languages out there.

Python lacks tail call optimizations and recursion dept is limited to ~1000, so if your algorithm is not O(log n) or better you may have to convert from recursive to iterative (there is a recipe that makes conversion trivial) but other than that I'm content with its FP-style features.

I guess many beginner developers haven't realize this feature of Python yet. There are a couple of lib to enhance the FP feature of Python. Like itertool, functool, maybe more. In PySpark there are many functions take other function as parameters.

Another language is JavaScript. It uses function as parameter all the time but often just one time but not in a general way. Seems no JavaScript developer really seriously care about the term FP or OO.

>Seems no JavaScript developer really seriously care about the term FP or OO.

Oh no, they care. The reason it doesn't seem like FP is big in the web dev world is because of reactive programming paradigm.

Reactive programming paradigm is designed so when one part of the program is processing it doesn't lock up the UI elements. This defaulting to being thread safe and lock free comes from the FP world.

Reactive programming is a marriage between functional programing and procedural programming paradigms and is incredibly popular. I suspect it is far more popular in the front end world than FP is in the back end world, showing their adoption, despite different, is stronger.

--

On the backend side of things, many of the popular languages have been slowly gaining FP toys, not just Python. C++, Java, Scala, and so on..

> I consider FP to just be one of the tools in my programming toolbox.

This is a healthy attitude to most paradigms. It's important to understand things from different perspectives because that enables us to frame problems in the correct fashion. If you only know C or other procedural languages, for instance, and are faced with a decision problem that is naturally expressed in a few lines of Prolog, you may end up writing a large chunk of Prolog to solve your problem. On the other hand, if you only know Prolog, you can solve the problem quickly, but may not be able to write a specialized program in C that executes that solution quickly enough for your target application.

This is why I like Scala, the best of both world, FP + OOP

Agree. In my previous project due to very tight schedule I had to find a better way to generalize the models which ended up using a lot of FP way in addition to OO way. In the project I was using Groovy which I didn't explore its FP potential before. Then recently I began to read Scala(A similar language but might be better) books and take course. I've used Scala but not very much. Because of pressure of the previous project now I understand how useful that abstraction can deal with so many problem beautifully by generalization of common patterns.

FP Makes Everybody Think Hard. Go METH! (Andrew Yang want to Make American Think Hard)

This is true, even Haskell supports imperative programming and mutation (very well in fact) but languages do need defaults. Given that even OOP thought-leaders argue "favour immutability", I would argue that FP languages offer a better set of defaults out-of-the-box (e.g. persistent collections, libraries for working with immutable data, concise syntax). Mutation is extremely useful and powerful, but if it's the default idiom used absolutely everywhere, then program composition and reuse will be harder to achieve.