Live data from Hacker News

Does OO really match the way we think (1997) [pdf]

leshatton.org

101–110 of 253 posts

Re: Does OO really match the way we think (1997) [pdf]

#101

I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.

Actually reading the whole article takes time, while reading the title and posting a knee-jerk reaction takes only a moment. One of the curses of a hotness-oriented system like HN is that earlier comments receive the bulk of the upvotes and responses, so it becomes less interesting to comment as time goes on.

There are lots of little rules in place to minimize the damage of this (like no memes, jokes, pics, etc.; HN actively discourages clickbait), but it can't force people to actually read the articles before responding. And, one doesn't have to read the articles to vote, either (again, HN mitigates that problem somewhat by requiring a minimum level of upvotes before being able to vote, etc.).

It's hard to have a substantive conversation online when so many of the incentives are for responding quickly (and probably without going too far against popular opinion within whatever community you're in).

Re: Does OO really match the way we think (1997) [pdf]

#102

OOP did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example functional has taken prominence in the 90s we'd be in a much better place now.

> set back program design

No one stops you writing program in whatever style you want. If functional programming has that of edge over OO, it would win over the argument long ago.

I don't like you assume other people don't know what is best for themselves, and needs some top-down expert to light the path. You argument, if there is one, sounds really preachy and proves no other than the point that support of functional programming here in HN are more about identity politics than actually making it useful to the crowd.

Re: Does OO really match the way we think (1997) [pdf]

#103

> Studying the copious literature of OO, the central features which define an OO system seem a little ill-defined. I didn't know opinion pieces could be disguised as academia. Of course the article has some interesting points about human memory, but that's why we have things like single responsibilities.

> that's why we have things like single responsibilities

I would argue that single responsibilities is nice to have. However, OO-style objects are responsible for both data and behaviour. Object-oriented languages themselves violate the SRP, to its own detriment.

Both functional and imperative languages tend to encourage separation of data and behaviour. I can operate on the same data structure implemented under a different context, without having to bring in its unrelated set of methods. This leads to cleaner code reuse and looser coupling - both nice properties to have in a complex codebase.

Re: Does OO really match the way we think (1997) [pdf]

#104

I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.

That's true but the HN algorithm for deciding what articles make it to the front page has itself become very political. For example, the amount of articles about programming languages like Rust or Elixir is disproportionate compared to their actual relevance in the industry. HN has a very strong bias for functional programming. You almost never hear about Go or Node.js anymore except when there is a major release but…

When Go and Node were new, they benefited from the same disproportionate level of interest here as Rust or Elixir currently do.

It's just the nature of the industry (and people in general). New and different is always more interesting than old but incrementally improved.

Re: Does OO really match the way we think (1997) [pdf]

#105
post #88
post #53

I think the big problem with OOP is that it's designed to simulate the real world but has the real world backwards. Real world objects are a composition of parts. The taxonomy of those objects, and its constituent parts, is am artificial construct independent of how those objects are composed. A frog is a frog because it fits some definition that experts agree on. The taxonomy comes afterwards - the composition just…

"In this way, OOP would benefit from composition-first, taxonomy after. An object is a thing because of what it has (and this includes behaviour too), not because of what it is or descended from." A lot of working programmers have figured this out already. Most experienced programmers I know don't use much inheritance.

Unfortunately OOP languages typically lack sum types, the mathematical dual of product types (objects with just fields). This means subtyping and inheritance is often needed to encode sum types.

Re: Does OO really match the way we think (1997) [pdf]

#106

I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.

Actually reading the whole article takes time, while reading the title and posting a knee-jerk reaction takes only a moment. One of the curses of a hotness-oriented system like HN is that earlier comments receive the bulk of the upvotes and responses, so it becomes less interesting to comment as time goes on. There are lots of little rules in place to minimize the damage of this (like no memes, jokes, pics, etc.; HN…

[deleted]

Re: Does OO really match the way we think (1997) [pdf]

#107

OOP did more to set back program design than anything else I can think of. It was incredibly wrong, has sent so many smart minds down a poor path. If for example functional has taken prominence in the 90s we'd be in a much better place now.

Poe's law strikes again!

Re: Does OO really match the way we think (1997) [pdf]

#108
A common sentiment expressed in threads like this is that people can write bad code in any language, therefore language doesn't matter. While that may be true, I don't think judging a language by the worse parts is a useful exercise. I'd rather judge a language by its best parts.

To that end, can someone point to me an example of object-oriented code that they feel is elegant?

Re: Does OO really match the way we think (1997) [pdf]

#109
post #76
post #69

Earlier quoted context omitted.

One of the main points of design patterns is composition over inheritance. Composition is also a major part of functional programming.

Yep, exactly! We now have a bunch if OOP languages that provide language features for inheritance making it easy but composition is an emergent property entirely based on existing language features - it's not a language feature itself. What I'm saying is flip it on its head. Build an OOP language where you have features to make composition easy and separate the taxonomy as a separate thing that shouldn't be tied dire…

Would you say that Scala is close to hitting that target? I've only taken a cursory look at it, but its traits appear to satisfy composition and its type system looks pretty close to being a decoupled taxonomy.

I'm not sure what a full implementation of a separate taxonomy would look like. Duck typing with an algebraic type system that is only applied when you ask for it?

Re: Does OO really match the way we think (1997) [pdf]

#110

I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.

Actually reading the whole article takes time, while reading the title and posting a knee-jerk reaction takes only a moment. One of the curses of a hotness-oriented system like HN is that earlier comments receive the bulk of the upvotes and responses, so it becomes less interesting to comment as time goes on. There are lots of little rules in place to minimize the damage of this (like no memes, jokes, pics, etc.; HN…

> but it can't force people to actually read the articles before responding

They could hash the title for a minimum time, or until at least three comments are posted.

That would at least force people to click the link to find out what's there, and filter out commenters too lazy to do even that.

Post reply on HN