Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OOP Isn't a Fundamental Particle of Computing

prog21.dadgum.com

Post reply on HN
Print view View original

51–60 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#51

Post by louischatriot »

wvenable wrote: post #17

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, -…

I think it comes down to discipline. We're using javascript (on both frontend and backend) which is not very strict, but we don't have that many "wtf is that kind of object doing here?" moments, and none after tests pass.

Re: OOP Isn't a Fundamental Particle of Computing

#52

Post by justincormack »

Evbn wrote: post #33
zanny wrote: post #30

Earlier quoted context omitted.

Cache coherency matters, and making sure a large data structure fits in memory is important too. If you can't fit it, at least make it nicely match up to page boundaries. If you don't understandt he implementation of your choice array / set / map / tuple data structure that you are throwing around all over the place, you could be missing plenty of performance just from TLB misses or some other hardware voodoo.

This matters if you are Google, serving gigabytes of data per user for free. This matters less for sites whose compute budget is 10% of their human budget, where trying to cut from 2x to 1x on compute isn't worth the human cost.

I imagine Google's staff budget is hugely higher than their compute budget. But when budgets get big you want to cut them anyway ...

Re: OOP Isn't a Fundamental Particle of Computing

#53

Post by jeffdavis »

programminggeek wrote: post #9

Well, most OOP isn't object oriented at all, it's class oriented or maybe another way to look at it is that most of the time OOP is used as containers for data and function, not for things. For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash? Is that object oriented? If you add a couple helper methods to said object is it more…

You and the author appear to be using different definitions. I find it troubling that, after all this time, there is still no definition that doesn't use words like "thing".

Re: OOP Isn't a Fundamental Particle of Computing

#55

Post by fholm »

ridiculous_fish wrote: post #46
ww520 wrote: 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!

You mean like this? :)

    type Color 
        = RGB of int * int * int
        | HSV of int * int * int
        | CMYK of int * int * int * int

    let toHsv = 
        function
        | HSV(h, s, v) -> HSV(h, s, v)
        | RGB(r, g, b) -> ...
        | CMYK(c, m, y, k) -> ...

Re: OOP Isn't a Fundamental Particle of Computing

#56

Post by nickik »

Avshalom wrote: post #43
jeremyjh wrote: post #29

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.

DSLs still use normal data down below. Thats part of why it is so easy to write DSLs.

You can write a Datalog DSL and it can work with almost everything. You can write a Prolog DSL and it can work with everything.

You can still expose and send around all the data the DSL uses. The trick is not to mix up what is functinality and what data, witch is what standard OOP does. Many good OO Languages like Dylan or Common Lisp do not do that.

Re: OOP Isn't a Fundamental Particle of Computing

#57

Post by lmm »

justincormack wrote: post #52
Evbn wrote: post #33

Earlier quoted context omitted.

This matters if you are Google, serving gigabytes of data per user for free. This matters less for sites whose compute budget is 10% of their human budget, where trying to cut from 2x to 1x on compute isn't worth the human cost.

I imagine Google's staff budget is hugely higher than their compute budget. But when budgets get big you want to cut them anyway ...

Poor logic on their part if so. Slowing your programmers down 2% to cut 10% off your hardware costs is usually a bad idea, and that's still true as your budgets for both grow, as long as the ratio stays the same.

(I don't think Google are stupid, I think their ratio probably has shifted to the point where their hardware budget is comparable to their salary budget. Which makes them a very unusual case)

Re: OOP Isn't a Fundamental Particle of Computing

#58

Post by lmm »

pjmlp wrote: post #54
ryandvm wrote: post #2

So true. I'm glad that non-OOP is finally getting mainstream traction (again).

The problem is that most languages touted as non-OOP actually have OO as their kernel data types, like Python, Ruby and JavaScript cases.

Why's that a problem? I like python because it removes a lot of the syntactic ceremony of a "pure-OOP" language; how that's actually implemented is irrelevant.

Re: OOP Isn't a Fundamental Particle of Computing

#59

Post by gdwatson »

jeffdavis wrote: post #53
programminggeek wrote: post #9

Well, most OOP isn't object oriented at all, it's class oriented or maybe another way to look at it is that most of the time OOP is used as containers for data and function, not for things. For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash? Is that object oriented? If you add a couple helper methods to said object is it more…

You and the author appear to be using different definitions. I find it troubling that, after all this time, there is still no definition that doesn't use words like "thing".

I like the Rees OO ontology[1]. The set notation doesn't lend itself to easy reading, but it lets you break out the features of an object system in a more precise way.

[1] http://mumble.net/~jar/articles/oo.html

Re: OOP Isn't a Fundamental Particle of Computing

#60

Post by DanielBMarkham »

Yeah not so much.

I've become a huge fan of FP over OOP over the last couple of years, but I think he missed it.

At some point early in any program, you have to concatenate existing types into something else purposed for the solution you are writing. In the OOAD world, we call this moving from the problem domain to the solution domain.

Is an RGB value just a tuple? Depends on what the problem is. In the context of just one pixel, yes. In the context of an image processing application, you may need an alpha channel, a grid of pixels, an undo, and so forth. By identifying just one type instead of talking about a problem, RGB, the author has created a circular reference. Why do you need more than a tuple for RGB values if you only have RGB values? Well you don't. But programs are not about tuples, they are about solving problems. Yes, a problem can only require one simple datatype to solve, but in my experience that's only for a very small subset of problems.

OOP concentrates just on assembling various pre-existing datatypes into something new in order to solve a problem. It concentrates on the type. FP concentrates on what you are doing with the type. Either way you still need to assemble various datatypes. The construction of a new type doesn't go away. The emphasis is just different. You don't need to worry about a copy constructor or any of that anymore because the goal isn't to create reusable types that can last forever. Multi-core processing and our experience with large systems is killing that concept -- most types don't scale as advertised.

So OOP skills aren't going anywhere. It's just instead of creating a complex type, we're using those skills to create the minimally-complex type sufficient for our immediate needs. Big change in focus.

Post reply on HN