3 ms·

The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to

The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to pure FP. The OCaml community presents a pretty compelling third option: OCaml is billed as a 'functional language,' but it doesn't do anything to prevent you from performing mutations or executing side effects anywhere you want. It even has builtin syntax for "for" and "while" loops. Interestingly, OCaml does afford classes and objects but hardly anyone seems to use them. It's not that OCaml objects are weird or difficult or bad in some way. People just choose to write records and functions. Some of those records have functions in them. Some of the functions mutate state. In the OCaml world, at least, pretending OOP never happened seems to have worked out just fine.

autokad 6y ago
> "The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to pure FP." I disagree. I dont think that is what the author was saying at all, not even a little bit: "100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches — say to 85% — then it really does work. ... It’s possible, and a good idea, to develop large parts of a system in purely functional code. But someone has to write the messy parts that interact with the outside world."
- implicit 6y ago
  The problem is the way the author instantly jumps from "98% pure functional programming doesn't work" to "you should use OOP." In order to bridge the gap, you have to make some pretty terrible assumptions: If your code is not OO, it must be FP. If your code is FP, it must be pure. Therefore, If your code cannot be pure, it must be OO.
mrkeen 6y ago
There isn't really a middle-ground (with regard to side-effects) despite people arguing for or against it - much like those memes where someone declares that they're not 'for' or 'against' abortion. Either I can rely on the fact that `foo() == foo()`, or I can't. Either I can rely on the fact that `map f . map g == map (f . g)`, or I can't.
- mrkeen 6y ago
  Care to enlighten me?
  - implicit 6y ago
    The properties you describe regarding pure functions are correct and useful, but those ideas miss the point: Neither OO nor pure FP are required to build high-quality software! OCaml developers have been living in this world for decades now and they seem to get by just fine. Further, they do this purely by choice! Their language has had OO syntax for decades and they are happy ignoring it!
jcelerier 6y ago
> In the OCaml world, at least, pretending OOP never happened seems to have worked out just fine. ... you know that the "O" in OCaml stands for object-oriented... right ?
- smabie 6y ago
  And over 99% of OCaml projects don't use objects at all. You would be hard pressed to find an OCaml developer who would care if objects were just removed from the language entirely.

autokad 6y ago

> "The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to pure FP." I disagree. I dont think that is what the author was saying at all, not even a little bit: "100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches — say to 85% — then it really does work. ... It’s possible, and a good idea, to develop large parts of a system in purely functional code. But someone has to write the messy parts that interact with the outside world."

implicit 6y ago
The problem is the way the author instantly jumps from "98% pure functional programming doesn't work" to "you should use OOP." In order to bridge the gap, you have to make some pretty terrible assumptions: If your code is not OO, it must be FP. If your code is FP, it must be pure. Therefore, If your code cannot be pure, it must be OO.

mrkeen 6y ago

There isn't really a middle-ground (with regard to side-effects) despite people arguing for or against it - much like those memes where someone declares that they're not 'for' or 'against' abortion. Either I can rely on the fact that `foo() == foo()`, or I can't. Either I can rely on the fact that `map f . map g == map (f . g)`, or I can't.

mrkeen 6y ago
Care to enlighten me?
- implicit 6y ago
  The properties you describe regarding pure functions are correct and useful, but those ideas miss the point: Neither OO nor pure FP are required to build high-quality software! OCaml developers have been living in this world for decades now and they seem to get by just fine. Further, they do this purely by choice! Their language has had OO syntax for decades and they are happy ignoring it!

jcelerier 6y ago

> In the OCaml world, at least, pretending OOP never happened seems to have worked out just fine. ... you know that the "O" in OCaml stands for object-oriented... right ?

smabie 6y ago
And over 99% of OCaml projects don't use objects at all. You would be hard pressed to find an OCaml developer who would care if objects were just removed from the language entirely.