> "Could you elaborate leading by example `how it is different`?"
I'll try.
By the end of the 1950's, modular programming based on procedures and subroutines had become problematic. It was hard to have large teams of programmers working on parts of the code at the same time, and it was hard to create large well-structured programs.
The answer in the 1960's was to break down a problem into pieces, then sub-components, then subroutines through functional decomposition. This better allowed large problems to be understood, and worked on by different teams at the same time. This approach is known as structured programming.
This approach has resulted in quality software over the years, but suffers from painful limitations. One of the big ones is that as one works on a problem and discovers its requirements, the decomposition used needs to be modified, often from the top down.
Object orientation (much as for the "data" movement) represented a different way to approach a problem. Let's break down a large problem or system into entirely independent concepts that know how to to do things themselves. Let's not orchestrate concepts (objects) centrally, but instead have them do things themselves together to solve a problem. This comes close to the way we think. We recognize and organize things in our minds around us as objects. We differentiate between them by their attributes, and we classify them. When we see a tree we recognize it as such, and differentiate it from other by its attributes and also by its place in the hierarchy of types of trees we know. Behavior on the other hand is only immediately important to us if it is causal - for example if it threatens us. That unknown thing moving fast towards you prompts changes in your body, but once you recognize the object is a beetle and not a spider, you change.
Functions have no internal state. Early languages used global variables to share state across functions without explicit message passing (everything was a singleton). This created worlds of pain. The alternative was passing state with each function call. This also got painful as people often passed data down through functions.
OOP lets chunks of functions share state and hide that state from the wider application. More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.
But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables.
> More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort.
Technically that's what classes gives you, not objects. But agreed on the sentiment.
If you apply this common understanding of "closure" where the values that closures close over are not really values but mutable objects, then closures don't count as (pure) functions.
If one thinks of them as proxies to the closed-over objects, they are quite like "procedures". Another way to think about them is simply as objects with only a single method.
They are definitely still "functions", barring the fact that Java doesn't have first-class functions and SAMs are the closest thing. C# does have first-class functions, and it is even more liberal in its closure rules. (Java can only close over `final` variables, which are immutable variable bindings. C# doesn't even have immutable variable bindings, only member bindings.)
Also, they can still be "pure functions". Purity is a relation of side effects, not of mechanisms. (Even then, it's a somewhat loose definition -- is allocating memory a side effect?) If you don't allow closures to escape their declared scope, you can handle closed values as extra parameters. So closures don't mean you suddenly can't write pure functions, it means that some input to the function is pre-determined. In other words, closures have the same implications to purity as parameter binding -- absolutely none.
You are kind-of making my point. It's clearer to use "function" fore pure, mathematical functions, and otherwise "procedure"/"object"/"proxy"/"closure" whatever. Even if some popular languages misuse the term "function".
> Even then, it's a somewhat loose definition -- is allocating memory a side effect?
This is leading nowhere. Is loading a value into a register a side effect? If you care.
I mean, if you're only point is that programmers use the term "function" to mean something other than a pure mathematical mapping from one set to another... You won't get any arguments from me.
> Technically that's what classes gives you, not objects. But agreed on the sentiment.
No, that's what objects give you. Classes are merely one means of creating objects (others exist), but the benefits come from the objects, not their means of construction.
My point is that you can have an OOP language / system that consists entirely of singletons. The ability to create multiple object instances from a template is classes or prototypes or whatever other mechanism. It's not something strictly necessary to OOP.
Yea, I have no idea what you're trying to convey. Additionally, a system built entirely with singletons isn't object oriented, it's procedural with modules.
Seriously because unless you can define it, and quantify it then it is just rhetoric.