5 ms·

One important thing to point out: functional programming and object-oriented programming aren't necessarily mutually exclusive. Scala, OCaml, and a lot of Lis

by j_baker 17y ago

One important thing to point out: functional programming and object-oriented programming aren't necessarily mutually exclusive. Scala, OCaml, and a lot of Lisps have proven that. Whether it's a good idea is another question entirely, but the point is that it can be done.

Flow 17y ago
Immutability and OO certainly feels mutually exclusive. :-/
Silhouette 17y ago
> One important thing to point out: functional programming and object-oriented programming aren't necessarily mutually exclusive. I'm not sure that's true. The essence of functional programming is treating a program as evaluating a function without carrying around state, a declarative approach that promotes things like pure functions and referential transparency. The essence of object-oriented programming is passing messages between objects with identity, state and behaviour, an imperative approach and one that fundamentally relies on late binding at run-time. Aren't these styles mutually exclusive? Of course, you can have tools representative of both styles, such as higher order functions and abstract data types, in the same language; the languages you mentioned all do. But whatever merit the resulting hybrid programming style may have, I'm not sure that style is properly called either functional or object-oriented programming.
- j_baker 17y ago
  "The essence of functional programming is treating a program as evaluating a function without carrying around state" Isn't a closure a function that carries around state? There's an old tale about this: "The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened." http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
  - Silhouette 17y ago
    > Isn't a closure a function that carries around state? Well, that's the question, isn't it? In our present context, to me "state" suggests something persistent and independent, something that could be read and possibly written by multiple paths. Do you view creating a closure as customising an existing function with specific data, or as defining a whole new function? I think of it as the latter, and it just happens to be at run-time. The resulting function is still pure, and any customisation based on particular data is an integral part of it that isn't externally visible, which doesn't feel "stateful".
silentbicycle 17y ago
They're not mutually exclusive, but they tend to push program design in different directions. There's tension when you try to make a whole program OO and functional, but you can make pockets of OO when it really is the best approach, and give them a functional interface,

by j_baker 17y ago

Flow 17y ago

Immutability and OO certainly feels mutually exclusive. :-/

Silhouette 17y ago

> One important thing to point out: functional programming and object-oriented programming aren't necessarily mutually exclusive. I'm not sure that's true. The essence of functional programming is treating a program as evaluating a function without carrying around state, a declarative approach that promotes things like pure functions and referential transparency. The essence of object-oriented programming is passing messages between objects with identity, state and behaviour, an imperative approach and one that fundamentally relies on late binding at run-time. Aren't these styles mutually exclusive? Of course, you can have tools representative of both styles, such as higher order functions and abstract data types, in the same language; the languages you mentioned all do. But whatever merit the resulting hybrid programming style may have, I'm not sure that style is properly called either functional or object-oriented programming.

j_baker 17y ago
"The essence of functional programming is treating a program as evaluating a function without carrying around state" Isn't a closure a function that carries around state? There's an old tale about this: "The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened." http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
- Silhouette 17y ago
  > Isn't a closure a function that carries around state? Well, that's the question, isn't it? In our present context, to me "state" suggests something persistent and independent, something that could be read and possibly written by multiple paths. Do you view creating a closure as customising an existing function with specific data, or as defining a whole new function? I think of it as the latter, and it just happens to be at run-time. The resulting function is still pure, and any customisation based on particular data is an integral part of it that isn't externally visible, which doesn't feel "stateful".

silentbicycle 17y ago

They're not mutually exclusive, but they tend to push program design in different directions. There's tension when you try to make a whole program OO and functional, but you can make pockets of OO when it really is the best approach, and give them a functional interface,