6 ms·

Are we still doing OOP?

23 points by graham_king_3 16y ago

fleitz 16y ago
The reason OO exists to the degree it does in my mind is that it makes it easier for Enterprise Architects to write code in Visio, this also lends itself to directly modeling the domain so managers don't have to think. Which leads to public class Money { public string Currency { get; set; } public float Price { get; set; } } "The money class is the root of all evil"
- derefr 16y ago
  OO models exist because they reflect how we describe things when not talking to computers. "This is Spot. Spot Is-A Dog. See Spot.run(). Spot.runs == :fast." They're a crutch for people who can't (or don't have the training to) think in terms of sets, mappings, graphs, combinators, etc.
  - blub 16y ago
    ...or maybe FP is a crutch for mathematicians and purists. You're making a huge mistake: we shouldn't adapt our thinking to computers, we should adapt computers to our thinking and make them easier to operate. According to your logic, writing hexadecimal code is the holy grail of computer programming.
    - loup-vaillant 16y ago
      And you are making an equally huge mistake: that thinking in terms of sets, mappings, graphs, combinators, etc doesn't help. It does. And if a programmer is incapable of understanding those concepts, he should learn them. The fact is, we shouldn't adapt computers to our thinking, nor our thinking to computers. We should adapt both to our problems.
      - blub 16y ago
        Sure it helps, but that's not what derefr said. He said that any other type of thinking is a "crutch" and that the ideal of thinking is "thinking in terms of sets, mappings, graphs, combinators, etc". By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument.
        loup-vaillant 16y ago
        OK, I misread you. That said, I tested both OO an FP, and my current opinion is that thinking more mathematically (in terms of sets, mappings…), almost always yields smaller designs, which are almost always more flexible and more efficient. > By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument. I don't understand you here. Derefr didn't make any mathematical statement. He didn't described the concepts, he named them. The four items he mentioned are related. And why should they, anyway? The way I see it, Derefr just made a statement, not an argument.
    - derefr 16y ago
      Computers are theoretical constructs as well as practical objects. In order to work with the practical object "computer," you should first understand everything possible about the theory of the theoretical construct "computer." Then, when you understand it, you can code however you like. To put it another way: > Before I understood the Art, a punch was just a punch, a kick was just a kick. Then, while learning the Art, a punch became more than a punch, a kick more than a kick. Now that I understand the Art, a punch is a punch, and a kick is a kick. Notice the removal of the "just"—now the underlying knowledge (the "more") is attached to the concept (it is not a pure concept, existing "just" for itself), but it is also understood that that the "more", learned while studying the Art, is perfectly described by the words "punch" and "kick"—that those high-level concepts are just abstractions for the low-level concepts learned while studying the Art. It's a crutch to rely on concepts without understanding their foundations. (This is what I meant with my original conclusion, vague as it might have been.) However, having learned those foundations, you can decide for yourself, on a case-by-case basis, whether to think in terms of the high- or low-level concept, and indeed the high-level is sometimes the perfect tool for the job. But it's not the perfect tool for everything—and only studying the Art of Computer Science will show you why.
  - IgorPartola 16y ago
    Sometimes an object is exactly the right tool. Also it makes the syntax nice and clear: xyz->foo() is sometimes much clearer than foo(xyz). But yes, wrapping any bit of data into a object is silly. Some things are just not objects. Others make for very awkward objects. My personal favorite is a result of an SQL query that JOINs multiple tables. Do you make each type of joon its own type or do you just dynamically extend the existing type a la JavaScript? I tend to do the latter but that does not work well in a lot of languages and goes against their intent at best. Lastly, OOP need != class based inheritance. Thus JavaScript is a very viable OOP environment any is very widely used, so no OOP is by no means dead.
blub 16y ago
Terrible blog post: present a series of special cases where OOP is not the best fit => throw OOP away except for class libraries? Thanks to Paul Graham's language abuse, dead is becoming a meme: "X is dead" = "I don't use X".
- mdg 16y ago
  Proper name
barrkel 16y ago
Ironically, I don't think OOP was really meant to be used for business objects. I think inheritance doesn't work very well with objects whose backing store needs to fit into a relational database someplace. OO really shines with UI programming, where incrementally building up behaviour through inheritance makes a lot of sense.
- arethuza 16y ago
  If the classes in your system vary a lot in behavior but not in their internal state then mapping to a database can be straightforward. With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows.
  - epochwolf 16y ago
    > With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows. This is the problem document databases are designed to solve. :)
    - arethuza 16y ago
      Maybe someone should create an ERP system based on one then!
