7 ms·

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

33 points by codeodor 17y ago

j_baker 17y ago
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).
neilo 17y ago
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.
- MoeDrippins 17y ago
  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.
banned_man 17y ago
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.
- eru 17y ago
  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.
- jerf 17y ago
  "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.
  - banned_man 17y ago
    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.
jballanc 17y ago
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.
- benreesman 17y ago
  So Scala?
- allertonm 17y ago
  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?
jimbokun 17y ago
"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.
- jballanc 17y ago
  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.
- russell 17y ago
  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.
  - stcredzero 17y ago
    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!")
    - jimbokun 17y ago
      "(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.
octane 17y ago
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.
- chancho 17y ago
  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.
- stcredzero 17y ago
  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.
phugoid 17y ago
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.
extension 17y ago
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.
- stcredzero 17y ago
  "X Uber Alles" Meta-Notion Considered Harmful! (Also "X Considered Harmful" Considered Harmful!)
geebee 17y ago
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.

33 points by codeodor 17y ago

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

neilo 17y ago

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.

MoeDrippins 17y ago
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.

banned_man 17y ago

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.

eru 17y ago
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.
jerf 17y ago
"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.
- banned_man 17y ago
  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.

jballanc 17y ago

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.

benreesman 17y ago
So Scala?
allertonm 17y ago
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?

jimbokun 17y ago

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

jballanc 17y ago
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.
russell 17y ago
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.
- stcredzero 17y ago
  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!")
  - jimbokun 17y ago
    "(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.

octane 17y ago

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.

chancho 17y ago
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.
stcredzero 17y ago
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.

phugoid 17y ago

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.

extension 17y ago

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.

stcredzero 17y ago
"X Uber Alles" Meta-Notion Considered Harmful! (Also "X Considered Harmful" Considered Harmful!)

geebee 17y ago

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.