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

Was object-oriented programming a failure? (2015)

quora.com

Post reply on HN
Print view View original

111–120 of 126 posts

Re: Was object-oriented programming a failure? (2015)

#111

Post by technion »

jpalomaki wrote: post #79

I think one major problem with OO was that many people did not really get object oriented thinking (and I was probably among them). It is very easy to do objects that are just dummy data container instead of smart things that interact with each other. Just think how many Java tutorials started with the procedural "Hello World" example and then proceeded to introduce objects and taught the idea of encapsulation by rem…

One of my complaints on the subject is that academia is so fascinated with OOP. I took multiple courses on the subject, and the issue I'm hitting is that your "proper" example would probably have failed me a course, because the "bad" example you've given is exactly what we were taught.

Re: Was object-oriented programming a failure? (2015)

#112

Post by jimmaswell »

hasbot wrote: post #110
jimmaswell wrote: post #99

Earlier quoted context omitted.

What seems most natural to me is that the gas station would have a fillUp(IFillableWithGas) method that takes an object with the IFillableWithGas interface, which has a method that returns the amount it was able to take and a method to put that much in. The gas station is the one "doing" the action "to" things that are able to take gas, and it's the gas station's responsibility to know how to pump up the gas from the…

LOL. Who said anything about an underground gas tank, pricing, or a display? If you're adding pricing, you have to add a payment system. It'd be out of place for a Vehicle to know anything about paying a bill. Objects just model reality; they don't have to mirror reality.

It's just a demonstration of how the hierarchy works in the abstract. And it's just displaying the price on the meter, not saying the "car" has to deal with that. The driver would, or the player, if you look at this like game code, which would make sense.

Re: Was object-oriented programming a failure? (2015)

#113

Post by jpalomaki »

technion wrote: post #111
jpalomaki wrote: post #79

I think one major problem with OO was that many people did not really get object oriented thinking (and I was probably among them). It is very easy to do objects that are just dummy data container instead of smart things that interact with each other. Just think how many Java tutorials started with the procedural "Hello World" example and then proceeded to introduce objects and taught the idea of encapsulation by rem…

One of my complaints on the subject is that academia is so fascinated with OOP. I took multiple courses on the subject, and the issue I'm hitting is that your "proper" example would probably have failed me a course, because the "bad" example you've given is exactly what we were taught.

Two books that affected my thinking on the subject were Domain Driven Design[1] by Eric Evans and Object Thinking[2] by David West. Many years since I read the books and I don't claim to have studied them in detail so I'm not saying if they were good or bad, but at least I got some ideas out of them.

[1] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

[2] https://www.microsoftpressstore.com/store/object-thinking-97...

Re: Was object-oriented programming a failure? (2015)

#114

Post by mmjaa »

ziotom78 wrote: post #94
_0w8t wrote: post #16

Earlier quoted context omitted.

I can definitely state that OOP allows to implement GUI. But "great success" I can see only for vendors selling OOP tools for GUI development. Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it…

Well, I used to bash C++ and OOP programming till not a long time ago, but I am slowly reconsidering my ideas. I am now learning Rust, and for this purpose I am trying to implement a small TUI (Text User Interface) framework. In order to get some ideas, I dug in my library and found the Turbo Vision User's Manual that was bundled with Borland Pascal 7.0 [1]. Reading it after so many years made me wonder how could the…

Ex-Turbo Vision user here .. I continue to be disappointed by modern GUI technologies, by comparison. Every time I pick up some React tutorial, it makes me sad as hell that we've come so far, and yet have to deal with such errant crap as React and the Web itself as a whole.

Its gotten so bad that I feel strongly about killing the browser-based ideology and just returning to native clients for everything .. I mean, its really not an easy decision to "do the whole GUI in Web", even though by now it should be. It just seems like such a mess by comparison with where we should be by now, given the work done decades ago ..

Re: Was object-oriented programming a failure? (2015)

#115

Post by coldtea »

mattmanser wrote: post #102
coldtea wrote: post #95

Earlier quoted context omitted.

> That just doesn't happen enough in real life to design around. On the contrary, I think it does. Especially for web, enterprise and application programming, 90% of the logic is the same tired data transformations.

