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

191–200 of 253 posts

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

#191

Post by dyarosla »

lgas wrote: post #184
MikkoFinell wrote: post #156

Earlier quoted context omitted.

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, an…

Why does a component need to belong to a system? Why can't the component belong to itself and just be used by multiple systems?

Right, this is the general approach of ECS.

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

#192

Post by dyarosla »

bitwize wrote: post #183
MikkoFinell wrote: post #156

Earlier quoted context omitted.

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, an…

Components do not belong to a system. Any system can access any component. Think of RDBMS stored procedures that operate on all rows matching certain criteria; don't think OO style encapsulated "methods". The system only operates on entities that have all the components they need. So there won't be one rendering system but several: one for entities that require movement, one for those which do not, etc.

Almost right. You wouldn't necessarily have a separate rendering system for entities that require movement and those that do not.

Instead you would likely have an additional system that operates on entities that have both position and render components and propagates updates from position to render data. The render system for all entities with just a render component would then remain the same.

This can be imagined as systems that work on signatures (a component set or aspect that specifies whether an entity's components match the system's criteria).

A render system would have an aspect of say [RenderComp] and a positionRender system would have an aspect of say [RenderComp, PositionComp]. Note that the positionRender system would not actually render anything, only serving as a propagater of data.

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

#193

Post by brudgers »

logicallee wrote: post #159
brudgers wrote: post #151

Earlier quoted context omitted.

If writing is thinking (and googling "writing is thinking" quote produces plenty of hits), then object oriented code reflects the way we think because we write it...I mean thinking in terms of object orientation is pretty a given in order to right object orientated code. That's a different proposition than object oriented programming reflects the primary way humans think or the only way humans think. Without diving d…

By that standard it is impossible for any type system not to match the way we think: for example a programming language could be abstracted in terms of food, recipes, and breakfast, lunch, and dinner, and express literally everything that way. Although by your standard our code would then match the way we think, clearly this is not a useful takeaway.

That's not the idea I was trying to convey. I think any claim that any language (computer or ordinary or otherwise) captures the way people think independent of the use of that language is at least suspect [and for me probably false, but I could be wrong].

To me, it seems more likely that the flexibility of human cognition allows a person to think in terms of a programming language than any particular programming language expresses something important about the mechanics of human thought. Another way of putting it is that the claim that object oriented programming is ontologically different from other Turing complete languages seems less believable than ontological equivalence -- the Chicken [1] interpreter is written in JavaScript.

http://torso.me/chicken

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

#194

Post by mannykannot »

sgt101 wrote: post #46

I love work like this - a real attempt to understand what was happening. Genuine scholarship. But it illustrates the issues with this sort of work. This is really about C++ vs C/Pascal and not OO vs Proc. Also this is 1997 C++ which I earned a living from for a brief moment, and I can attest, it was horrible, and very different from 2017 C++. From my perspective today : we need to separate parametric and polymorphic…

> This is really about C++ vs C/Pascal and not OO vs Proc. Also this is 1997 C++...

I can imagine the Smalltalk community rolling its collective eyes and saying "that's not OO..."

My issue with the primary study is that the two programs are not really comparable: a think a C++ parser was a harder problem than a C parser (even given that it is 1997's C++), and this is backed up in the study:

"The C++ parser by further contrast is a recursive descent parser owing to the intractability of parsing C++ using 1 token-lookahead grammars. In other words, they are very different products..."

In mitigation, it says that the C++ parser, as used in the comparison, did not parse the full language, thereby presumably reducing the difference in the complexity of the requirements, but I think the difference in architecture alone is enough to raise doubts over the significance of the results.

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

#195

Post by jwdunne »

ryanbrunner wrote: post #187
jwdunne wrote: post #116

Earlier quoted context omitted.

I haven't looked at Scala closely. I'll take a look - thanks for the tip :) This is something I'm thinking about a lot. I've been wanting to sit down and sketch out what it would look like in terms of syntax / structure. Difficult with 3 kids, wife and a full time job. I think behaviours should be able to specify taxonomy, which in effect is a name for saying "I only accept objects that do this and have that". I envi…

I don't think what you're saying is really much at odds with many OOP languages. Unless I'm missing something, Ruby's mixins and duck-typing (care about what messages an object responds to rather than it's type) comes awfully close to what you're looking for. Granted, something like duck-typing is more of a practice or pattern than something that's terribly well supported by the language (it's up to you to put safegu…

Ruby influenced my opinion.

What I described above wasn't duck typing plus responds_to - maybe it sounds like a whole lot of sugar on that. It was keeping the taxonomy separate, with behavioural sharing through composition only. I was elaborating on how parameters would work - do you allow taxonomies there or keep it separate still?

It's at odds with Ruby because it's still easier to inherit than it is to compose an object. As much as I love the language for its flexibility, it is still based on the idea of coupling the taxonomy with the object itself.

I'm sure an emulation of what I describe is possible to a degree in Ruby.

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

#196

Post by tome »

tzs wrote: post #181
wfunction wrote: post #71

Earlier quoted context omitted.

No, it absolutely is not. OOP has lots of well-known unique characteristics such as inheritance, dynamic dispatch, polymorphism, encapsulation, etc... as well other less-frequently-noticed semantic differences like the fact that the message-passing follows a subroutine model (which may be more difficult to appreciate if that's the only thing you're used to). Yes, you can do OOP in C, but just making a struct and defi…

This thread brings to mind an old quote: What is object oriented programming? My guess is that object oriented programming will be in the 1980s what structured programming was in the 1970s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is. Tim R…

I fear this is the destiny for functional programming in the 2020s.

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

#197

Post by abecedarius »

yen223 wrote: post #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?

http://erights.org/elib/capability/ode/index.html

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

#198

Post by fiddlerwoaroof »

sds2 wrote: post #135
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…

> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

The performance claim doesn't really matter in a world where we use languages like Python, Ruby, PHP and Javascript for major applications. Also, compared to these languages, Common Lisp seems to generally be faster (and, on most implementation/architecture combinations, supports real parallelism).

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

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

#199

Post by cesarb »

imtringued wrote: post #168
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…

Rust doesn't have two string types. They have one string literal type (str&) and a poorly named string buffer (String).

Actually, Rust has four string types: str/String, CStr/CString, OsStr/OsString, and Path/PathBuf.

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

#200

Post by dragonwriter »

jwdunne wrote: 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…

> I think the big problem with OOP is that it's designed to simulate the real world

I actually think that it's more designed to reflect (one particular idea of) the way humans construct mental models of the real world.

> Real world objects are a composition of parts

At the lowest level, sure, but if our aren't modelling quantum physics, the “parts” are abitrary artificial divisions (or aggregations), not part of the fundamental nature of the real world, which are no more fundamental than taxonomy (or identity) of the objects they compose.

> In fact, the only reason why a frog is an amphibian is because it has parts all amphibians share.

In a typical taxonomy, that's true, but it's not in a phylogenetic one, which is based on ancestry, not parts.

> It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog.

OOP allows this (and it's common in dynamic OOP languages, back to Smalltalk), though static class-based OOP (which treats inheritance as type heirarchy) relies on declaration to limit what an object can be used as.

Post reply on HN