4 ms·

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

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.
  - _sh 14y ago
    Although it looks impoverished, it's really just a foundation for developing your own abstractions, and syntactic sugar goes a long way (I've bound the Alt-> key to → and use it for 'send'). CLOS-like systems can be built on structs with the racket/generic module and Typed Racket makes multimethods trivial.
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.

_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.
- _sh 14y ago
  Although it looks impoverished, it's really just a foundation for developing your own abstractions, and syntactic sugar goes a long way (I've bound the Alt-> key to → and use it for 'send'). CLOS-like systems can be built on structs with the racket/generic module and Typed Racket makes multimethods trivial.

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.