Live data from Hacker News

Is the supremacy of object oriented programming coming to a close?

blog.objectmentor.com

21–26 of 26 posts

Re: Is the supremacy of object oriented programming coming to a close?

#21
post #6

I largely agree with the author, but I think the reason for the "failure" of the object oriented model has more to do with the promises it made. Object Oriented Programing was supposed to make programming more understandable to the average human brain. In this respect, it's largely failed. If functional programming is thriving, I feel that it's only because FP has been more honest with its goals, and has done a bette…

While I'll concede that OOP is not the be-all-and-end-all of programming paradigms, I have a hard time thinking of it as a failure.

It seems to me that since the advent of OOP hitting the mainstream, the world has seen more and better software than ever before, written by more people. So in what way is this a failure?

Re: Is the supremacy of object oriented programming coming to a close?

#22
Object oriented programming has been a success, it's just not where people are looking for answers any more. The lifecycle for modestly successful technologies often goes like:

nobody understands it -> everybody scrambles to use it -> people start to get some benefit from it -> people overuse it -> people hate it and say it's dead -> people retreat to where it makes sense.

Objects are as dead as methods or loops. They're not super interesting anymore, they're just fixtures.

I agree that functional programming (while hardly new) will probably start to gain traction, similar to the cycle above. I think FP will also be a successful technology, eventually becoming a fixture in mainstream languages.

Re: Is the supremacy of object oriented programming coming to a close?

#23
post #15

Earlier quoted context omitted.

I agree 100%. Maps and lists are good workhorse objects. You don't need to clutter up your projects with lots of custom objects that do nothing more than transport data. Add to that the over use of inheritance, abstract classes, and interfaces an you get impenetrable clutter. Throw in frameworks and all their XML glue an a simple bug fix become a heroic quest.

If procedural programming is simpler for you, then do it that way! If you have lots of objects that are just glorified structs, then you are factoring badly. I have been in lots of projects. Not all OO is like that. Apparently, yours is. (Oh, and XML glue should be considered a "Framework Smell!")

"(Oh, and XML glue should be considered a "Framework Smell!")"

How about object relational glue? JSON glue? HTML template glue? Google Protocol Buffer glue? (Sure I am missing lots of others.)

I do not know how you go about modern web programming without lots of glue that takes some square data and transforms it into some round data for some other piece of software, be it a browser, a client of your web service, a relational database that has data you cannot live without, etc. etc.

Re: Is the supremacy of object oriented programming coming to a close?

#24
post #16
post #8

"The ceremony of object wrappers doesn’t carry its weight." This nails it. I find so much of my programming now is shoving data into objects, only to almost immediately pull it out again into JSON, XML, HTML templates, or relational databases (in both directions). Most of the code in these "objects" are just getters, setters and member declarations, with very little in the way of actual logic. There is little point i…

If you're just working by yourself, then by all means use whatever you want. If you're working on a multi-developer team, or someone else might have to work on or try to fix your code later, please use structured objects, not Maps. The point of having named and typed member variables is that I actually know what's in there. I know that a User object has a displayName property, so I can use that. I know that the addre…

"If you're using a good IDE, creating the members and even getters and setters shouldn't take you much time at all"

I don't totally disagree with what you say, but having your IDE auto-generate lots of code automatically for you gives me the heebie-jeebies.

The problem is that with a language as verbose as Java, you quickly have a bajillion files filled with far more characters than it should take just to define some property names and their types. Especially considering how having a public field in an object is a Java Mortal Sin.

I could go on, but Yegge has summed up the problems with generating mountains of code with an IDE, that then requires an IDE to move around, here:

http://steve-yegge.blogspot.com/2007_12_01_archive.html

Re: Is the supremacy of object oriented programming coming to a close?

#25
post #12

The answer to this question depends on how you define OOP and FP. I think the answer is "sort of". The problem with OOP is that it encourages the proliferation of mutable state. If each object has mutable state, then a large object-oriented program has distributed mutable state, potentially in hundreds of different silos. Problems like concurrency become impossible to reason about. FP encourages the careful sequestra…

"The problem with OOP is that it encourages the proliferation of mutable state." It should be pointed out that this is a characteristic of the languages and not actually OOP. The original insight, something like "Hey, let's bundle together data structures and their methods into one unit, and communicate with them via messages!" (which got turned into "method calls") actually has nothing to say about mutability. You c…

This is a great point. Given how I tend to get annoyed when people reflexively associate static typing with Java, I shouldn't be so quick to make the leap from OOP to mutable state. Many OOP concents (e.g. inheritance) are mutability-agnostic.

Re: Is the supremacy of object oriented programming coming to a close?

#26
post #16
post #8

"The ceremony of object wrappers doesn’t carry its weight." This nails it. I find so much of my programming now is shoving data into objects, only to almost immediately pull it out again into JSON, XML, HTML templates, or relational databases (in both directions). Most of the code in these "objects" are just getters, setters and member declarations, with very little in the way of actual logic. There is little point i…

If you're just working by yourself, then by all means use whatever you want. If you're working on a multi-developer team, or someone else might have to work on or try to fix your code later, please use structured objects, not Maps. The point of having named and typed member variables is that I actually know what's in there. I know that a User object has a displayName property, so I can use that. I know that the addre…

"If you're working on a multi-developer team, or someone else might have to work on or try to fix your code later, please use structured objects, not Maps."

Or pick a language in which the difference is an implementation detail, where an object defaults to a bag of data, but getters and setters can be transparently substituted when it becomes necessary.

Post reply on HN