Ask HN: can you summarize OO for me in 64 words or less?

Object-orientation is fundamentally just a way of organising programs.

In most non-OO programming, you've got a bunch of data, and a bunch of procedures that can operate on the data. The two are defined and considered somewhat separately, though they must fit together.

In OOP, a kind of datum and the operations on it are instead designed, defined and used together, as essentially linked.

The answer to your question hinges mainly on how you define components. In the Erlang language for example: It is completely functional but threads actually become somewhat stateful and ultimately end up recreating some similar scenarios for OOP programmers. On top of that, functions themselves showcase an even higher amount of reusability at times especially in functional languages because of the prevalence of lists of things and tuples. This prevents an over abundance of duplicate implementations of the same thing that, even though their signatures are identical (or nearly so) can't interoperate because they haven't been specified as exactly the same. So language wide consistency is a big plus for some functional languages.

Having said that no one tool is a golden hammer. OOP and Functional programming are just tools and there are others out there. Some not even based on Von Neumann architectures that are even more flexible than the ones we, Von Neumann proggies, are (think data flow architectures for example).

If there isn't an inherent ownership and hierarchy of data and data properties, OO isn't at all necessary. When the structure is well-defined though, which is in many cases, it is the most intuitive abstraction.

Each object wraps up a program. The program's global variables become variables of the object. The program's functions become functions of the object. The public functions are the interface of the object (an interface is the part of a module that interacts with other modules, like the surface of an object). So basically, you have the inside of the object, and the outside (surface).

Think of it as support for the modules that you already wanted, that seem to be naturally present in the problem, or in how you naturally want to divide it up and think about it. That is, use OO to support your conception, instead of a priestly template to mold yourself into. Tools are good slaves, poor masters. If you follow your conception, you will make mistakes - but those mistakes will belong to you, and so you will learn from them.

Using objects for modularity does not work well for every case (e.g. I think parsing works better in the old-fashioned style).

OO is nothing special. There's no wonderful mysterious secret. It doesn't even have a precise definition that everyone agrees on. It's just a tool. Inheritance and polymorphism are grossly overrated, but presented as a quasi-religious AI solution-to-everything - but are useful in some cases (e.g. great for windows/GUIs). There's also a danger of having overly theoretical modules - the "spaces" you mention. Be problem-driven. What does the problem need?