It'd be nice if you told us what code you're referring to. I've been giving examples and rough technical outlines how I'd handle problems that needed code sharing. So far you've given us zilch but naysaying. Have you got any examples? I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class? Like in C#, the…

>It'd be nice if you told us what code you're referring to. I've been giving examples and rough technical outlines how I'd handle problems that needed code sharing. So far you've given us zilch but naysaying.

Sorry, why the complaining? We were talking on a more abstract level. Yourself just gave some anecdote about "Someone did this on a project I work on (C#). Utter nightmare. Loads of repeated code as new programmers didn't know methods existed, loads of extraneous DTO objects, lots of nested single line methods, massive code bloat", that's hardly an example either.

>I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class?

Apart from the data contained without, which process would not be the same? Most high level operations would be exactly the same: filtering would be the same (it just needs to accept a predicate), ordering would be the same, serialization would be the same, etc etc.

For a very simple example, you don't need:

  persons.sort("age", sort.DESC)
  orders.sort("created_at", sort.DESC)
etc, you just need:

  sortedPersons = sort(persons, cur -> cur.age, sort.DESC)
  sortedOrders = sort(orders, cur -> cur.created_at, sort.DESC)
And the same function can work with 100s of other classes and containers.

Re: Was object-oriented programming a failure? (2015)

#116

Post by geophile »

unclebucknasty wrote: post #108
geophile wrote: post #105

Earlier quoted context omitted.

> It may be reasonable, but it's not OO. Says who? I.e., do you have any references? It is easy to give examples arguing either side. I agree that your bus example is best modeled as a mutable object. The same bus can have different passengers over time. But a complex number is an example that I think is better thought of as immutable. You really lost me with your discussion of Strings. Why does "immutability tend to…

> do you have any references? My statement rested on the original intent of the OO paradigm, which I described in the subsequent paragraph, including the bus example. And, the reason you agree that the bus is best modeled as mutable is because it represents this original intent! You can (and did) make an argument for why you like immutability. There are valid reasons to want to be assured that the data doesn't change…

Because numbers are, by their nature, immutable. I think an object should reflect the externally visible properties of the thing being modeled. To me, that is the whole point of OO. If I have two variables pointing to the same mutable Number, then some very non-intuitive things can happen when the value of the Number is changed through one variable.

> That thing has internal state, so why am I forced to continuously assign the results of each operation to a completely new object vs simply having those operations update state?

The abstract idea of an integer is immutable. Changing 3 to 4 is nonsensical. (It is not analogous to modeling a bus by a Bus object with operations reflecting the coming and going of passengers.) That's why the Java object named Integer should be immutable, and similarly for all the other Number classes, including BigDecimal.

Now if there were an IntegerBuffer class, then sure, there should be methods to change state.

Your argument is that there is internal state, state can be mutable, therefore every object should be mutable. My argument is that the nature of some objects is immutable, and designing a class to reflect that nature is preferable, and not at all at odds with OO.

Re: Was object-oriented programming a failure? (2015)

#117

Post by shadowmint »

Buttons840 wrote: post #83
shadowmint wrote: post #59

Earlier quoted context omitted.

The irony is that it probably does mean better quality code for most people. Quality in practical outcomes for building projects, that is, not code asthetics. The problem is that 'functional code' means 'spagetti code' for many 'low skill' people, and 'write once maintain never' perl style code for many other 'smart' people. Both are rubbish, terrible low quality useless code outcomes. OOP doesn't fix everything, but…

> The problem is that 'functional code' means 'spagetti code' for many 'low skill' people I don't see how that is the case. Even in the most poorly written function you have code that's working mostly on it's arguments (and maybe some global or something, since it is poorly written) and then returns a value. How is this function connected to the surrounding code? We know the answer, it's called in a single expression…

It's not about hidden state; that's just bad OOP. You shouldn't be looking at the internals, that's the point. It's about modular encapsulation and reusable components.

> a single isolated function and the functions tend to be on the short side

I can almost guarantee that code was not written by an inexperienced or low skill coder.

If it was, you'd have a large complex function that took large complex state as its input, and probably maintained some kind of hidden internal state in some kind of async deferred loop after it returned or some combination of the above.

Have you worked with inexperienced FP programmers?

It's not fun.

