Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Joe Armstrong: Why OO Sucks

harmful.cat-v.org

Post reply on HN
Print view View original

131–140 of 267 posts

Re: Joe Armstrong: Why OO Sucks

#131

Post by jpatte »

fauigerzigerk wrote: post #126
jpatte wrote: post #122

Earlier quoted context omitted.

contract = agent.makeContract(property, seller, buyer) seller.signContract(contract) buyer.signContract(contract) agent.registerSale(contract) Nothing complicated here, really. Just follow the "natural" flow and respect each actor's role. Don't try to group all operations into a single one when there are independant actors involved. Note : I see the "contract.sign()" solution coming back a lot. I will admit this is "…

Your "data object" versus "actor" argument is intersting. Does that mean an object model should mimic certain properties of the real world that aren't even part of the system, like the knowledge that agents can act whereas contracts can not? There are clearly conflicting goals here. It could be that you need polymorphism along one hierarchy but that would make the design look very unnatural in the eyes someone who kn…

Clearly the goal here is not to simulate an ecosystem where agents, buyers and sellers happily live together.

However, the idea here is to organize your object model exactly as you would organize a group of employees. Each of these employees has a specific job and a specific set of responsibilities - ideally only one. You can describe the solution to your problem as the result of their interaction. These employees are actor objects.

To interact efficiently, they need to exchange information, in the form of data objects. These data objects don't do anything except hold a piece of information - exactly as you would have two employees exchanging notes or emails.

Most of the time these data objects correspond to the language of your problem domain. The actor objects however may have nothing to do with any "real world" activity, depending on the job you want them to do in the process. So yes, the object model diverge from reality over time because we introduce new actors with specific roles that have no "real world" equivalent. But that's just fine.

The important thing is to keep seeing the distribution of responsibilities among your objects and their interaction as the work of a team of independent experts, not as "things doing stuff".

Re: Joe Armstrong: Why OO Sucks

#132

Post by ioquatix »

it wrote: post #27
ioquatix wrote: post #18

Languages that are "OO" and languages that are not (in this case functions and data structures) are semantically equivalent. Q.E.D.

It is possible in principle to implement one in terms of the other, but in practice this is not what typically happens.

Sure, it might not be typical, but it does happen in quite a few languages. CLOS is one system that comes to mind.

FP vs OO is an interesting discussion but this article hardly does it justice.

Re: Joe Armstrong: Why OO Sucks

#133

Post by the1 »

nessus42 wrote: post #41

I've been watching some talks online recently by Rich Hickey of Clojure fame, and he's a very interesting and convincing speaker. He basically makes the same argument that Armstrong makes here. I'm not clear, however, how the pro-FP, anti-OO crowd address the Law of Demeter, which is often summarized as "One dot: good. Two dots: bad." The canonical example where the Law of Demeter serves us well comes from some of th…

DOM is a tree. Tree traversal, filter, fold, query, search .. are well known.

Re: Joe Armstrong: Why OO Sucks

#134

Post by Dn_Ab »

tikhonj wrote: post #125
Dn_Ab wrote: post #114

Earlier quoted context omitted.

This is the first time I've encountered this and what you wrote packs a lot of ideas in a small space so forgive me if I have misunderstood. What you write seems like an even more powerful version of the Active Patterns in F#, which are already really powerful. Active Patterns are the closest thing to First class patterns in a production language * . Haskell has a similar thing in views. But I think another concept,…

I'm afraid that I'm not too familiar with either active patterns or GADTs at the moment. However, given the understanding that I do have, I think they are both unrelated to the basic dynamic pattern matching that I was talking about. As far as I can tell, active patterns only affect the constructor . They let a constructor like Even to run an arbitrary function when it's matched. This lets you customize what a constr…

Excellent! Thank you, yes I am clearer, the concept is even more awesome than I thought .

>I think active patterns do not constitute first-class patterns.

I agree, but like I said, they are the closest thing in active use, they extend the type of structures one can deconstruct to encapsulated ones while being more flexible in implementation. They fall in the class of techniques which extend and make matching more flexible, other examples would be multimethods and predicate dispatch. So very much orthogonal to approaches in pattern calculi but I think in a subspace in terms of matching.

>GADTs are also unrelated. For one, GADTs only affect the type of a constructor

Yes they are unrelated that's why I focused on expressitivity, and you are right, I misconstrued what you meant by generalizes on constructors. But everything has a cost - runtime, learning, cognitive overhead - what I was curious of is: how much does the pattern calculus buy you? GADTs are another concept that allow one to elegantly tackle problems where it looks like the pattern calculus would help. I was just looking for an example where something like GADTs fumbles in comparison.

It's clearer to me now that the pattern calculus is definitely more flexible in terms of match semantics but I can't think of any situation in practice where this would give an added advantage.

Also, Is this typically done via term rewriting and is there anything on the decidability of this?

Re: Joe Armstrong: Why OO Sucks

#135

Post by borplk »

yen223 wrote: post #28
borplk wrote: post #12

From a purely scientific view, OO is a terrible idea because it moves the program further away from the mathematical form and makes it harder (if not impossible) to say, logically prove the correctness of the program. But from a practical perspective OO is a great idea because it makes many things so much easier.

"But from a practical perspective OO is a great idea because it makes many things so much easier." This seems true at first, but after having worked with C# a while I'm not so sure about that. OO introduces some weird issues that aren't immediately apparent: 1. Verbosity When the shortest method call looks like "abcObject.functionXYZ()", code gets huge really fast character-wise. This actually does make it harder to…

I think the advantage of OO is that is transforms the code into something that is closer to the "human" interpretation. Modelling the problem like we have it in real world. Instead of thinking like a computer, you can more easily think as a human and let the computer do the rest. Although of course it comes with trade offs.

