Joe Armstrong: Why OO Sucks

Yes, but pure OOP has been proven impractical many times over the last 20 years. What we are looking for here are practical rules that will help us organize our code in an OOP framework.

So the date format formats the date. Why is that? Why is date subordinated to date format here?

Actually the name "DateFormat" is unfortunate. It should have been "DateFormatter", because it is clearly an actor object - while a date is a data object. Suppose you have a fire in your house, you want help to extinguish it. So you call a fireman, and you basically say to him "here's a fire : do your job". In the present case you have a date, and you want to format it. So you "call" a DateFormat(ter) and you say "here is a date : do your job". That's exactly the same, natural principle of delegation. If you need something to be done, call an expert to do it for you.

Of course it gets quickly tedious having to explicitly call the actor objects for everything. So it might be useful to add "convenience methods" to the data objects, which would simply call the appropriate default actor and pass themselves as arguments to the work operation. So here you would then be able to call date.format(DateFormat.LONG), which means any date would basically become able to format itself. It has good and bad sides, and there is no clear answer (that I know of) to determine in which cases it's okay to do that or not.

s = format(date, date_format) makes a lot more sense to me

That's because you see formatting as an action, and you're thinking action => function. In an OO environment you should rather be seeing formatting as a responsibility, and thinking responsibility => class.

I think you are making two mistakes:

(1) Assuming that any good API/interface must be object-oriented; and

(2) Assuming that, when using object-oriented programming, that good APIs/interfaces come naturally.

Cells are obviously a very successful kind of module. What does that really mean? It's just an analogy. Erlang, the "non-OOP" language under discussion, seems to resemble cells at least as well as "OOP" languages (perhaps more so, because you don't have to synchronously wait for a response for every interaction).

This is part of the reason that people call erlang an OOP language. So clearly there is a major confusion over terms here, because the creator of erlang didn't originally consider it to be OOP.

OK, so let's assume that we're actually talking about something that is as non-OOP as I can imagine: haskell. Let's also assume that haskell doesn't resemble cells as much as OOP does. There are still problems:

* Many interfaces in haskell are very well-designed, so it's hard to argue that OOP has a monopoly on good interface designs

* It's not clear that the goals you mention, such as unexpected dependencies, are actually reduced by using OOP.

* It's not clear that a superficial similarity with cells really translates to anything meaningful. If nothing else, evolution of cells takes place on million-year timescales, and doesn't drive toward any one particular kind of outcome other than self-perpetuation; which are not a good set of properties when it comes to project management.

http://www.daimi.au.dk/~madst/tool/papers/expression.txt

In brief, if you think of data types are rows, and behaviors as columns, the question is how to extend either the rows or the columns naturally.

In your example, it is easy to add a new row (datatype) – create a Triangle class which implements the Drawable interface. It is difficult to add a new column (behavior) – if you realize all of these datatypes should also have a "extrude to additional dimension" behavior, you're going to have to individually implement that in all of your different classes, across many different files, etc. All of the problems that you note arise when adding a new datatype in the FP strawman.

It's important to recognize that this is indeed a difficult problem, and that addressing it well takes real care.

The c2 wiki has a good distillation:

http://c2.com/cgi/wiki?ExpressionProblem

and this paper (by the Scala people) is very nice:

http://www.scala-lang.org/docu/files/IC_TECH_REPORT_200433.p...

Some approaches that languages take, to varying degrees of success, include typeclasses in Haskell, multimethods in Clojure and elsewhere, the Visitor or Extended Visitor patterns in OO languages, controllable extensions in C#, Ruby, and Scala, etc.

Neither argue that FP can't be built modularly with a wonderful structured API. OOP, conceptually, is simply one way to accomplish that goal. FP is another.

In both cases, the underlying philosophies are sound, it is the humans that implement the solutions that fall well short of the mark.

I understand what you're saying and I understand OO design very well because I used it for decades. I just don't agree. The question we're asking here, I think, is not "how should you behave in an OO environment?", the question is "is OO a good software design principle".

My answer to that is no, and your insistance on dividing classes into data and actor classes tells me that you're well on your way to joining my opinion soon ;-)