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

101–110 of 126 posts

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

#101

Post by eveningcoffee »

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…

  In OOP you have to both instantiate a class and then call 
  it's methods. By simple line count it is twice as 
  complicated to call as a function, and it is twice as 
  coupled to the code that calls it.
And in FP a state falls out of the sky?

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

#102

Post by mattmanser »

coldtea wrote: post #95
mattmanser wrote: post #87

Earlier quoted context omitted.

as now different data that need the same treatment can be handled with the same methods. That just doesn't happen enough in real life to design around. In the rare instances when you do need to that, it's trivial to handle with interfaces and a wrapped method that calls a shared function.

> 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 entity framework has mainly done away with all the "tired data transformations". The equivalents like Hibernate, ActiveRecord, etc. have done the same in other languages (and were the trailblazers). When I dip into a data transformation these days it's complex, hand-coded SQL, the tricky bit that takes time, with a simple data class to handle strong typing, trivial to write in a minute or two with snippets and auto-completion.

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

#103

Post by eveningcoffee »

naasking wrote: post #38
delinka wrote: post #2

Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."? OOP is a tool. And generally a useful one. Every new programming paradigm at its inception was going to Save The World and make programming A Better Place. Turns out, every one if these paradigms is a tool with u…

> So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." That's a module. This scope creep is part of the problem with OOP, as it slowly encompasses features that are orthogonal to their main purpose. OOP is mainly about procedural abstraction: any type implementing a protocol (set…

One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world. So in sense of the OOP, object methods are all the functions that can have access to the internal state.

Naturally you can do the same in FP with modules, but honestly, how different it is from OOP then (considering that you can use some form of polymorphism)?

For me OOP and FP stand for abstract concepts, not as specific languages.

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

#104

Post by eveningcoffee »

marktangotango wrote: post #12
gpderetta wrote: post #4

Earlier quoted context omitted.

Exactly. "Everything is an object" was an extremism (today's extremism is the crusade against 'mutable state'), but otherwise OoO has been useful. For example it has seen great success in GUIs.

If you're creating final immutable everything in Java using effective Java chapter 1 immutable objects, sorry but you have the wrong language for the job. Even with Java 8 Optional and Lombok annotations, it opens a can of worms. What is optional and what are sensible defaults for non optional value? These are often non trivial questions in legacy code bases.

And yet Clojure immutable datatypes were written in Java.

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

#105

Post by geophile »

unclebucknasty wrote: post #80
geophile wrote: post #70

Earlier quoted context omitted.

> immutability and OO are diametrically opposed concepts. Why do you say that? It is completely reasonable to define objects whose state is fixed at creation, hide a representation, and have methods that implement some abstraction. E.g., strings, complex numbers, points in a space, and possibly even more complex things like sets. All the advantages of OO apply, even for objects whose interface does not provide a way…

It may be reasonable, but it's not OO. There are those who believe that all objects should be immutable, particularly at the domain level. In my view, that defeats the purpose of OO. There really is no state in this case in any meaningful sense because to get a new state, you must create a new object. So, the object is simply a collection of data. And, even in limited use it's not strictly OO, which is a separate que…

> 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 oppose OO in the strictest sense"? I like the distinction between String and StringBuilder, because I want to be able to share a String without worrying about the possibility of an update through some other reference. (This is not an argument about whether String/StringBuilder is OO or not, just a comment on the design of the classes.) Just because it is possible to define mutable objects, it does not follow that all objects should be mutable. By your logic, Integer should also be mutable?

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

#106

Post by crusso »

School-Cotton wrote: post #60
crusso wrote: post #56

For computers built in the late 80's and subsequent couple of decades, OOP was a fine abstraction that furthered software development in many ways. When you had one thread running your whole program, it was okay to have mutable data all over the place with complex interactions between parts of your program. Developers could keep it all straight in their heads, so OOP added some structure that was very helpful. Now th…

Ehh, even nowadays, lots of programs aren't CPU bound or for whatever other reason can't benefit from using more than one core per process.

But by the time you are CPU-bound, it's too late to change your programming language and your whole development methodology.

There's an easy case to be made that starting with a functional programming, easily parallelizable language from the beginning helps to mitigate the growing pains that happen later when you discover that you need to take better advantage of the hardware.

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

#107

Post by ljw1001 »

delinka wrote: post #2

Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."? OOP is a tool. And generally a useful one. Every new programming paradigm at its inception was going to Save The World and make programming A Better Place. Turns out, every one if these paradigms is a tool with u…

Because straw men make the best targets

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

#108

Post by unclebucknasty »

geophile wrote: post #105
unclebucknasty wrote: post #80

Earlier quoted context omitted.

It may be reasonable, but it's not OO. There are those who believe that all objects should be immutable, particularly at the domain level. In my view, that defeats the purpose of OO. There really is no state in this case in any meaningful sense because to get a new state, you must create a new object. So, the object is simply a collection of data. And, even in limited use it's not strictly OO, which is a separate que…

> 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, but that doesn't make it good OO design vs just being overlaid to achieve some other purpose. On a side note, it also introduces the question of which copy of the object/state is referenced elsewhere and what the possible inconsistency means. That again points to the tension between OO and immutability.

So, never say never, but the more immutability you have, the more difficult it is to pull off a good OO design overall. If you imagine that every object is immutable, then you really won't have an OO design at all.

>Integer should also be mutable?

I see no inherent reason number objects must be immutable. In fact, if you've ever done math with Java's related BigDecimal class, you quickly realize how much cleaner and less error-prone it would be if that class was mutable, especially when performing a series of operations. 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?

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

#109

Post by naasking »

eveningcoffee wrote: post #103
naasking wrote: post #38

Earlier quoted context omitted.

> So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." That's a module. This scope creep is part of the problem with OOP, as it slowly encompasses features that are orthogonal to their main purpose. OOP is mainly about procedural abstraction: any type implementing a protocol (set…

One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world. So in sense of the OOP, object methods are all the functions that can have access to the internal state. Naturally you can do the same in FP with modules, but honestly, how different it is from OOP then (considering that you can use some form of polymorphism)? For me OOP and FP stand for ab…

> One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world.

This is not a defining feature of OOP, because it's a characteristic of abstract data types which predate OO. William Cook managed to distill the essence quite clearly I think [1].

[1] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

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

#110

Post by hasbot »

jimmaswell wrote: post #99
hasbot wrote: post #54

Earlier quoted context omitted.

Your comment reminds me of the class responsibility discussions we used to have. Should we have gasStation->fillUp(vehicle) or vehicle->fillUp(gasStation)? There is no right answer and depends on the situation.

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.
Post reply on HN