Is the supremacy of object oriented programming coming to a close? | Hacker News Reader

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

blog.objectmentor.com

33 pointscodeodor25 comments

"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 in having objects at all for this kind of programming, as opposed to a map, struct, or type class of some sort.

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 address property is actually a List of Address objects, not a string, and not a Map. And I can know this instantly using my IDE's auto-complete and tool-tips. It's also exposed via Javadoc, which means if your front-end team is writing the JSPs, they can just look at the Javadoc to know what they have access to, without bugging me every 10 seconds.

Not only do I know, but the compiler knows, and can let me know if I'm trying to access something that doesn't exist, or I typo'ed the name, or if I'm trying to treat a String like a Date.

If you're using a good IDE, creating the members and even getters and setters shouldn't take you much time at all, and will be well worth it in maintainability, compile-time checking, debugging, extensibility, etc...

"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

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

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.

It sounds to me like this is a case of "right tool for the job". Regardless of what the "future" of programming languages is, I don't think we'll ever be free from making those sorts of decisions.

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 better job achieving them. FP is supposed to be mathematical in nature. It's uncomfortable to learn, but once you do, FP languages, for the most part, live up to their billing.

What is really needed is a new paradigm that is what OOP was supposed to be: programming that matches the patterns of human thought. In this respect, I think the author's suggestion of OOP-style modularization with FP-style pattern matching and function mapping is the future of programming.

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?

So Scala?

I don't think OOP is at an end. In fact, I think newer functional languages are giving it new life (and giving us alternative ways to use OOP). Consider clojure. It's fully object-oriented, but not in the traditional way (although you can still use Java objects).

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.

You mean that real programmers have coded an Account class with a Withdraw method and a Balance property, like in OO for Dummies? Sure glad I'm not a real programmer then.

I wrote my first object oriented program a few years ago, and it seemed obvious that database fields would keep getting added, deleted and changed. My goal was to isolate this stuff from the rest of my program, not try to hardcode it everywhere.

I got a bit lost in all the buzzwords, but if that what his point, I agree.

Objects as a language feature aren't going anywhere, nor should they. Like functions, they are simple, fundamental, versatile and work well with nearly every other language feature.

Object Oriented Programming, as an all-encompassing paradigm that will solve all your problems if you faithfully and blindly devote yourself to applying it, and only it, anywhere and everywhere that you possibly can, is dying.

Hopefully, the notion that such a paradigm can ever exist will die with it.

"X Uber Alles" Meta-Notion Considered Harmful!

(Also "X Considered Harmful" Considered Harmful!)

FP plus lighter and more dynamic objects doesn't sound like the end of OOP supremacy, but rather another stage of it. I'm curious to see where it leads / what comes out of it.

Also curious. Horizontal scaling, distribution, concurrency; that's where I see the tech heading. I think whatever will make those easier to deal with will have a huge advantage going forward.

The worst thing in the world is working with code written by an inexperienced programmer who thinks he has to use OO everywhere for everything.

Same goes for table normalization.

One of the greatest things about experience is that you know when you should use the "proper" way of doing things and when you should make things work faster/better/more directly.

Funny that. If you use OO for everything in Smalltalk, often it's pretty. If you use OO for everything in, say, Perl 5, it feels quite cumbersome to me. (Ever meet one of those guys who uses one instance of polymorphism in their whole project and talks as if they've mastered OO?)

Look inside the Smalltalk image sometime. There is a clear attempt at OO everywhere for everything and it feels natural and unforced. (Well, it's about 70%, to be completely accurate, because there's also some functional and some OO newbie code in there.)

"proper" is all about cost/benefit tradeoffs, and it's very context-dependent. Expressing things polymorphically in an environment like Smalltalk, Python, or Ruby has low coding overhead.

Sometimes, it is just better to crank out an old-fashioned procedural routine and be done with it.

One of the key tradeoffs: Am I trapped, or will I be able to change my mind? So long as you can keep yourself from getting trapped, you're mostly safe.

Interesting that "proper" is different from "faster/better/more directly"

I know what you mean, its just kind of sad that this is the case.

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 sequestration of mutable state. It's false to say that FP outlaws it entirely, since it's hard to do anything useful without side effects. However, functional style limits and sequesters mutable state to such a degree that it's usually easy to reason about what side effects are happening.

"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 can and people have build object systems based on immutable objects.

The implications of doing that are deep and profound and color the rest of the system and are beyond the scope of this posting, but it can be done.

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.

Yes. And FP may even go so far, and uphold this segregation at the language level. I.e. Haskell's type system and IO Monad.

Reply on news.ycombinator.com