Hacker News Reader

Comment by Ensorceled | Hacker News Reader

    "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.

View on HN

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).

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.

We get by without OOP in the widget library (creatively called Widget) we use for a Haskell-flavoured language at work.

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.

FRP seems deeply awesome. Thanks for explaining it.

>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.

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.

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.

   "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.

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 :)

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.

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.

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.

Reply on news.ycombinator.com