ErrantX 16y ago
As with all programming methodologies; OOP is a useful tool for situations where it works. Outside of that other things become useful... this is how the world has always worked :)
- loup-vaillant 16y ago
  Of course. The real question is, where does it work? (And why?) Personally, I don't know.
xtho 16y ago
Probably the most disturbing thing about the article is the original title: "Programming like it's 1995". I'd feel better if he had said "OOP is like so 1980's".
- loup-vaillant 16y ago
  The problem is, OOP as Alan Kay envisioned it isn't widely refered to any more. Now, we all talk about OOP as if Java started it.
xtho 16y ago
Probably the most disturbing thing about the article is the original title: "Programming like it's 1995". I'd feel better if he had said "OOP is like so 1980's".
DanielBMarkham 16y ago
With all respect to this author and this piece -- it was well done and he makes many salient points. There are some topics on HN that are just starting to bore the hell out of me. Apple fanboy-ism, or not. C++: it's complicated so it's bad. Famous person X says this about famous person/product Y. And bitching about OOP. Look. OOP is just the use of categorization and set theory to organize code and data. It doesn't have to involve a lot wiring things together, it doesn't have to mean tremendously huge class diagrams before coding, and it is absolutely not related to one particular language. I can use OOP techniques in any language, and to the degree they're necessary, I should. It's just a tool. I understand that the OOP movement got way overblown and annoying, but we as technologist are always making overly-broad generalizations of anything we do. There's a tremendous amount of selection bias that goes on in technology, most of it hidden. I remember in one of my early contracting jobs we had a PM who was a FoxPro programmer. No matter what the problem we were talking about, somehow he would feel that FoxPro was the best answer for that problem. At the time I thought he was unique -- sort of a joke. Looking back over many years of observing technologists, however? He was the rule, not the exception. At the risk of stating the obvious we only understand those things we have familiarity with. This means if you haven't programmed in OOP, or if you've had extensive experience with OOP and you know somebody at the same experience level with different opinions, you should try very hard to have an open mind and learn something from somebody else. It's very easy to make broad claims that are unsupported by anything but a small set of observations. Saying "Are we still doing OOP?" is like saying "Are we still using categorization and set theory" which sounds to me a LOT like "Are we still using arithmetic?" The question is nonsensical.
- plinkplonk 16y ago
  "Saying "Are we still doing OOP?" is like saying "Are we still using categorization and set theory" which sounds to me a LOT like "Are we still using arithmetic?"" OO is hardly equivalent, and not as fundamental (or anywhere near fundamental) as Set Theory, leave alone Arithmetic. The implied equivalence is misleading. You can use "categorization" and Set theory to design programs with never an Object in sight. Types and (mathematical) functions are both defined using Set Theory as are Relations (as in relational databases). You could program in Haskell with only types and functions and monads and such with no "object oriented design". The primary difficulty for people who've only done (what some call) "OOP" is forgetting all the OO technique they learned. At best you could say that objects (for various definitions of "OO") could also be expressed with Sets and (mathematical) functions and such. ALmost every programming language feature could be so expressed, that isn't saying much. There is no specifically "Object Oriented" super technique that transcends all languages (both OO and non OO) and is applicable in all of them. You'd be cutting against the grain of many languages if you tried to think in OO while using them. LIke Fortan, you can write "OO" in any language and it isn't always a good thing to do. Not defending the author of TFA ( I don't read these "Ohh technique X or language Y is so outdated" type of articles any more) but the sentence quoted (' "Are we using OO" is lik e "Are we using Set Theory" ') is as generic and misleading as anything the author claimed. Balance in all things.
deleted 16y ago
[deleted]
elblanco 16y ago
Yes, next question?
duncanj 16y ago
1. How bizarre to consider Javascript not object-oriented programming. The entire page is represented in objects. 2. I think the worst thing that happened in OOP was the development of ER-like methods (Rumbaugh, Booch) to "model" the system before it got built. It doesn't clarify anything and it doesn't fit with the original idea from Smalltalk, where software is developed in a gradual and exploratory style. When he states you don't need to develop a "complex object class hierarchy" for a small task, I think he is falling into this trap. 3. Obviously, other approaches are good for a number of problems, and OOP is not the be-all and end-all. I would never avoid using it, though, because it is good for many problems, especially UI. OOP is worst in static languages (EC++), and best in dynamic languages (Smalltalk, Ruby, JS), in my opinion. 4. Spreadsheets. I wish the VBA interface to Excel were more OO, because I think the methods are on the wrong interfaces. There is definitely room for improvement. OTOH, the user interface is a facade around something that may or may not be implemented in OO. I also wish that I could refer to things in the user interface using OO methods, kind of like using Prototype in JS. 5. In financial applications, I wonder what technique allows him to "innovate" without his model "breaking down". He doesn't say, but it sure seems like he doesn't like objects! (for whatever reason, he also doesn't really say.) 6. Finally, I get the feeling that he's really saying he no longer writes a real object model for his applications. This is, apparently, because the object libraries he is working with have gotten so good at modeling everything he needs that he is mostly writing glue, and it is all fitting into a few modules of mostly procedural code. So, in other words, OO is a huge success.
hxa7241 16y ago
It is not so much OO that is receding as inheritance. Although that is not recent -- it must have been around 1995-2000 that doubts were becoming popularly known. Inheritance is somewhat interesting though: it is a formalised mechanism or pattern for changing software function -- there doesn't seem much else like that. Why did it not work very well? As to OO, Bertrand Meyer gives the best rationale: it is about organising software around data instead of procedure, because data is more stable. That yields a rather abstract definition, but in that sense OO is perhaps more alive now than ever. What has happened is that the developer's canvas has expanded enormously. We think and write for the WWW first now. The data types are the various sub-parts and relations of web standards. Our software is very much organised around these, they just don't map to small language features.

