4 ms·

I'm not so sure. What advantages does OOP have?

ajuc 16y ago
Every program is either a compiler, or an interpreter. Compilers are just functions from input to output, so it is easy to write them in a functional way. For example code formatter, report generator, any program in which we are only interested in the final result, not in the intermediate steps, and nothing "new" can happen in the process of computation. Interpreters are more imperative by nature, and it is more natural to write them in imperative way. For example real-time simulations (including games), interactive apps like offices suites, crud apps, etc. In interpreters functional programming can be used in the small scale, to implement commands, but the result will be imperative interpreter with state and commands that modifies this state. So oop is more suited to describe domain of most programs - users think about crud apps like this: "this button changes the name of selected student", "this button deletes student from base", "this button assigns student to course". Even if under the hood there is functional code, it is in reality interpreting imperative language and operating on state. At least that's how I see it. YMMV.
- evanrmurphy 16y ago
  Every program is either a compiler, or an interpreter. Great insight. Thanks for teaching me about this.
  - ajuc 16y ago
    Not mine insight but I can't remember where i've read it.
- joe_the_user 16y ago
  Sorry, the compiler/interpreter division is nice but it's just one design pattern. Works good till you reach a problem domain it's not appropriate for. Models are great till you take them for reality.
  - RodgerTheGreat 16y ago
    It's easy to be dismissive, but your criticism would probably be a good deal more constructive if you provided an example of an application where this division does not apply. I've often thought that the recent emphasis on functional languages stems from the fact that webapps are where a great deal of innovation has been coming from lately. The design of the HTTP protocol makes it particularly straightforward to think about server-side code as a series of stateless (ignoring the database) transactions. The "model" of inherently* functional tasks as compilers and inherently procedural tasks as interpreters does a good job of crystallizing this idea. (* When I say "inherently" functional or procedural here I mean tasks that lend themselves to being expressed cleanly one way or another.)
- weavejester 16y ago
  Mutable state does not necessarily mean OOP. For instance, in Clojure I could write a multimethod that updates refs of type Student, and Course: (defmethod assign [Student Course] [student course] (alter student update-in [:courses] conj course) (alter course update-in [:students] conj student)) There is polymorphism and mutability here, but we're not dealing with objects. So to rephrase my question: what are the advantages of OOP when dealing with mutable state?

ajuc 16y ago

Every program is either a compiler, or an interpreter. Compilers are just functions from input to output, so it is easy to write them in a functional way. For example code formatter, report generator, any program in which we are only interested in the final result, not in the intermediate steps, and nothing "new" can happen in the process of computation. Interpreters are more imperative by nature, and it is more natural to write them in imperative way. For example real-time simulations (including games), interactive apps like offices suites, crud apps, etc. In interpreters functional programming can be used in the small scale, to implement commands, but the result will be imperative interpreter with state and commands that modifies this state. So oop is more suited to describe domain of most programs - users think about crud apps like this: "this button changes the name of selected student", "this button deletes student from base", "this button assigns student to course". Even if under the hood there is functional code, it is in reality interpreting imperative language and operating on state. At least that's how I see it. YMMV.

evanrmurphy 16y ago
Every program is either a compiler, or an interpreter. Great insight. Thanks for teaching me about this.
- ajuc 16y ago
  Not mine insight but I can't remember where i've read it.
joe_the_user 16y ago
Sorry, the compiler/interpreter division is nice but it's just one design pattern. Works good till you reach a problem domain it's not appropriate for. Models are great till you take them for reality.
- RodgerTheGreat 16y ago
  It's easy to be dismissive, but your criticism would probably be a good deal more constructive if you provided an example of an application where this division does not apply. I've often thought that the recent emphasis on functional languages stems from the fact that webapps are where a great deal of innovation has been coming from lately. The design of the HTTP protocol makes it particularly straightforward to think about server-side code as a series of stateless (ignoring the database) transactions. The "model" of inherently* functional tasks as compilers and inherently procedural tasks as interpreters does a good job of crystallizing this idea. (* When I say "inherently" functional or procedural here I mean tasks that lend themselves to being expressed cleanly one way or another.)
weavejester 16y ago
Mutable state does not necessarily mean OOP. For instance, in Clojure I could write a multimethod that updates refs of type Student, and Course: (defmethod assign [Student Course] [student course] (alter student update-in [:courses] conj course) (alter course update-in [:students] conj student)) There is polymorphism and mutability here, but we're not dealing with objects. So to rephrase my question: what are the advantages of OOP when dealing with mutable state?