4 ms·

"The object-oriented model makes it easy to build up programs by accretion." On a similar note that object-oriented model makes it easy to write code when you

"The object-oriented model makes it easy to build up programs by accretion." On a similar note that object-oriented model makes it easy to write code when you don't understand the problem yet. "I know I'll need a Patient and a Doctor and a Diagnosis ..." Soon you have all these pretty objects and interfaces and Patient and Doctor inherit from Person and ... I've seen people with literally dozens of objects who still had no idea what they were building or why and couldn’t answer basic questions about the problem domain.

michaelochurch 14y ago
Alan Kay's idea of OOP-- encapsulate complexity behind a simple interface, and separate the two while preferring stability in the latter-- was utterly sound and right. He wasn't saying, "go off and write opaque, complicated objects". He was talking about what to do when complexity becomes inevitable. The SQL database (a brilliant, wonderful thing despite the hatred it gets) is an example. When you write a query, you don't tell it which indexes to hit and how to micromanage details. You send a declarative query to this "black box" that, most of the time, does the right thing. I think Objects are a good thing, but they should be rare. Very rare. As with macros, only use them when the simpler tools (referentially transparent functions, immutable data) won't do. Files are a case where the object metaphor makes sense-- there's a bunch of tightly-wound connected state, and I/O is inherently stateful. The problem with "OOP" is that it's "programming as micromanaging, inept businessmen understand it". Instead of math, it's Factories and Visitors and other nonsensical "big picture" bullshit that doesn't map in any coherent, reliable way to the underlying substrate (mathematics, logic) of computation. I'm sorry, but programming is a game where if one doesn't understand the details, one doesn't understand the fucking big picture (which is made up of extremely important details).
- _sh 14y ago
  Files are a case where the object metaphor makes sense-- there's a bunch of tightly-wound connected state, and I/O is inherently stateful. And user interface widget libraries, which are all about I/O. Even Racket's widget toolkit leverages the superb racket/class encapsulation mechanism.
  - eru 14y ago
    We get by without OOP in the widget library (creatively called Widget) we use for a Haskell-flavoured language at work.
  - tikhonj 14y ago
    For UI code, you should check out functional reactive programming (FRP). It essentially provides first class time-varying values instead of implicitly modelling time with mutable state. This makes UI code more declarative and allows you to create things like neat combinators. As an example, it's very easy to write a function like `when' with FRP, which could be used like this (code roughly from a game of life app I wrote): when (not <$> paused) (step <$ time) Here `time' is just a stream of events every x milliseconds. So what this code does is create a stream of step events which represent stepping the life simulation forward at each time step, as long as the game isn't paused. `paused' is a value based on a button, but it could easily have multiple inputs. So you get signals and event streams like `paused' and `time' from UI widgets (or the system), and then combine them into new streams that you can plug directly into UI widgets. This then lets the widgets themselves be much simpler structures with not internal state. In essence, this replaces arbitrary mutable state with an explicit dependence on time which leaves less room for making mistakes while also making it easier to write high-level functions like `when'. There's a ton of other cool things you can do--this is just an example meant to illustrate the sort of abstractions you can use; it is by no means exhaustive! I've found that FRP leads to much nicer UI code than callback-based OOP.
    - michaelochurch 14y ago
      FRP seems deeply awesome. Thanks for explaining it.
  - flyinRyan 14y ago
    >the superb racket/class encapsulation mechanism. Superb? The racket class system strikes me as awful/embarrassing. The language at least looks functional in nature, but to do OO they implemented this ridiculous single dispatch mechanism (manually calling "send" no less!). Why on earth didn't Racket end up with a CLOS like system? They could have made anything they wanted, and yet they ended up with a system that will require people to write the Visitor pattern. Shocking.
- alipang 14y ago
  The SQL database (a brilliant, wonderful thing despite the hatred it gets) is an example. When you write a query, you don't tell it which indexes to hit and how to micromanage details. You send a declarative query to this "black box" that, most of the time, does the right thing. That sounds very much to me like 'A SQL database is an abstraction', and very little like 'A SQL database is somehow related to OO'. In facts it's really unnatural to map objects to relations, which is why you need yet another ORM abstraction on top of it, just to satisfy the OO silver bullet.
