Back in the day (finishing up my PhD thesis in 1998) I would write C code with functions like

  some_method(Object* this, ...)

that was effectively "object based" even if there was no support for inheritance. Ultimately this style reifies data structures as objects and provides a systematic approach to many problems such as how you allocate memory. The one area where I feel it falls short is that there ought to be some way of switching from struct-of-arrays to arrays-of-struct representations.

This is not too different from how many real object-oriented systems are implemented.

There is a quite a bit of overlap between "using functional programming techniques to implement an object-oriented style" and "using object-oriented techniques to implement a functional programming style."

There's nothing more annoying in the lower teachings of programming that circulate than the "FUNCT10NS RULE, 0BJECTS DR001" sentiment you see so much of.

AKA python style OOP ;-)

Even in a language like Java which pushes objects pretty hard the mental model that "a method is just a function where the first parameter is this" is pretty useful, particularly if you are trying to break out of the OO box and write Java code that looks like LISP, ML, COBOL, FORTRAN, etc. (Super Fun IMHO, particularly in JDK 17!)

The tricky thing with this model is "how do you implement polymorphism?" The most sublime methods dispatch not just on this but also on the other methods but you do get extra complexity just as you would with multiple inheritance, or the C++/C# polymorphism models other than Java's "all-virtual" approach, etc.

JS doesn't have true classes, but I use the class keyword often to do what you're describing: creating immutable OOP style models that i can pass around as function arguments.

F#. It's functional first. Supports currying, HoF, maybe types, composition, pipelining and most of the functional goodies. It offers a neat indented syntax for OOPs.

You can also do function calls with optional arguments with defaults.

Case classes in Scala? (Although traditional imperative classes are also available, so maybe this doesn’t count as encouraging your desired style.)

Thanks, that's pretty much exactly what I was looking for. Very interesting. Are these commonly used in Scala code? It seems that they do away with some of the boilerplate code (in the constructor) and provides some rather nice features. I guess the inventors of Scala has been thinking along similar lines as me ;-)

Yes they are used all the time and every time data has to be represented.

pony is the word