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

41–50 of 253 posts

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

#41

Post by quickthrower2 »

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.

Works with FadX = Waterfall & FadY = Agile, and vice versa.

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

#42

Post by Tehnix »

MarkMc wrote: post #24
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.

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 another list

- redo replays the undo list onto the history list

A bit more outlined, but nothing OO there, it was in fact entirely functional.

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

#43

Post by pka »

MarkMc wrote: post #24
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.

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…

Apart from this being the prime example for the argument for immutable data (i.e. just keep the whole state of your editor at every undo point somewhere; restore to previous states when undoing) the "OO way" doesn't even need OO features, i.e. see typeclasses or traits.

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

#44

Post by quickthrower2 »

TimMurnaghan wrote: post #37
willtim wrote: post #14

Earlier quoted context omitted.

OOP does not offer true state encapsulation, it just hides it. Objects are always potentially stateful when reasoned about externally. This means that all objects in your system could potentially contribute to the global state space, resulting in a combinatorial explosion of state. This makes programs difficult to reason about and is not a good general approach. In contrast, functional programming makes state explici…

It's cute how people thing that functional will fix everything. In what way does functional make state explicit? If I look at a structure (if you have one in your language) and ask who changes this part of it across a large code base - it's much worse when you've just got a bunch of functions (with bad names) which can be hiding anywhere. And the "reasoned about" shibboleth. What "reasoning" do you actually do. Don't…

In functional programming n Haskell functions are pure so there is no state just an input and an output.

The exception is the IO entry point.

There is a lot of opportunity to sandbox things so that if you know the type of the function you know what it can or can't do to the programs state.

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

#46

Post by sgt101 »

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 oo in our thinking and the big problem is that programmers use these tools to the limit (creating objects with 3+ parameters or deep inheritance hierarchies) and weave silly complexity into the code base .

In a commercial setting the biggest impact I have seen is a project that became impossible to staff because as soon as the developers saw the code base they started looking for other work. It was really good code developed by a two brilliant people initially and then three or four more smart ones as the project grew, but when the lead left it was just too complex - due to prolific use of generics and a obsession with ORM.

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

#47

Post by willtim »

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…

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.

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

#48

Post by dfguo »

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…

This is a way simpler approach vs the OO way described above. The OO way requires undo/redo to precisely cancel each other, which is extremely difficult to get right.

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

#49

Post by jussij »

MarkMc wrote: post #24
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.

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…

I pretty much used this exact same approach to implement undo/redo in a programmer's editor and found it worked well.

My code is pretty exactly as you describe, an undo and redo stack holding action objects and the interfaces to the action objects being nothing more than 'undo()' and 'redo()' methods.

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

#50

Post by mpweiher »

robertkrahn01 wrote: post #7
kccqzy wrote: post #3

C++'s implementation of OO isn't that good to begin with, mainly due to compatibility concerns. Perhaps we should look for a better OO language for comparison, say Smalltalk.

Indeed! And not every language that claims to be OO actually follows the basic ideas [1,2]. So, Smalltalk, as e.g Squeak [3] or Pharo [4] is a good place to start looking and learning but also Erlang [5] and Clojure [6]. State is necessary not "evil" but needs to be managed well. And most OO-languages have, apart from the assignment operation, no abstractions for. [1] http://wiki.c2.com/?AlanKayOnMessaging [2] http:/…

> State is necessary not "evil" but needs to be managed well.

> And most OO-languages have, apart from the assignment operation, no abstractions for

Yep. "Once you're inside an object, it's essentially Pascal" -- David Robson

That's what Polymorphic Identifiers[1][2] in Objective-Smalltalk[3] address. Partial inspiration was the Web and its REST model, which shows that using state as the basis for composition is not just possible, but works really, really well at the largest possible scales.

What it does is replace your bog-standard programming language identifiers with URIs. So you can write things like the following:

     comment                    := https://news.ycombinator.com/item?id=14997098
     file:/tmp/comment          := https://news.ycombinator.com/item?id=14997098
     file:{$HOME}/comment       := https://news.ycombinator.com/item?id=14997098
     file:{$HOME)/comments/{id} := https://news.ycombinator.com/item?id={id}
But that's not the cool thing. The cool thing is that scheme handlers are completely user-defined and composable, so you can abstract over state handling, with scheme combinators that take other scheme handlers as parameters, for example a cache, or filters.

Oh, and references (ref:comment, ref:file:/tmp/comment, ...) generalize the concept of pointer. So creating a symbolic links becomes:

     file:link            := ref:file:path/to/link/target
etc.

[1] http://dl.acm.org/citation.cfm?id=2508169

[2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

[3] http://objective.st/URIs/

Post reply on HN