- lucian303 14y ago
  Programming isn't math. Let me restate that again: programming is NOT math. OOP works and is a paradigm because people can relate to objects and narrative best. It has much more to do with narrative and story. The word "language" is by design. Good OOP techniques can create great products. Whatever the code is, unless you're writing machine language, eventually, you compile to or run bits of existing machine code. The important part is encapsulating the complexity. OOP or not, that's should be the goal of any module. Not all the details are important all of the time. In fact, it's generally much more important to hide details so one can deal with large systems in an abstract way. In many cases, details are unavailable and black box systems have to be dealt with. The point is logical abstractions, not details, are the goal here. Just because you can write it in machine language doesn't mean you should.
- Ensorceled 14y ago
  "Alan Kay's idea of OOP-- encapsulate complexity behind a simple interface, and separate the two while preferring stability in the latter-- was utterly sound and right. He wasn't saying, "go off and write opaque, complicated objects". He was talking about what to do when complexity becomes inevitable." I agree completely, I was only pointing out another problem with OOP (or, if you will, OOP done poorly) is that it leads to the trap I mention.
praptak 14y ago
I know a company that used to ask in all seriousness "How would you model a car in an OO way?" during interviews, with the expected answer along the lines of Car, Engine, four instances of Wheel and so on. My friend totally stumped the interviewer asking him about the purpose of the modeling. You know, this revolutionary idea that a DMV might model a car slightly differently than a car mechanic. Late nineties, good times, OO was the silver bullet back then :)
- Ensorceled 14y ago
  Yeah, I was asked to model a graphics program in an interview and got into a argument about why circles should not be a subclass of ellipse. I explained that, yes, mathematically it's a degenerate case, but in a graphics package circles have different algorithms and different user interfaces. They actually have more in common with squares than ellipses. After about 10 minutes of no progress, I suddenly realized I would be working with and for idiots so I excused myself from the rest of the process.
  - praptak 14y ago
    Yeah, Liskov Substitution Principle. I believe that (mutable) circle and (mutable) ellipse is the chief example of the bad kind of inheritance wrt to this rule.
- vsync 14y ago
  I'm reminded of Pirsig's comments on the multiple ways you could break down a motorcycle, for example. The tyranny of the dominant decomposition is no joke, especially when single inheritance and single dispatch are so popular.

michaelochurch 14y ago

Alan Kay's idea of OOP-- encapsulate complexity behind a simple interface, and separate the two while preferring stability in the latter-- was utterly sound and right. He wasn't saying, "go off and write opaque, complicated objects". He was talking about what to do when complexity becomes inevitable. The SQL database (a brilliant, wonderful thing despite the hatred it gets) is an example. When you write a query, you don't tell it which indexes to hit and how to micromanage details. You send a declarative query to this "black box" that, most of the time, does the right thing. I think Objects are a good thing, but they should be rare. Very rare. As with macros, only use them when the simpler tools (referentially transparent functions, immutable data) won't do. Files are a case where the object metaphor makes sense-- there's a bunch of tightly-wound connected state, and I/O is inherently stateful. The problem with "OOP" is that it's "programming as micromanaging, inept businessmen understand it". Instead of math, it's Factories and Visitors and other nonsensical "big picture" bullshit that doesn't map in any coherent, reliable way to the underlying substrate (mathematics, logic) of computation. I'm sorry, but programming is a game where if one doesn't understand the details, one doesn't understand the fucking big picture (which is made up of extremely important details).

_sh 14y ago
Files are a case where the object metaphor makes sense-- there's a bunch of tightly-wound connected state, and I/O is inherently stateful. And user interface widget libraries, which are all about I/O. Even Racket's widget toolkit leverages the superb racket/class encapsulation mechanism.
- eru 14y ago
  We get by without OOP in the widget library (creatively called Widget) we use for a Haskell-flavoured language at work.