23 points by graham_king_3 16y ago

The reason OO exists to the degree it does in my mind is that it makes it easier for Enterprise Architects to write code in Visio, this also lends itself to directly modeling the domain so managers don't have to think. Which leads to public class Money { public string Currency { get; set; } public float Price { get; set; } } "The money class is the root of all evil"

derefr 16y ago
OO models exist because they reflect how we describe things when not talking to computers. "This is Spot. Spot Is-A Dog. See Spot.run(). Spot.runs == :fast." They're a crutch for people who can't (or don't have the training to) think in terms of sets, mappings, graphs, combinators, etc.
- blub 16y ago
  ...or maybe FP is a crutch for mathematicians and purists. You're making a huge mistake: we shouldn't adapt our thinking to computers, we should adapt computers to our thinking and make them easier to operate. According to your logic, writing hexadecimal code is the holy grail of computer programming.
  - loup-vaillant 16y ago
    And you are making an equally huge mistake: that thinking in terms of sets, mappings, graphs, combinators, etc doesn't help. It does. And if a programmer is incapable of understanding those concepts, he should learn them. The fact is, we shouldn't adapt computers to our thinking, nor our thinking to computers. We should adapt both to our problems.
    - blub 16y ago
      Sure it helps, but that's not what derefr said. He said that any other type of thinking is a "crutch" and that the ideal of thinking is "thinking in terms of sets, mappings, graphs, combinators, etc". By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument.
      - loup-vaillant 16y ago
        OK, I misread you. That said, I tested both OO an FP, and my current opinion is that thinking more mathematically (in terms of sets, mappings…), almost always yields smaller designs, which are almost always more flexible and more efficient. > By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument. I don't understand you here. Derefr didn't make any mathematical statement. He didn't described the concepts, he named them. The four items he mentioned are related. And why should they, anyway? The way I see it, Derefr just made a statement, not an argument.
  - derefr 16y ago
    Computers are theoretical constructs as well as practical objects. In order to work with the practical object "computer," you should first understand everything possible about the theory of the theoretical construct "computer." Then, when you understand it, you can code however you like. To put it another way: > Before I understood the Art, a punch was just a punch, a kick was just a kick. Then, while learning the Art, a punch became more than a punch, a kick more than a kick. Now that I understand the Art, a punch is a punch, and a kick is a kick. Notice the removal of the "just"—now the underlying knowledge (the "more") is attached to the concept (it is not a pure concept, existing "just" for itself), but it is also understood that that the "more", learned while studying the Art, is perfectly described by the words "punch" and "kick"—that those high-level concepts are just abstractions for the low-level concepts learned while studying the Art. It's a crutch to rely on concepts without understanding their foundations. (This is what I meant with my original conclusion, vague as it might have been.) However, having learned those foundations, you can decide for yourself, on a case-by-case basis, whether to think in terms of the high- or low-level concept, and indeed the high-level is sometimes the perfect tool for the job. But it's not the perfect tool for everything—and only studying the Art of Computer Science will show you why.
- IgorPartola 16y ago
  Sometimes an object is exactly the right tool. Also it makes the syntax nice and clear: xyz->foo() is sometimes much clearer than foo(xyz). But yes, wrapping any bit of data into a object is silly. Some things are just not objects. Others make for very awkward objects. My personal favorite is a result of an SQL query that JOINs multiple tables. Do you make each type of joon its own type or do you just dynamically extend the existing type a la JavaScript? I tend to do the latter but that does not work well in a lot of languages and goes against their intent at best. Lastly, OOP need != class based inheritance. Thus JavaScript is a very viable OOP environment any is very widely used, so no OOP is by no means dead.

blub 16y ago

Terrible blog post: present a series of special cases where OOP is not the best fit => throw OOP away except for class libraries? Thanks to Paul Graham's language abuse, dead is becoming a meme: "X is dead" = "I don't use X".

mdg 16y ago
Proper name

barrkel 16y ago

Ironically, I don't think OOP was really meant to be used for business objects. I think inheritance doesn't work very well with objects whose backing store needs to fit into a relational database someplace. OO really shines with UI programming, where incrementally building up behaviour through inheritance makes a lot of sense.

arethuza 16y ago
If the classes in your system vary a lot in behavior but not in their internal state then mapping to a database can be straightforward. With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows.
- epochwolf 16y ago
  > With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows. This is the problem document databases are designed to solve. :)
  - arethuza 16y ago
    Maybe someone should create an ERP system based on one then!

