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

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

leshatton.org

Post reply on HN
Print view View original

171–180 of 253 posts

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

#171

Post by tome »

cousin_it wrote: post #55

No comment about OO in general, but I think Java/C# is a damn fine language design, avoiding many problems of newer paradigms. Here's an example: 1) Java: starts out with one opaque string type, because that's what OO methodology says. Changes the internals when needed. All clients continue to work forever. 2) Haskell: starts out with strings as exposed linked lists of characters, because functional methodology says…

> functional methodology says exposed algebraic types are OK

No, it absolutely doesn't. Functional methodology is absolutely orthogonal to data abstraction.

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

#172

Post by tome »

skrebbel wrote: post #59

Commenting more on this thread than the article: in my opinion, the idea that OO and functional are somehow at odds with each other is misguided. There is little about OO that doesn't mesh well with functional ideas, and vice versa. The core concept of most OO designs is that data is coupled with the methods that operate on that data. There is absolutely no reason why that can't work with immutable data and pure func…

> The core concept of most OO designs is that data is coupled with the methods that operate on that data.

I've read this a lot, in this discussion and elsewhere, for years. But what does it mean? Does it mean data is syntactically coupled with state? Otherwise I don't get why pretty much any C program is an OO design by this definition.

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

#173

Post by imtringued »

willtim wrote: post #19
gnaritas wrote: post #12

Earlier quoted context omitted.

> However, OOP fundamentally results in a combinatorial explosion of state Eh, no it doesn't. I think you need to expand on that statement because it isn't remotely true in my experience.

I've now expanded on that statement. In my experience, working using OOP in large multi-million line codebases, the state issues have proven very true.

How can you know that without comparing the same programs with a FP version? What if those codebases would become messy even with FP simply because the problem they are trying to solve is difficult? Also in what way does OOP prevent you from writing the code in a FP-style? It doesn't because the concepts FP and OOP are orthogonal.

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

#174

Post by jkrems »

alkonaut wrote: post #28

OO solves some problems and creates others. One must remember that the competing paradigm isn't functional programming but imperative procedural programming. Very large code bases in C, Fortran, Cobol aren't all that nice either. It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Many of OO's flaws are being addressed and are even missing from new languages. Rust "feels" OO…

The article is about how C & Fortran ("traditional languages" by 1997 standards) compare to C++. This is not about functional- but procedural languages vs. OO. (!)

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

#175

Post by nurettin »

SwellJoe wrote: post #101
theboywho wrote: post #92

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…

Actually, the article makes some far-fetched assertions which may not even correspond to reality and may not even be worth discussing at all.

OO (in this case the author means C++) is less related to a programmer's understanding of reality compared to C because... programmers of the 90s make more errors that are harder to fix in C++.

Yeah. Right.

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

#176

Post by rleigh »

abhishekash wrote: post #20

But then if OO is a dud then why do we have some of its implementations C#, C++ and Java drive most of the enterprise. If they would not have existed would we have same amount to faith of enterprises to move to adopt software applications to run daily business.

OO was a fad for how many years? All these languages were strongly influenced by this, and this greatly colours the worldview programmers have who work with these languages.

If you work in Java, everything is contained within a class. You can't easily think outside the OO box because the language insists that everything you do is done in terms of OO, and this has great implications from the standard library, to primitive type boxing. It's very much constrained by the prevalent trends of the mid-90s. C++ is a more OO agnostic, it being something you can opt into as and when it makes sense.

I certainly don't think OO is a "dud", and it's provided a conceptual framework for programmers of wildly varying abilities to create and maintain vastly complicated codebases. But... it's only one way of many to structure and reason about program logic and data, and to constrain oneself to only using OO is greatly limiting. Now the hype has died down, I hope we can use OO where it fits, and avoid it where it does not, rather than as a blunt instrument for every problem?

The main problem I see in my day to day work (imaging related) is that OO is too costly. Arrays of object instances are too cache unfriendly. And code doesn't always need to be directly tied to data. I see Java code using collections of primitive arrays in place of objects because most OO languages don't provide a means of laying out objects in column stores, even though it wouldn't be technically difficult (just different offsets to members rather than packed structures). Treating objects as individual private collections of state leads to only being able to work with an object-centric rather than data-centric view, which can be quite detrimental. It's this view that leads to abominations like database object mappers, treating tabular data as object collections when they are not. While such things are possible and even popular, they often come with significant tradeoffs. I've encountered developers who are completely constrained within an OO worldview and can't take the blinkers off and see what's possible outside the box.

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

#177

Post by SwellJoe »

krapp wrote: post #110
SwellJoe wrote: post #101

Earlier quoted context omitted.

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.

Hashing the title when first posted would likely lead to more quality problems. The first stage of QC is New. Nothing makes it to the front page without a little time on New.

So, I think that hashing titles would make it so that the worst (by some definition, but one that probably matches HN's definition) clickbaity stuff would rise to the front page faster and more often. This would happen because people could no longer make any decisions about what to click on New by it's title, and so the short articles that confirm common tropes, the funny pictures, etc. would get people coming back faster to click the upvote, while the longer articles would be more slow to get upvotes.

Same problem we have already, only moreso. At least now, we have a stage where we can see the title in New and the interesting things might get upvotes sooner...you have a little more knowledge going in. i.e., I might not read the whole article about something I find really interesting, but I might click over to it, see that it's by someone I trust or seems to be well done and free of fluff, and upvote it before finishing reading.

I dunno. I could see blocking commenting for a time after a post. But, hashing titles seems to just take away valuable information people use to make upvote decisions during the vital New phase of a post. Also, there's no way I'm clicking on every link on New. New is a goddamned wasteland; 50+% garbage, sometimes.

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

#178

Post by SwellJoe »

Pica_soO wrote: post #160
SwellJoe wrote: post #101

Earlier quoted context omitted.

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…

one could make a sort of article captcha..

That'd be a fun AI project that would be reasonably easy with off-the-shelf components: A summarizer and test generator.

It'd probably generate a lot of false negatives, though. Even humans make bad comprehension tests sometimes.

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

#179

Post by tome »

mpweiher wrote: post #57
willtim wrote: post #47

Earlier quoted context omitted.

Passing a common struct into one or more procedures is absolutely not what is commonly understood as object-oriented programming. This is what people did (and are still doing) long before OOP existed. I also do it all the time in Haskell. Similarly that article is wrong to imply that all these techniques are unique to OOP.

It absolutely is. OOP languages formalized this pattern and made it easy to use.

OOP languages formalized the pattern of passing data structures into procedures?!

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

#180

Post by magnusjonsson »

dyarosla wrote: post #136
jwdunne wrote: post #122

Earlier quoted context omitted.

Thank you - I think this was probably the inspiration or seed for what I was thinking :) I was amazed when I saw the ECS architecture when I filled my toe into game development. I remember wanting to apply it to other areas outside of game development. It's interesting though that a paradigm that intends to help simulate the real world has been eschewed for speed and maintainability in favour of something like ECS in…

Yeah it's an interesting pattern and even when implemented in an OOP language ignores most OOP ideas in favour of what is really more akin to data-driven design. There's some great insight into how the pattern evolves in non-game projects here: https://softwareengineering.stackexchange.com/a/306983/27143...

That's an awesome article! Thanks for sharing.
Post reply on HN