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

71–80 of 253 posts

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

#71

Post by wfunction »

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.

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 defining procedures to operate on it doesn't imply any OOP.

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

#72

Post by willtim »

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…

Those are good points, but really not an argument against FP. String could have originally been an abstract data type in Haskell. There are of course disadvantages to the Java string approach, in that there is potentially a lot of code duplication inside the String class. There will also always be some situations that will require you to unpack the string into an array of chars, because a particular method does not exist.

There are plenty of things that Java got wrong. Threads and concurrent programming in Java is particularly difficult to get right without expert knowledge. Haskell makes concurrent programming much easier. I've worked with both professionally and feel that Haskell got more things right.

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

#73

Post by eksemplar »

exDM69 wrote: post #13
eksemplar wrote: post #5

> 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.

But it is not an opinion. There is no universally accepted definition of OO let alone a formal, axiomatic definition, and that makes it ill-defined. If you disagree, point to a definition of OO that you think is "correct".

I'm not disputing the opinion, rather the fact that the author doesn't document why the opinion is there. Maybe the author went through research on the subject and found a consensus, but maybe not.

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

#74

Post by skrebbel »

jcelerier wrote: post #65
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…

indeed, there has been a small essay on this: http://www.lispcast.com/object-oriented-vs-functional-duals

Cool esssay, but it is precisely not what I mean. What I'm talking about is that despite the duality between OOP and FP you can combine the two effectively.

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

#75

Post by jwdunne »

jcelerier wrote: post #70
jwdunne wrote: post #67

Earlier quoted context omitted.

That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts. With de facto OOP, you have no hope in hell because the taxonomy is hard coded to the structure of the object itself. My point is supported by what you say, in fairness. A taxonomy is artificial and separate to the actual object itself. It can and is different based on who defines the taxonomy. My…

> That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts. Except that you want to share properties between those different contexts, and this is where hell begins. For instance (for a more programming-related problem) say that you have a gui application with graphical objects that map to your frogs,say a frog pond simulation. Now months passes and the b…

I love how much this comment makes me think. Thank you!

To be honest, this sounds like a hell hole no matter what you did. It's a complex program that services two domains.

I would say that in the real world, a frog studied in a pond and frog studied at a molecular level share the same properties. A frog is a complex object that has many parts. Naturally for a pond view, you provide the properties needed for that, through composition of smaller objects. If you want to study it on a molecular level, you are really studying the properties, the constituent objects, at a much more granular level (and perhaps more that you didn't need in the simple pond view). It's all still one object.

In fairness, this would be much worse to model in bog standard OOP. Could Joe programmer fair any better there too? Would Joe programmer be working on a macro/molecular simulation in the first place?

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

#76

Post by jwdunne »

icc97 wrote: post #69
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…

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 directly to an object.

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

#77

Post by xorcist »

jcelerier wrote: post #35
willtim wrote: post #29

Earlier quoted context omitted.

In what way is the Linux kernel or my router firmware object-oriented? Linus Torvalds has even gone on record to express his distaste for C++ and OOP.

Object-oriented design patterns in the kernel, part 1: https://lwn.net/Articles/444910/ I'd go as far as to say that every time you have a C API that looks like struct some_struct { ... }; void my_api_foo(some_struct*, param1, param2); int my_api_bar(some_struct*); float my_api_baz(some_struct*, float**, int n); it's OO. And the kernel is full of this (just like many C APIs). Also, Linus's arguments are about C++ usa…

A definition of OO trivial enough to make everything OO isn't very useful. That's why inheritance, encapsulation etc. are often included, to mark the difference against what was before.

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

#78

Post by jcelerier »

wfunction wrote: post #71
mpweiher wrote: post #57

Earlier quoted context omitted.

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

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…

> OOP has lots of well-known unique characteristics such as inheritance, dynamic dispatch, polymorphism, encapsulation, etc...

OO just means that you have a semantic entity, the object, which contains data and to which you associate code. Your main tool to work with is this object; just like in FP your main tool to work with is the function to which you associate data through closures and currying. Likewise, in logic programming your main tool is the constraint. And these aren't relevant to the language. You can do both OO and FP in most mainstream languages.

> dynamic dispatch

is just allowing to associate a different implementation to the same function name. Every languages that have some kind of function pointer allow this.

> polymorphism

is in almost every language, including FP.

    data Tree a = Empty | Node a (Tree a) (Tree a)
is polymorphism. C++ templates are polymorphism. Rust traits are polymorphism.

> message-passing

is only relevant if you adhere to Alan Kay's vision of objects. I personally don't (even if the guy coined the term).

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

#79

Post by nonsince »

jcelerier wrote: post #33
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…

> Rust "feels" OO but isn't. If you write C#7 or Swift and avoid inheritance and prefer immutable types as long as possible - how OO is your code then? Both are 100% object-orientated (and in the case of Rust, also 100% FP is reachable I'd say. Not knowledgeable enough in C# to say). Do they have in-memory data structures with attached functions that do useful work with this object's state (not necessarily mutating i…

Rust is neither OO nor FP, it's procedural (like C and Fortran) but borrows concepts from OO and FP. OO requires data structures to support dynamic dispatch, and although you can have dynamic dispatch in Rust via trait objects your code is heavily gimped - no generics, you can only pass by reference, lifetimes have to be explicitly annotated, etc. It feels like OOP-emulating C code from back in the day. Likewise, if you try to do pure functional programming in Rust you're going to have a bad time. Closures don't share types, and doing dynamic dispatch on them creates the same problems as trying to emulate OOP. In reality it's its own beast, much closer to C with templates than a crossbreed of C++ and Haskell.

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

#80

Post by jcelerier »

xorcist wrote: post #77
jcelerier wrote: post #35

Earlier quoted context omitted.

Object-oriented design patterns in the kernel, part 1: https://lwn.net/Articles/444910/ I'd go as far as to say that every time you have a C API that looks like struct some_struct { ... }; void my_api_foo(some_struct*, param1, param2); int my_api_bar(some_struct*); float my_api_baz(some_struct*, float**, int n); it's OO. And the kernel is full of this (just like many C APIs). Also, Linus's arguments are about C++ usa…

A definition of OO trivial enough to make everything OO isn't very useful. That's why inheritance, encapsulation etc. are often included, to mark the difference against what was before.

But there is an infinite spectrum of languages that mix and match various features of what you call "OO" at diverse degrees, making it meaningless to include all of these in the definition. The most famous ones tended to bundle them all which led to the misappropriation but really, there's no problem with simple concepts. We don't have to find names for everything: it's much clearer to say "language Foobar makes immutable values first-class and allows interface inheritance and delegation" than "language Foobar is FP/OO/whatever seems to be most predominant when looking at the hello world in such language".
Post reply on HN