ErrantX 16y ago

As with all programming methodologies; OOP is a useful tool for situations where it works. Outside of that other things become useful... this is how the world has always worked :)

loup-vaillant 16y ago
Of course. The real question is, where does it work? (And why?) Personally, I don't know.

xtho 16y ago

Probably the most disturbing thing about the article is the original title: "Programming like it's 1995". I'd feel better if he had said "OOP is like so 1980's".

loup-vaillant 16y ago
The problem is, OOP as Alan Kay envisioned it isn't widely refered to any more. Now, we all talk about OOP as if Java started it.

xtho 16y ago

Probably the most disturbing thing about the article is the original title: "Programming like it's 1995". I'd feel better if he had said "OOP is like so 1980's".

DanielBMarkham 16y ago

With all respect to this author and this piece -- it was well done and he makes many salient points. There are some topics on HN that are just starting to bore the hell out of me. Apple fanboy-ism, or not. C++: it's complicated so it's bad. Famous person X says this about famous person/product Y. And bitching about OOP. Look. OOP is just the use of categorization and set theory to organize code and data. It doesn't have to involve a lot wiring things together, it doesn't have to mean tremendously huge class diagrams before coding, and it is absolutely not related to one particular language. I can use OOP techniques in any language, and to the degree they're necessary, I should. It's just a tool. I understand that the OOP movement got way overblown and annoying, but we as technologist are always making overly-broad generalizations of anything we do. There's a tremendous amount of selection bias that goes on in technology, most of it hidden. I remember in one of my early contracting jobs we had a PM who was a FoxPro programmer. No matter what the problem we were talking about, somehow he would feel that FoxPro was the best answer for that problem. At the time I thought he was unique -- sort of a joke. Looking back over many years of observing technologists, however? He was the rule, not the exception. At the risk of stating the obvious we only understand those things we have familiarity with. This means if you haven't programmed in OOP, or if you've had extensive experience with OOP and you know somebody at the same experience level with different opinions, you should try very hard to have an open mind and learn something from somebody else. It's very easy to make broad claims that are unsupported by anything but a small set of observations. Saying "Are we still doing OOP?" is like saying "Are we still using categorization and set theory" which sounds to me a LOT like "Are we still using arithmetic?" The question is nonsensical.

