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

31–40 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#31

Post by Evbn »

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

Eh, An object can expose an array interface or whatever for use in efficient algorithms and reusable libraries. Simple example is how C++ strings have c_str() or whatever it is called.

Re: OOP Isn't a Fundamental Particle of Computing

#32

Post by andrewflnr »

Evbn wrote: post #31
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-…

Eh, An object can expose an array interface or whatever for use in efficient algorithms and reusable libraries. Simple example is how C++ strings have c_str() or whatever it is called.

I think a more interesting example is how every standard C++ container has the same iterator-based interface for iterating over it.

Re: OOP Isn't a Fundamental Particle of Computing

#33

Post by Evbn »

zanny wrote: post #30
btilly wrote: 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…

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.

Re: OOP Isn't a Fundamental Particle of Computing

#34

Post by chubot »

btilly wrote: post #24
btipling wrote: post #3

> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. 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? It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing a…

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, which is slow. People somehow feel naked when they only have to type 10 characters rather than banging out a bunch of boilerplate for a mundane task.

When you're just using basic data structures in an idiomatic way, Python is fast. I think there were some dictionary-heavy benchmarks I saw awhile ago where Python is faster than Go, because its dictionaries are so highly tuned.

Re: OOP Isn't a Fundamental Particle of Computing

#35

Post by artsrc »

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

> However, not using strictly defined self-contained data types for a large project is also recipe for confusion and pain.

Not using well defined data types for in a widely exposed interface in a large project is suboptimal.

Overly formalizing data types for entities of limited scope is suboptimal on small and large projects.

We need to be careful about adding unnecessary weight to large projects, because it costs more there.

> in many languages arrays are objects, dictionaries are objects, and tuples are objects

I am not aware of a canonical definition of object. One thing that is commonly included is the idea that objects have identity. So "two" arrays with the same values are distinguished in the object world. This is not what people mean if they create an RGB from an array (or dictionary).

Re: OOP Isn't a Fundamental Particle of Computing

#36

Post by ynniv »

guelo wrote: post #22
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…

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

Re: OOP Isn't a Fundamental Particle of Computing

#37

Post by microtonal »

jerf wrote: post #18
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, -…

Your argument, unfortunately, doesn't really work, because for instance, in Haskell, data RGB = RGB Word8 Word8 Word8 The point made here has nothing to do with weak typing. It just so happens his example sort of implies that he might be using it, since the author rather likes Erlang and that appears to be the syntax he reaches for, but the entire article applies without loss to strongly-typed languages as well. (Of…

In this case, Word8 applies nicely, but I'd like to point out that the argument doesn't fly either when something isn't nicely mapped to a type. E.g. (not checked):

    module Temperature (
      TempCelsius
      tempCelsius
    ) where

    newtype TempCelsius = TempCelsius Double

    absoluteMinimum :: Double
    absoluteMinimum = -273.15

    tempCelsius :: Double -> Maybe TempCelsius
    tempCelsius t
      | t
In other words, by hiding the constructor, you can control all access to a datatype. You could do the same with opaque pointers in C, etc.

Re: OOP Isn't a Fundamental Particle of Computing

#38

Post by btilly »

zanny wrote: post #30
btilly wrote: 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…

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.

Yes, all of those make a difference. Sometimes a big one.

But in general, it is best to just try to be reasonably sane and not worry about it until you have a proven problem. A surprising fraction of the time, a "reasonably sane" approach is not that far off from optimal. And setting the bar there helps development speed.

Which, of course, is what you care about when you choose to use a scripting language. If you care more about computer time than developer time, then using a more efficient language makes sense.

Re: OOP Isn't a Fundamental Particle of Computing

#40

Post by gridaphobe »

hackinthebochs wrote: post #23
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…

>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? Of course this is the most degenerate case of an object, so pointing to this as an counter-argument to OOP seems rather specious. The typical case is that the data being encapsulated is related to each other in some way, and thus having a restricted set of operations on the…

> You say that like its a bad thing. If humans like to categorize, why shouldn't our programming languages be designed around this tendency?

I've always had the impression that we (at least as programmers) are incredibly bad at categorizing things into hierarchies.

I think class hierarchies (and module hierarchies for that matter) suffer from a similar problem to that of hierarchical file systems, there is often more than one way of organizing the items and it's unclear which way is right. I'd like to see if one could use a tagging mechanism instead; I guess interfaces/mixins/traits could be thought of as tags for classes though.

Post reply on HN