Inexperienced OOP is a lot easier to deal with, because the entity level API validation is all you care about; you don't care about how hideously the internals were implemented as long as the tests pass. There can be any number of bugs and spaghetti inside the object, but you don't care, because you don't see it (until it manifests as bugs; but then you just add more tests and make them go away until all the tests pass).

I think there's a pragmatic aspect to OOP that involves large scale organizations collaborating on projects that you're not taking into account.

You could argue that a test suite for FP does the same job, and maybe it does... but the point here is that someone has to define the module level interface, and how it behaves as a state machine (regardless of if the state comes in 'pure' and is passed around or is encapsulated internally); and that's OOP, not an inheritance hierarchy.

Re: Was object-oriented programming a failure? (2015)

#118

Post by mattmanser »

coldtea wrote: post #115
mattmanser wrote: post #102

Earlier quoted context omitted.

It'd be nice if you told us what code you're referring to. I've been giving examples and rough technical outlines how I'd handle problems that needed code sharing. So far you've given us zilch but naysaying. Have you got any examples? I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class? Like in C#, the…

> It'd be nice if you told us what code you're referring to. I've been giving examples and rough technical outlines how I'd handle problems that needed code sharing. So far you've given us zilch but naysaying. Sorry, why the complaining? We were talking on a more abstract level. Yourself just gave some anecdote about "Someone did this on a project I work on (C#). Utter nightmare. Loads of repeated code as new program…

A better solution than that has been in heavy use for a decade in C#. Works on anything that implements `IEnumerable`.

    db.Orders.Sort(o => o.StartDate)
I've also never found ordering code to be the bulk of my logic, but whatever.

Anyway, generics. Without having to muck around with funky designs for your classes.

Re: Was object-oriented programming a failure? (2015)

#119

Post by unclebucknasty »

geophile wrote: post #116
unclebucknasty wrote: post #108

Earlier quoted context omitted.

> do you have any references? My statement rested on the original intent of the OO paradigm, which I described in the subsequent paragraph, including the bus example. And, the reason you agree that the bus is best modeled as mutable is because it represents this original intent! You can (and did) make an argument for why you like immutability. There are valid reasons to want to be assured that the data doesn't change…

Because numbers are, by their nature, immutable. I think an object should reflect the externally visible properties of the thing being modeled. To me, that is the whole point of OO. If I have two variables pointing to the same mutable Number, then some very non-intuitive things can happen when the value of the Number is changed through one variable. > That thing has internal state, so why am I forced to continuously…

Well, we basically agree. I grant that there's a better case for numbers being immutable than buses. However, I would say that number "objects" are not meant to model real world numbers as objects per se. Because, sure, you don't morph a 3 into a 4 in the real world, but in code you don't generally require numbers as objects for the purpose of representing such constants. Rather, they are variables with some meaning.

In other words, you don't generally need:

BigDecimal three = new BigDecimal(3);

but

BigDecimal sum = new BigDecimal(0);

Followed by some operation(s).

Sure, depending on naming, you can create confusion with mutable numbers, but that's true for immutable objects as well.

At the end of the day, I am not saying that immutables have no use and one immutable class outright destroys your OO design. I am saying that there is a tension that exists between the two that can easily be seen if you envision a design with 100% immutable classes in the context of OO's raison d'etre.

Bringing it back to the OP, my bigger point was that all of the work involved and "side effects" of layering on immutability are an example of how people assess OO's success through the lens of things that were later added, but were not an intrinsic part of the OO paradigm in the first place.

Re: Was object-oriented programming a failure? (2015)

#120

Post by hasbot »

jimmaswell wrote: post #112
hasbot wrote: post #110

Earlier quoted context omitted.

LOL. Who said anything about an underground gas tank, pricing, or a display? If you're adding pricing, you have to add a payment system. It'd be out of place for a Vehicle to know anything about paying a bill. Objects just model reality; they don't have to mirror reality.

It's just a demonstration of how the hierarchy works in the abstract. And it's just displaying the price on the meter, not saying the "car" has to deal with that. The driver would, or the player, if you look at this like game code, which would make sense.

Dude, it was just an example for a style discussion. You're missing the point of the discussion and way over-engineering the example.
Post reply on HN