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

81–90 of 253 posts

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

#81

Post by wfunction »

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

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

A lot of misunderstanding in what you wrote, but to comment on two parts:

> Every languages that have some kind of function pointer allow this.

It doesn't seem like you're reading the discussion. The claim the parent made was that "every time you do {X}, it is OOP". My reply was "yes, you can do OOP in C, but OOP implies far more than just {X} (it implies {Y}, etc.); merely {X} does not imply OOP".

You reply with "languages that have function pointers allow {Y}". Well yes, they do allow {Y}. Most/all of them in fact probably allow OOP in full. Nobody suggested such languages don't allow OOP (in fact I said the opposite about C). What does that have to do with the entire discussion and argument? Your argument isn't even wrong... it doesn't even compile.

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

This 100% completely misses the point of what I said. Replace it with "procedural call" if you're allergic to "message passing". The point I was making was we're talking about subroutine calls: you call a procedure and wait for it to produce a single value as the resulting output before proceeding. Again: if you're not used to other paradigms then that might be why you're missing my point here and adversely reacting to superficial things like the nomenclature. Whether you dress it as message passing or anything else has nothing to do with the issue.

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

#82

Post by jcelerier »

wfunction wrote: post #81
jcelerier wrote: post #78

Earlier quoted context omitted.

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

A lot of misunderstanding in what you wrote, but to comment on two parts: > Every languages that have some kind of function pointer allow this. It doesn't seem like you're reading the discussion. The claim the parent made was that "every time you do {X}, it is OOP". My reply was "yes, you can do OOP in C, but OOP implies far more than just {X} (it implies {Y}, etc.); merely {X} does not imply OOP". You reply with "la…

> yes, you can do OOP in C, but OOP implies far more than just {X}

maybe it was not clear, the point I am trying to get across is that "OOP implies far more than just {X} " is incorrect; OOP doesn't imply any of inheritance, dynamic dispatch, run-time polymorphism, etc. I took function pointers as an example of why "supporting dynamic dispatch" is irrelevant for categorizing programming languages as OOP / not OOP (and I would even say that doing such a categorization is in itself a worthless idea).

> you call a procedure and wait for it to produce a single value as the resulting output before proceeding

I must admit my ignorance : which languages except prolog don't work like this ?

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

#83

Post by wfunction »

jcelerier wrote: post #82
wfunction wrote: post #81

Earlier quoted context omitted.

A lot of misunderstanding in what you wrote, but to comment on two parts: > Every languages that have some kind of function pointer allow this. It doesn't seem like you're reading the discussion. The claim the parent made was that "every time you do {X}, it is OOP". My reply was "yes, you can do OOP in C, but OOP implies far more than just {X} (it implies {Y}, etc.); merely {X} does not imply OOP". You reply with "la…

> yes, you can do OOP in C, but OOP implies far more than just {X} maybe it was not clear, the point I am trying to get across is that "OOP implies far more than just {X} " is incorrect; OOP doesn't imply any of inheritance, dynamic dispatch, run-time polymorphism, etc. I took function pointers as an example of why "supporting dynamic dispatch" is irrelevant for categorizing programming languages as OOP / not OOP (an…

> I took function pointers as an example of why "supporting dynamic dispatch" is irrelevant for categorizing programming languages as OOP / not OOP.

Again, like everywhere else in your comments, you're conflating and confusing the language with the model/paradigm and keep trying to shove a language into a programming paradigm. Firstly, you can do OOP in assembly and yet it's not an "OOP language". The language is quite independent of the paradigm. Secondly, who was even trying to categorize languages here? You keep thinking the argument is about categorizing languages and then refute a nonexistent discussion...

> I must admit my ignorance : which languages except prolog don't work like this ?

Again: the discussion is not about trying to shove languages into categories; it's about programming paradigms. You can use the same language to code in multiple paradigms.

Look up "actor-oriented programming". It's a different model meant for concurrent processes, i.e. it's not a subroutine model since you don't need to wait for the procedure to finish and produce a result before continuing.

There are lot of "models of computation" out there (probably a better search term than "programming paradigm", btw) and people go so far as to do PhDs on these. I suggest looking around and not assuming everything is some trivial variation of OOP or FP or DP (declarative programming) or whatever you saw in undergrad.

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

#84

Post by ettoretorti »

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…

There's more to the everyday definition object oriented than having functions operating on in-memory data structures. Two other features that are commonly included are subtyping through inheritance and encapsulation.

If we stick to your definition C functions operating on structs qualify as OO, and I don't think many would agree with that.

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

#85

Post by wfunction »

alkonaut wrote: post #30
wfunction wrote: post #27

Earlier quoted context omitted.

> Seriously guys, if you think OO has failed you are obnoxious to the amount of successful OO software that everyone uses every day. Not sure what you mean. Do you mean oblivious ?

Amphibious pitcher debuts in MLB.

What?

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

#86

Post by maxxxxx »

Tehnix wrote: post #42
MarkMc wrote: post #24

Earlier quoted context omitted.

I have the polar opposite view. I love OOP because it provides a way to elegantly solve so many problems. To take a concrete example, consider the undo-redo mechanism in a text editor. It seems natural to create a list of objects with each object representing the action that can be undone or redone, and a pointer to the most recent action object. Undoing executes the 'undo' method and moves the pointer to the previou…

Heh, check out time-travel debugging and be amazed at how simple a much more powerful “undo” can be made when purity is involved (in FP langs, e.g. Elm or Haskell). Seriously though, design wise there was not much you said that was specific to OO. Take for example: - all actions are a data type - the history is a list of actions (in LIFO style for the purpose of simplicity here) - undo pops the list and puts undo in…

Isn't the real difficulty of undo the implementation of the undo method for each action? T The action list seems easy.

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

#87

Post by maxxxxx »

skrebbel wrote: post #21
BoiledCabbage wrote: post #4

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.

Fad X 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 Fad Y has taken prominence in the 90s we'd be in a much better place now.

Exactly!

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

#88

Post by maxxxxx »

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…

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

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

#90

Post by empthought »

willtim wrote: post #68
jcelerier wrote: post #58

Earlier quoted context omitted.

So LISP and Caml aren't functional programming language nowadays ? Because both allow you to modify what's in a closure.

There is no language definition or implementation called "LISP". Both Scheme and OCaml lexically capture variables by value, as if they have been passed in as arguments. This is not how it works in e.g. Python.

Python has had closures exactly the same as Scheme and OCaml since the year 2000.

What it lacks is a multiline anonymous function syntax.

See PEP 227: https://www.python.org/dev/peps/pep-0227/

Post reply on HN