Live data from Hacker News

OOP Isn't a Fundamental Particle of Computing

prog21.dadgum.com

41–50 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#41
post #20

I agree with the author's conclusion "When blindly applied to problems below an arbitrary complexity threshold, OOP can be verbose and contrived" but I think he fails to recognize that the opposite is also true. Yes, it's much simpler to store RGB color in a three-element tuple when you're working on simple code that you've written all yourself. But what happens when get a tuple from somewhere containing {289, 345, -…

"...but I think he fails to recognize that the opposite is also true" I don't think that is the case at all. In fact, it is specifically implied in the sentence that you chose to quote. Why is the top reply to every HN story always so darn contrarian and nit-picky (in this case, not even validly so)? Why can't it just once be "Yep, you nailed it." (or something insightful)

> Why can't it just once be "Yep, you nailed it."

Insubstantial praise isn't really worthwhile unless invited. If it's invited, it'll be through comments on the article itself, not on an aggregator like HN.

I don't disagree with your overall point: the nitpicking is nearly as worthless: but if you don't have anything substantial to say, it isn't worth saying anything. Just upvote and move on.

Re: OOP Isn't a Fundamental Particle of Computing

#42

My question then is: where is the sweet spot? What's the right amount of OOP before it becomes overkill? Is it perhaps a matter of domain, and therefore some domains will benefit much less of OOP?

I think that it's a question of how difficult it is to hold the entire idea in your head. The utility of OOP is in breaking down a difficult idea into manageable parts; if you can commandingly capture the entire thing in a thought, OOP is overkill. Write your program and be done with it; tweak when needed. If you find yourself backtracking and needing to map things out on paper, though, OOP is probably a much better fit.

So my answer is basically, "Can you explain it in the elevator?"

Re: OOP Isn't a Fundamental Particle of Computing

#43

I happened to read this interview ( http://www.codequarterly.com/2011/rich-hickey ) with Rich Hickey today which I'm sure has been posted here before. I mention this because of this statement: > When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-…

Which is interesting considering how often "write a DSL for every problem" is used as a selling point for lisps.

Re: OOP Isn't a Fundamental Particle of Computing

#44
post #34
post #24

Earlier quoted context omitted.

You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? You sound like someone who doesn't really understand performance very well. Lists and strings and arrays as implemented in any scripting language can implement virtually any algorithm with only a constant factor performance and…

Yeah I always hear people saying how Python is slow. But in 10 years of Python programming, I see 2 repeated performance anti-patterns: 1) Writing quadratic loops and not realizing it, then it blows up on a biggish data set. This is quite easy to do in Python because people don't realize that "in" on a list and .remove() and so forth do a linear search. 2) Writing Python like Java, where you have tons of indirection,…

The person I was responding to sounds likely to make mistake #2.

Re: OOP Isn't a Fundamental Particle of Computing

#45
> Then in the next assignment the simple three-element tuple representing an RGB color is replaced by a class with getters and setters and multiple constructors and--most critically--a lot more code.

How about using a simple struct/record? Not too much boilerplate, and if you're using a statically typed language it can be nice to at least give these things a type to help you out.

Re: OOP Isn't a Fundamental Particle of Computing

#46
post #16

> in the next assignment the simple three-element tuple representing an RGB color is replaced by a class with getters and setters and multiple constructors and--most critically--a lot more code. This is in the classroom setting, during the learning process. It's good to reuse the same example to explore different concepts, from map to class, so that the students don't have to build up a different mental model with an…

Also, "rewrite this RGB color to be a class" is a poor choice of assignment because it doesn't exercise any of the strengths of OOP.

Instead, try "rewrite this as a color class that can handle RGB, CMYK, or HSV representations." Now the value (and challenges) of a good abstraction is made apparent!

Re: OOP Isn't a Fundamental Particle of Computing

#47

My question then is: where is the sweet spot? What's the right amount of OOP before it becomes overkill? Is it perhaps a matter of domain, and therefore some domains will benefit much less of OOP?

* The sweet spot is to use OOP only when needed. * Abstract your core functions to the max

Here is a real life example. I write a software which is based mostly on functions. A php based CMS

If you look at it from aside, you will say its huge and probably needs a lot of code (and objects). The truth is that the core set of functions are less than 20 and less than 100K of code.

If you write your functions well, you don't need OOP and you will have - less code - less memory usage (functions free memory after run) - less problems

Re: OOP Isn't a Fundamental Particle of Computing

#48

My question then is: where is the sweet spot? What's the right amount of OOP before it becomes overkill? Is it perhaps a matter of domain, and therefore some domains will benefit much less of OOP?

OOP is great when your main focus are data structures. Many enterprise applications are basically just transforming data from one system to another. Being able to come to an unknown code and figure out what is the format of input and output just by reading couple of classes is a godsend. Even in this case use OOP features sparingly (beware of deep hierarchies, contrived polymorphism etc).

On the other hand when your problem is more about algorithms and evaluation of data you might choose more functional approach.

Hybrid (object+functional) approach is getting even to the enterprise world - SOA suggests to have dumb (possibly immutable) data objects for business objects (just like struct in C) and service objects that perform operations on these data objects (not unlike functional programming). Similar pattern is with dependency injection frameworks that rely heavily on singletons (Spring) - many beans become just containers for stateless functions.

OOP is not silver bullet (nothing is for that matter), but it is a very useful tool.

Re: OOP Isn't a Fundamental Particle of Computing

#49
The late professors Kristen Nygaard and Ole Johan Dahl, at the University of Oslo in Norway, only intended their invention of the class based OOP programming language named SIMULA to be used to simulate real world objects. It has since proved valuable as a tool for making abstractions in software. The concept was invented by LISP programmers.

Re: OOP Isn't a Fundamental Particle of Computing

#50
post #36
post #22

Earlier quoted context omitted.

> OOP is not that useful for anything other than namespacing Namespacing, and modularization in general, are cornerstones of well structured code. OOP gives you nice tools to help with this.

OOP gives you tools. Having spent the last 15 years using them, I'm not convinced they are nice.

Maybe you use C++, Java or one of the languages in that family?
Post reply on HN