[savingGrace]

I felt as though I should know the moral of the story, yet I did not.

https://stackoverflow.com/a/11421598 Moral of the story is that closures and objects are ideas that are expressible in terms of each other, and none is more fundamental than the other. That's all there is to the statement under consideration.

[gfxgirl]

Maybe I'm mis-understanding the definition of class or object but isn't a "File" in even Haskell an example of a class. Files have state which is either the read head or write head and in most languages you can change the head using seek.

I don't think the fact that you call `file.seek` vs `seek(file)` the difference between functional and object oriented. functional people say "state = evil, side effects = evil" and yet that version of `seek` has both.

The functional version of files would have to move the head out of the file

newWritePosition = write(file, currrentWritePosition)

And there would be no need for seek since you're holding your own write and/or read position.

If you close over a bunch of state and pass back a function or functions to work with that closed state you've just created an object with state and side effects. That's exactly what FP people say is bad.

[wwright]

I can’t speak for all functional programming advocates, but personally, when I criticize “classes” it is because of the overall design/culture and not because of encapsulating state/side effects.

- Subclassing is notoriously misleading and confusing and almost never truly useful (true subclassing, not abstract subclassing/interfaces).

- Class syntax/semantics are usually divorced from the other semantics of the language; closures are usually a much simpler design to achieve the same power. (You can get class-like ideas with simpler ideas too, but I think most “class” features don’t.)

- Culturally, classes are often viewed as mythic/special in a way that’s kind of out of touch with mapping problems to solutions. Look at “typical” Java code full of classes for crazy tasks like implementing 20 getters and constructing a factory to create callbacks. All of these things are related to the problem, but there’s a lot of friction/mismatch because people are taught to “use classes.”

[AlexanderDhoore]

I don't know what your point is here. When you do IO, even in Haskell, you will be mutating state in the outside world. Also know that many functional languages, especially the lisps, will allow you to mutate state in a closure.

[AlexanderDhoore]

It's code and state. Nothing more. Nothing less.

[jl2718]

My first computer book was: “Data Structures + Algorithms = Programs”. Thinking in this way has simplified my code tremendously. I think OO is taught because it’s more tactile. Literally it takes more keystrokes, and so much is pattern repetition that it facilitates learning and feels like progress. Functional is like learning Latin by studying Ovid one word at a time. When books (or mips) were expensive, this was how it was done. Even OO is old-school now though; today’s introduction to programming is mostly configuring CSS and webpack.

[jimmaswell]

OO is just the most intuitive way to compartmentalize state to many people, me included.

[cessor]

I feel the same way.

[cessor]

How do you model changes in state over time? (i.e. effects and processes?)

[AlexanderDhoore]

Is this a trick question? You mutate the state, of course.

[cessor]

True. But given that the difference in implementation appears to be arbitrary, the real differene between oop and fp must be evaluated in the domain of empirical research regarding their ergonomics. If one matches your natural thoughtpatterns more closely (be that abstract or concrete modelling) or educative efforts (it might be that one is easier to understand), or ease of implementation, that would be an argument for or against it.

Although Java might be conceptually weak, empirically speaking it's a big winner, because developers appear to value ease of education, connectedness with others, availability of jobs and job security more than feeling stupid for not understanding lambda calculus. (that doesn't render formalist approaches invalid)

[wwright]

You absolutely do not need to understand lambda calculus to leverage FP. (And similarly, you don’t need to understand Turing machines to leverage imperative styles.)

Tools like ReactJS and regular expressions would indicate that the market for FP is quite large in spite of the popularity of Java as well, IMO