Live data from Hacker News

Are we still doing OOP?

hackinghat.com

31–37 of 37 posts

Re: Are we still doing OOP?

#31

Earlier quoted context omitted.

Looking at this thread, it seems your main disagreement is about the definition of OOP. I won't provide one, mind you. But such disagreements are so widespread that we may want to stop using the term OOP altogether, and only use more narrowly defined terms.

No rhetorical trick intended. It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point. I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!" However use-case analysis is just a way of thinking about system functionality. Most pe…

OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking.

Yeah except Alan Kay, you know that guy who invented OOP, says everything you mention there is the overly complex BS unOOP. OOP is late binding and message passing. It isn't the hair splitting you seem to think it is, it truly different philosophies about programming. What you are calling OOP is more like Structured Programming Redux, strong on the structure and light on the dynamic message passing and late binding.

Re: Are we still doing OOP?

#32
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.

Re: Are we still doing OOP?

#33

Earlier quoted context omitted.

Looking at this thread, it seems your main disagreement is about the definition of OOP. I won't provide one, mind you. But such disagreements are so widespread that we may want to stop using the term OOP altogether, and only use more narrowly defined terms.

No rhetorical trick intended. It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point. I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!" However use-case analysis is just a way of thinking about system functionality. Most pe…

> No rhetorical trick intended.

(I suppose you refer to the "just a tool" sentence.) I'm sure of that. It's just that its an easy sentence to throw up while not really thinking about it. I see it often, and it rarely actually says something. And its effect, whether intended or not, is often the rhetorical trick I spoke of.

About the rest, I agree: when (if) disagreeing parties manage to set definitions straight, they often find that they actually agree.

Re: Are we still doing OOP?

#34

Earlier quoted context omitted.

No rhetorical trick intended. It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point. I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!" However use-case analysis is just a way of thinking about system functionality. Most pe…

OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking. Yeah except Alan Kay, you know that guy who invented OOP, says everything you mention there is the overly complex BS unOOP. OOP is late binding and message passing. It isn't the hair splitting you seem to think it is, it tru…

Alan Kay? Well gee, you should have said something. Here I was using working definitions and Alan Kay already had the answer.

Either you understand how silly you sound or you do not. I suspect the latter. Perhaps you and Alan could continue the discussion.

Re: Are we still doing OOP?

#35

Earlier quoted context omitted.

No rhetorical trick intended. It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point. I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!" However use-case analysis is just a way of thinking about system functionality. Most pe…

OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking. Yeah except Alan Kay, you know that guy who invented OOP, says everything you mention there is the overly complex BS unOOP. OOP is late binding and message passing. It isn't the hair splitting you seem to think it is, it tru…

In his own words (from HN, I think): http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

The way I read this, he should have called his paradigm "Message Oriented Programming", and Erlang is actually closer to his views than Java.

Re: Are we still doing OOP?

#36

Earlier quoted context omitted.

OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking. Yeah except Alan Kay, you know that guy who invented OOP, says everything you mention there is the overly complex BS unOOP. OOP is late binding and message passing. It isn't the hair splitting you seem to think it is, it tru…

Alan Kay? Well gee, you should have said something. Here I was using working definitions and Alan Kay already had the answer. Either you understand how silly you sound or you do not. I suspect the latter. Perhaps you and Alan could continue the discussion.

What can I say a silly response to a silly post. Information hiding, encapsulation,polymorphism, have been Software Engineering principles before OOP was invented Using X == good software engineering then X is the true definition of OOP no matter how you program it, and all that bad OOP code is just wolves in OOP clothing is humorous. Good clean structured code may look similar to OOP code. If the author was not Oriented on Objects then it isn't OOP code. OO is more about how you get there than where you end up.

Re: Are we still doing OOP?

#37
post #4
post #3

Earlier quoted context omitted.

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.

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

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.

Post reply on HN