Why can't an OO language be functional? OCaml is OO, and it's one of the most functional languages I know (the other being Haskell). Scala is a functional language and an OO language (and an imperative language, as a matter of fact). Clojure could also be considered OO, with the new protocols. Javascript is a very OO language, and quite functional as well (especially considering the libraries such as Underscore). Maybe we should be talking about functional and imperative programming styles instead, imperative being a loop, and functional being a recursive function (map, filter, fold/reduce).
> declarativity instead of an imperative style of programming
I guess there's a thin line separating these concepts, and also a great deal of overlap and confusion. Here, we're declaring what we want:
even = [i from nats[1:100] where i % 2 == 0]
Here, we're using "the imperative style":
even = []
for i = 1 to 100
if i % 2 == 0
even.append(i)
This is functional style:
even = filter(nats[1:100], i -> i % 2 == 0)
However, this is also imperative - we're telling the computer what to do. The main difference is just that in the "imperative style", we're dealing with elements, while functional style is focused around sequences.
On the other hand, these concepts and expressions are used with so many different meanings and in so many different contexts, that it's no surprise that different people understand them differently. Maybe it's better to just talk in code...
Interestingly, the class system of Ocaml is one of its least useful parts. This is basically because most uses for inheritance (mixins, interfaces) are covered by first class functions.
> However, this is also imperative - we're telling the computer what to do.
No we don't (if you except the assignment to even). The fact that "filter" is an active verb is slightly misleading here. It deludes us into thinking the computer does something. (Well, it does, but not in the imperative programming sense of the word.) A more correct name would be "filtered", which makes it clearer that it produces a result, which is a filtered version of its second argument. I we wanted to be pedantic, "filter" should be reserved for a procedure that actually modifies its argument in place. But as there's no such procedure in the standard library of the typical functional language, it doesn't really matter.
"Imperative and object oriented are two different things" - Martin Odersky. An object is just a something that implements an interface and an interface is just a collection of functions. It may or may not have mutable state. That's why OO and functional are really just two sides
of the same coin. I think that tightly associating a set of functions with data is still a very good way to organize programs for the same reasons that it always was. Its the over use of the imperative bit of many languages that caused all the problems.
> > OO languages (i.e. imperative)
>
> Why can't an OO language be functional?
Yes, I think you are totally right. As I see it, OO is about data and behaviour encapsulation, and object polymorphism. There is no reason why objects need to carry mutable state. But, they often do, and I think most authors do put OOP in the procedural/imperative side of programming.
Of course come cool hybrid languages do mix concepts from OOP and functional programming in order to have more expressive power. But most of them still map pretty closely to the Von Neumann model: a set of statements executed one after the other that alter the program's state, and hence are imperative too.
A functional program does not map it's computation to this Von Neuman model, which pretty much represents how computers work, but to an abstract model, usually based on mathematical concepts.
Therefore,
even = filter(nats[1:100], i -> i % 2 == 0)
would be functional or not depending on the underlying execution model. A functional programing language would guarantee that the function passed to `filter` is side-effect-free, so it can be free to make the computation of the result in parallel or lazily or whatnot. An imperative language would be required to execute the passed function for each element of the sequence in a defined order, as that function might very well not be side-effect-free.
But, in the end, I think that all that is a very absolutist approach to what is functional and what is not. Trying to draw that line is usually quite futile, as it really depends on very strict definitions, and, well, everybody agreeing on those definitions. I just wanted to clarify my point a little bit (though I probably failed)
> On the other hand, these concepts and expressions are used with so many different meanings and in so many different contexts, that it's no surprise that different people understand them differently. Maybe it's better to just talk in code...
Totaly agreed. Probably a more "fuzzy" definition of "functional", thus allowing one to say that some construct "more functional" than an other one, is more pragmatic. I also would say that
even = filter(nats[1:100], i -> i % 2 == 0)
is much "more functional", or declarative, than
even = []
for i = 1 to 100
if i % 2 == 0
even.append(i)
And I would even say that Python's list comprehensions are even more declarative, even though it is an imperative language too:
Why can't an OO language be functional? OCaml is OO, and it's one of the most functional languages I know (the other being Haskell). Scala is a functional language and an OO language (and an imperative language, as a matter of fact). Clojure could also be considered OO, with the new protocols. Javascript is a very OO language, and quite functional as well (especially considering the libraries such as Underscore). Maybe we should be talking about functional and imperative programming styles instead, imperative being a loop, and functional being a recursive function (map, filter, fold/reduce).
> declarativity instead of an imperative style of programming
I guess there's a thin line separating these concepts, and also a great deal of overlap and confusion. Here, we're declaring what we want:
Here, we're using "the imperative style": This is functional style: However, this is also imperative - we're telling the computer what to do. The main difference is just that in the "imperative style", we're dealing with elements, while functional style is focused around sequences.On the other hand, these concepts and expressions are used with so many different meanings and in so many different contexts, that it's no surprise that different people understand them differently. Maybe it's better to just talk in code...