You don't need OO for state management. Plain data structures and functions work just fine.
The core aspects of OO like inheritance are not that useful for most problems.
The core aspects of OO like inheritance are not that useful for most problems.
Of course you don't, that's why I said OO is most likely the way to go.
I also spoke of more than simple state management - If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - isn't simple state management.
You still don't have to go OO to solve that problem, it's just a very good choice in most circumstances.
Also, inheritance is not a core aspect of OO. It's a common aspect of OO and even a popular aspect, but it's not core. To wit, there are OO systems not having inheritance.
One of the core aspects of OO is reuse of functionality, typically by inheritance or delegation. We can find one or both in most OO languages.
You'll find it in practically every object-oriented language, starting with Simula. Later Smalltalk, Actors, CLOS, C++, Self, Java, Objective-C, Python, JavaScript, ...
> making things "reusable" only to never be reused.
It's similar mind-numbing how much has been reused.
My experience is the reuse comes from frameworks. I'd love to hear if you've had another experience.
Flavors (an early object-oriented system for Lisp, early 80s) provided multiple-inheritance, mixins, method combinations, etc. and a bunch of software made use of its features. Object Lisp was another OO system for Lisp, which one used for example in an interface builder, which made extensive use of delegation. The Common Lisp Object System later was designed improving on Flavors and LOOPS (from Xerox), switching away from message passing, adding multiple dispatch. Thus dispatch based on inheritance works over possibly multiple arguments.
Inheritance and delegation have a long history in Lisp going back to the 70s.
That's what was taught to me in computer science at university, along with Java (sadly).
In Common Lisp the object system uses generic functions, which assemble several related methods. Generic Functions are defined outside (!) of classes and objects. Generic Functions are both CLOS objects and functions. Generic functions are called with one or more arguments. The Generic Function decides which methods are run and in what combination. There is no equivalent to a receiver: CLOS generic functions dispatch over its arguments, all primary arguments. There is no equivalent of a privileged receiver object or a self. There is no special syntax for calling a generic function and they are themselves first class objects, which can be stored and passed around. The mental model of a developer is based on function calling of runtime assembled functions.