- tikhonj 14y ago
  For UI code, you should check out functional reactive programming (FRP). It essentially provides first class time-varying values instead of implicitly modelling time with mutable state. This makes UI code more declarative and allows you to create things like neat combinators. As an example, it's very easy to write a function like `when' with FRP, which could be used like this (code roughly from a game of life app I wrote): when (not <$> paused) (step <$ time) Here `time' is just a stream of events every x milliseconds. So what this code does is create a stream of step events which represent stepping the life simulation forward at each time step, as long as the game isn't paused. `paused' is a value based on a button, but it could easily have multiple inputs. So you get signals and event streams like `paused' and `time' from UI widgets (or the system), and then combine them into new streams that you can plug directly into UI widgets. This then lets the widgets themselves be much simpler structures with not internal state. In essence, this replaces arbitrary mutable state with an explicit dependence on time which leaves less room for making mistakes while also making it easier to write high-level functions like `when'. There's a ton of other cool things you can do--this is just an example meant to illustrate the sort of abstractions you can use; it is by no means exhaustive! I've found that FRP leads to much nicer UI code than callback-based OOP.
  - michaelochurch 14y ago
    FRP seems deeply awesome. Thanks for explaining it.
- flyinRyan 14y ago
  >the superb racket/class encapsulation mechanism. Superb? The racket class system strikes me as awful/embarrassing. The language at least looks functional in nature, but to do OO they implemented this ridiculous single dispatch mechanism (manually calling "send" no less!). Why on earth didn't Racket end up with a CLOS like system? They could have made anything they wanted, and yet they ended up with a system that will require people to write the Visitor pattern. Shocking.
alipang 14y ago
The SQL database (a brilliant, wonderful thing despite the hatred it gets) is an example. When you write a query, you don't tell it which indexes to hit and how to micromanage details. You send a declarative query to this "black box" that, most of the time, does the right thing. That sounds very much to me like 'A SQL database is an abstraction', and very little like 'A SQL database is somehow related to OO'. In facts it's really unnatural to map objects to relations, which is why you need yet another ORM abstraction on top of it, just to satisfy the OO silver bullet.
lucian303 14y ago
Programming isn't math. Let me restate that again: programming is NOT math. OOP works and is a paradigm because people can relate to objects and narrative best. It has much more to do with narrative and story. The word "language" is by design. Good OOP techniques can create great products. Whatever the code is, unless you're writing machine language, eventually, you compile to or run bits of existing machine code. The important part is encapsulating the complexity. OOP or not, that's should be the goal of any module. Not all the details are important all of the time. In fact, it's generally much more important to hide details so one can deal with large systems in an abstract way. In many cases, details are unavailable and black box systems have to be dealt with. The point is logical abstractions, not details, are the goal here. Just because you can write it in machine language doesn't mean you should.
Ensorceled 14y ago
"Alan Kay's idea of OOP-- encapsulate complexity behind a simple interface, and separate the two while preferring stability in the latter-- was utterly sound and right. He wasn't saying, "go off and write opaque, complicated objects". He was talking about what to do when complexity becomes inevitable." I agree completely, I was only pointing out another problem with OOP (or, if you will, OOP done poorly) is that it leads to the trap I mention.

praptak 14y ago

I know a company that used to ask in all seriousness "How would you model a car in an OO way?" during interviews, with the expected answer along the lines of Car, Engine, four instances of Wheel and so on. My friend totally stumped the interviewer asking him about the purpose of the modeling. You know, this revolutionary idea that a DMV might model a car slightly differently than a car mechanic. Late nineties, good times, OO was the silver bullet back then :)

Ensorceled 14y ago
Yeah, I was asked to model a graphics program in an interview and got into a argument about why circles should not be a subclass of ellipse. I explained that, yes, mathematically it's a degenerate case, but in a graphics package circles have different algorithms and different user interfaces. They actually have more in common with squares than ellipses. After about 10 minutes of no progress, I suddenly realized I would be working with and for idiots so I excused myself from the rest of the process.
- praptak 14y ago
  Yeah, Liskov Substitution Principle. I believe that (mutable) circle and (mutable) ellipse is the chief example of the bad kind of inheritance wrt to this rule.
vsync 14y ago
I'm reminded of Pirsig's comments on the multiple ways you could break down a motorcycle, for example. The tyranny of the dominant decomposition is no joke, especially when single inheritance and single dispatch are so popular.