>The core of Functional Programming is thinking about data-flow rather than control-flow
That's not right. The difference between data and control flow oriented programming is the difference between laziness and eagerness. The difference between imperative and functional programming is largely one of abstraction, not a feature in itself.
The genuine core feature of FP is the separation of data and methods, that stands in contrast not to imperative programming but object oriented programming, whose core feature is fusion of data and methods. Functional programming tries to address complexity by separation of concerns, pulling data and methods apart, OO tries to address complexity by encapsulation, pulling data and methods into purely local contexts.
This is also where the association between FP and static typing comes from that the post briefly mentions. Pulling data and functionality aside lends itself to programming in a global, sort of pipe based way where types act like a contract between different interacting parts, whereas the information hiding of OO lends itself to late binding and dynamic programming, taken to its most extreme version in say, Smalltalk.
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.
>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.
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.
> 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.
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.)
> 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.
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.
Implying that the inventors of Simula had a time machine?
I am inclined to think the more logical explanation is that they didn't actually take OO back in time and that Simula isn't an OO language at all (perhaps confused by the first OO language being created with Simula?), but admittedly I'm rooting for the time machine! Look forward to you telling us more about it.
That's exactly what the parent comment said, since C is an imperative programming language:
> The genuine core feature of FP is the separation of data and methods, that stands in contrast not to imperative programming but object oriented programming, whose core feature is fusion of data and methods
Yes, the original comment posits that functional programming and imperative programming are the same thing, but that does not address the practical concerns of the parent. The harsh reality is that we have both "functional programming" and "imperative programming" terms with an intent for them to have different meanings.
Let's accept temporarily that functional programming and imperative programming are, indeed, the same thing. But now you have two terms with the same meaning still wanting to mean something different. A conflict in need of resolve. So, from this point forward what can we say that makes them different?
A trait I often see in languages that are considered functional, and not found in C, is the closure. Its purpose is to bind data with functions. That suggests to me that, as we seek a division in meaning, separation of data and functions is better left for the imperative definition rather than the functional definition.
Perhaps functional programming is best described as the intersection of imperative programming with "OO" programming? That seems to be the view the original commenter ends up taking in subsequent comments.
There's always some rambling answer in every FP post about what FP _actually is_ which then devolves into senseless drivel and arguments.
If you wrote this in a book and gave it to me as a way to learn what FP is, I'd be pretty pissed if I paid for that book is all I'm saying.
Also, what in the actual fuck are you on about? FP is many things and some of them are less enforced than others depending on implementation, but I'm pretty sure in each FP book I've looked at has mentioned exactly this idea of data-flow. So either you are an amazing genius who sees what others can't, or you are just generating nonsense. Either way I don't care, HN is kind of a joke to me anymore.
That's not right. The difference between data and control flow oriented programming is the difference between laziness and eagerness. The difference between imperative and functional programming is largely one of abstraction, not a feature in itself.
The genuine core feature of FP is the separation of data and methods, that stands in contrast not to imperative programming but object oriented programming, whose core feature is fusion of data and methods. Functional programming tries to address complexity by separation of concerns, pulling data and methods apart, OO tries to address complexity by encapsulation, pulling data and methods into purely local contexts.
This is also where the association between FP and static typing comes from that the post briefly mentions. Pulling data and functionality aside lends itself to programming in a global, sort of pipe based way where types act like a contract between different interacting parts, whereas the information hiding of OO lends itself to late binding and dynamic programming, taken to its most extreme version in say, Smalltalk.