plinkplonk 16y ago
"Saying "Are we still doing OOP?" is like saying "Are we still using categorization and set theory" which sounds to me a LOT like "Are we still using arithmetic?"" OO is hardly equivalent, and not as fundamental (or anywhere near fundamental) as Set Theory, leave alone Arithmetic. The implied equivalence is misleading. You can use "categorization" and Set theory to design programs with never an Object in sight. Types and (mathematical) functions are both defined using Set Theory as are Relations (as in relational databases). You could program in Haskell with only types and functions and monads and such with no "object oriented design". The primary difficulty for people who've only done (what some call) "OOP" is forgetting all the OO technique they learned. At best you could say that objects (for various definitions of "OO") could also be expressed with Sets and (mathematical) functions and such. ALmost every programming language feature could be so expressed, that isn't saying much. There is no specifically "Object Oriented" super technique that transcends all languages (both OO and non OO) and is applicable in all of them. You'd be cutting against the grain of many languages if you tried to think in OO while using them. LIke Fortan, you can write "OO" in any language and it isn't always a good thing to do. Not defending the author of TFA ( I don't read these "Ohh technique X or language Y is so outdated" type of articles any more) but the sentence quoted (' "Are we using OO" is lik e "Are we using Set Theory" ') is as generic and misleading as anything the author claimed. Balance in all things.

deleted 16y ago

[deleted]

elblanco 16y ago

Yes, next question?

duncanj 16y ago

1. How bizarre to consider Javascript not object-oriented programming. The entire page is represented in objects. 2. I think the worst thing that happened in OOP was the development of ER-like methods (Rumbaugh, Booch) to "model" the system before it got built. It doesn't clarify anything and it doesn't fit with the original idea from Smalltalk, where software is developed in a gradual and exploratory style. When he states you don't need to develop a "complex object class hierarchy" for a small task, I think he is falling into this trap. 3. Obviously, other approaches are good for a number of problems, and OOP is not the be-all and end-all. I would never avoid using it, though, because it is good for many problems, especially UI. OOP is worst in static languages (EC++), and best in dynamic languages (Smalltalk, Ruby, JS), in my opinion. 4. Spreadsheets. I wish the VBA interface to Excel were more OO, because I think the methods are on the wrong interfaces. There is definitely room for improvement. OTOH, the user interface is a facade around something that may or may not be implemented in OO. I also wish that I could refer to things in the user interface using OO methods, kind of like using Prototype in JS. 5. In financial applications, I wonder what technique allows him to "innovate" without his model "breaking down". He doesn't say, but it sure seems like he doesn't like objects! (for whatever reason, he also doesn't really say.) 6. Finally, I get the feeling that he's really saying he no longer writes a real object model for his applications. This is, apparently, because the object libraries he is working with have gotten so good at modeling everything he needs that he is mostly writing glue, and it is all fitting into a few modules of mostly procedural code. So, in other words, OO is a huge success.

hxa7241 16y ago

It is not so much OO that is receding as inheritance. Although that is not recent -- it must have been around 1995-2000 that doubts were becoming popularly known. Inheritance is somewhat interesting though: it is a formalised mechanism or pattern for changing software function -- there doesn't seem much else like that. Why did it not work very well? As to OO, Bertrand Meyer gives the best rationale: it is about organising software around data instead of procedure, because data is more stable. That yields a rather abstract definition, but in that sense OO is perhaps more alive now than ever. What has happened is that the developer's canvas has expanded enormously. We think and write for the WWW first now. The data types are the various sub-parts and relations of web standards. Our software is very much organised around these, they just don't map to small language features.