[wk_end]

One of the foundational building blocks of FP is the closure, the purpose of which is to couple together data and the function operating on it.

ML, one of the standard-bearing functional programming languages, is at least partially defined by its powerful module system. And an ML module serves a similar sort of encapsulatory purpose as the class does, often binding together a type and functions that operate on it - the internals of the type sealed away such that only those functions can operate on that data.

[Barrin92]

>One of the foundational building blocks of FP is the closure

Yes, because the closure solves a problem in functional programming by injecting a bit of OO. Closures are just stateful function objects with a single call method operator where the local context serves the same purpose as private variables in an object.

It's exactly because FP otherwise lacks the coupling of data and methods that closures are so important, and it's why, the other way around, in languages where functions are literally first class objects, you achieve that through closures.

[wk_end]

If paradigm A is defined, in part, by a particular concept that was created wholly independently of paradigm B, even if that concept has some analogs in paradigm B, it's a real stretch to say that it's merely "injecting a bit of" paradigm B into paradigm A.

A more parsimonious ontology is that there's an underlying concept shared by both paradigm A and paradigm B, and that you're making your cut in the wrong place - that this concept is not where the split is.

[Barrin92]

> it's a real stretch to say that it's merely "injecting a bit of" paradigm B into paradigm A.

Not at all. Leibniz and Newton both invented the same thing independently, calculus, even though each probably called it something else. The reason why this whole discussion is so confused is because people tend to do what you proposed, which was argue from the top down by association. We say ML is "functional", ML contains closures, closures encapsulate state and behavior, therefore that's "functional programming". But that's like saying, Python is "object oriented", X is in Python, therefore that's object oriented programming. Which is of course not true, you can write functional code in Python just fine.

If we want a real ontology we've got to look at what structures in a program do, regardless of language. Closures behave like objects, modules that you brought up are basically just static classes. In fact the Ocaml manual gives a good example of how classes, modules and objects can be expressed in interchangeable ways (https://ocaml.org/manual/5.2/advexamples.html). There's a reason that Ocaml is a fairly logical extension of Caml, it didn't suddenly become the ontological opposite because you added the O to it.

Working up from clear conceptual differences I think also leads to a much more sensible conclusion, which is that a lot of languages combine both functional and object oriented features and that labelling an entire language as either one is just wrong.

[randomdata]

> by injecting a bit of OO.

OO is defined by message passing. What does a closure have to do with message passing?

[layer8]

In most OO languages, message passing is just a fancy term for function calling. It’s really not fundamentally different from functional application on a closure value in FP.

OOP is defined by encapsulation and subtyping (polymorphism and inheritance). In fact, the one thing that doesn’t exist in standard FP is inheritance. (Encapsulation sort-of exists with closures, and polymorphism exists with function values.)

[randomdata]

> In most OO languages, message passing is just a fancy term for function calling.

Having objects does not make a language oriented to those objects. By your definition C++ would be considered OO, but we know it is not. Kay quite explicitly stated that C++ is not OO. I expect you're thinking of Object-based programming.

If you look at the actual definition of OO, it basically is just a laundry list of Smalltalk features. It is probably not usable outside of Smalltalk for that reason, despite Joe Armstrong's playful insistence that Erlang is the only OO language in existence.

You might be able to include Ruby and Objective-C (and, iff you're really stretching, Swift with @objc enabled), but that's about the extent of it.

[layer8]

I don’t really care much about what Kay says. His view of OO isn’t what caught on. C++ as a descendant of Simula, which is considered the first object-oriented programming language, certainly supports OO. (C++ is really a multi-paradigm language.)

Object-based means OO without inheritance or subtyping.

[randomdata]

Simula long predates OO. To call it an OO language is laughable.

Simula has objects, but that does not imply that the objects are oriented.