Re: Joe Armstrong: Why OO Sucks

#136

Post by jpatte »

fauigerzigerk wrote: post #128
MarkMc wrote: post #112

Earlier quoted context omitted.

Without knowing any more about the system I'd suggest: contract.sign(property, buyer, seller, agent) It seems that properties, buyers, sellers and agents could exist without 'knowing' about contracts, but a contract at some point needs to reference the other entities. Also, it seems odd that the contract can exist without knowing the details of buyer, seller, etc. I'd prefer: new Contract(property, buyer, seller, age…

I would tend towards this solution as well, but does it meet the "looks natural" criteria? Contracts that sign themselves? I think many classes we invent are nothing more than processes in disguise and we could just as well model them as functions. A simpler example. Should the BankAccount class have a transferTo(BankAccount other) method to transfer money into another account? What if there are different account typ…

A simpler example. Should the BankAccount class have a transferTo(BankAccount other) method to transfer money into another account?

A BankAccount is a data object, so no processing in there. You could have a Banker object (or a MoneyExchanger object, which is "less real world" solution) which would be the actor object responsible for this task. So the natural message is myBanker.transferMoney(sourceBankAccount, targetBankAccount, amount).

What if there are different account types and the exact process depends on the types of both accounts?

You would need to handle of the possible cases into your actor object - which is why it is interesting here to have an actor object specialized in just that. There are several techniques you could apply to dispatch the call to the appropriate implementation of transferMoney().

I think many classes we invent are nothing more than processes in disguise and we could just as well model them as functions.

Well, yes, classes do things - at least actor objects do things. Btw actor objects generally have no state, so you can see them as "super functions", with many advantages over basic functions (inheritance, polymorphism etc).

Re: Joe Armstrong: Why OO Sucks

#137

Post by xyzzyb »

adeelk wrote: post #108
cageface wrote: post #58

Earlier quoted context omitted.

The funny thing is that most of these APIs wind up with what's essentially a "this" pointer at the front of every argument list so you're really doing OO anyway. I'd like to read a persuasive critique of OO but so far I haven't found one. Time objects are a really bad example because time calculations are exactly the kind of hairy mess you want to hide behind some kind of abstract API.

The funny thing is that most of these APIs wind up with what's essentially a "this" pointer at the front of every argument list so you're really doing OO anyway. Do you have much experience with non-OO programming? Or even OOP, for that matter? How can one honestly believe that every instance of passing data into functions is automatically OOP? Did you even consider the fact that this has nothing to do with objects?…

I'm sure that GP is referring to point number 2 of the article -- which explicitly says that time should (or at least could) just be data with no associated methods.

I winced at the naïveté in that section myself. It sure seems like he's arguing that OO programmers muddy the waters when they make something as "simple" as time and dates into an object with methods for storage and retrieval.

http://infiniteundo.com/post/25326999628/falsehoods-programm...

Re: Joe Armstrong: Why OO Sucks

#138

Post by einhverfr »

einhverfr wrote: post #115
nessus42 wrote: post #87

Earlier quoted context omitted.

> Have you ever tried to read any Demeterized code? What are you suggesting as an alternative? It should be noted that the original Demeter system would fetch sentences (or whatever) based on a description of the data structure that was provided by the implementer of the data structure alongside its implementation. In this system, you wouldn't have to examine code to answer your question, but you would have to be abl…

I think the obvious solution is to stop worrying about what's perfect on paper and instead approach things from two very simple questions: 1) What are my use cases? and 2) What should be abstracted in order to create the cleanest interfaces with the most predictable behavior? 3) What should be exposed to ensure that debugging is easiest? The answer here is simple, "everything." I think if we focus on clean interfaces…

I should have added, not only is it internally structured in order to provide a good user interface, but we've had hundreds of years of perfecting that user interface, so printing and book conventions are remarkably useful to the reader and ignoring them is always at one's own peril.

Re: Joe Armstrong: Why OO Sucks

#139

Post by ajuc »

fauigerzigerk wrote: post #92
MarkMc wrote: post #54

Wow, I am genuinely shocked by the comments in this thread. I didn't realise that so many people held the polar opposite view to me. It's a bit like suddenly finding out that all your friends are racist. I love object oriented programming. For me it aligns perfectly with the way I think - it allows me to produce a system of interrelated 'things' where each thing (or group of things) has a well-defined role and can hi…

So what is the natural and clean design for an operation that represents the sale of a property? Say we have these objects: the buyer, the seller, the agent, the property and the contract. Which one of these would you prefer? property.sell(buyer, seller, agent, contract) seller.sell(property, buyer, agent, contract) buyer.buy(property, seller, agent, contract) agent.sell(property, buyer, seller, contract) contract.si…

The usual answer, as always, is to add another layer of abstraction. Enterprise Java:

    @Resource("ejb/PropertySale")
    PropertySaleManager psm;

    psm.sell(property, buyer, seller, agent, contract);
This style of code is so popular in the code I've seen, that I almost think EJB3 is just conspiracy to allow procedural programming in Java, and to keep people thinking they still do OO to satisfy their egos.

Re: Joe Armstrong: Why OO Sucks

#140

Post by rapala »

einhverfr wrote: post #120
comex wrote: post #33

Earlier quoted context omitted.

I've had a conversation about it on HN in the past: http://news.ycombinator.com/item?id=4112517 I wouldn't mind discussing it again.

when zlib had that double-free bug a while back, how many programs had to be updated because of static linking? I think the problem is that in most of these cases, people only count one side of the ledger. On the whole, I think static linking causes more security issues than dynamic linking, but dynamic linking causes some other problems that are less well accounted for.

A security hole in a library is "automatically distributed" to every program dynamically linked against it. Yes, the coin has two sides.
Post reply on HN