OOP Isn't a Fundamental Particle of Computing • Hacker News Board

Re: OOP Isn't a Fundamental Particle of Computing

#11

Post by irahul » Wed, Nov 14, 2012, 4:34 AM UTC

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…

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

I am pretty sure he is saying he doesn't have to manually allocate and free memory and worry about off by one errors when iterating. He is comparing equivalents; he isn't saying since I am using Python I can shove 1 billion numbers in a list.

> Can you imagine going into a programming interview and saying something like this?

The only occasion when programming interviews have any significance is when you are seeking a job. Using them as a benchmark for anything else is flawed.

> It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing around dictionaries of dictionaries and lists.

Translating proven, classical design patterns to Python or Ruby will result in shitty code. The proven design patterns don't have to be the same for all languages. It's idiomatic to use dictionaries/list in place of classes where applicable.

http://norvig.com/design-patterns/

https://www.youtube.com/watch?v=0vJJlVBVTFg

http://designpatternsinruby.com/

Re: OOP Isn't a Fundamental Particle of Computing

#12

Post by darkarmani » Wed, Nov 14, 2012, 4:37 AM UTC

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.

You mean if you are memory or cpu-bound and not IO bound?

Re: OOP Isn't a Fundamental Particle of Computing

#13

Post by hurshp » Wed, Nov 14, 2012, 4:51 AM UTC

There is nothing theoretical behind OOP its just how we currently abstract and modularize code for human consumption.

I know its flame war stuff but I really think marketing from certain languages got everyone into the OOP paradigm as the best way, Its funny sometimes I talked to people who programmed in the 80's and they talk about how OOP didn't really solve anything for them. Its always interesting conversation.

Re: OOP Isn't a Fundamental Particle of Computing

#14

Post by carstimon » Wed, Nov 14, 2012, 4:53 AM UTC

I program almost completely for myself. I recently moved up a scale from only being able to write small programs (solving simple mathematical problems) to larger ones.

I think my block from being able to write larger programs was that I would get too caught up in creating classes. I would start a large project by abstracting and abstracting and thinking about the most general class. I found that I just thought about what data fields I needed, not what I actually wanted to do.

More recently I've tried to limit how much time I think about how to store data. Do the quickest thing first, and only think about your data storage when you find yourself writing the same thing over and over.

Maybe you call this "premature abstraction", in comparison to premature optimization?

Re: OOP Isn't a Fundamental Particle of Computing

#15

Post by jonathanwallace » Wed, Nov 14, 2012, 4:55 AM UTC

carstimon wrote: post #14

I program almost completely for myself. I recently moved up a scale from only being able to write small programs (solving simple mathematical problems) to larger ones. I think my block from being able to write larger programs was that I would get too caught up in creating classes. I would start a large project by abstracting and abstracting and thinking about the most general class. I found that I just thought about…

It sounds like to me that you're finally learning what design means and how to design well. :)

Re: OOP Isn't a Fundamental Particle of Computing

#16

Post by ww520 » Wed, Nov 14, 2012, 4:55 AM UTC

> 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 another example. It's like writing Hello World in different languages to illustrate the language mechanics. It has nothing to be with whether the requirement (RGB) is too simple for an OOP implementation.

You are using trivial examples to prove "OOP Isn't a Fundamental Particle of Computing." This is the classic straw man fallacy.

Re: OOP Isn't a Fundamental Particle of Computing

#17

Post by wvenable » Wed, Nov 14, 2012, 4:58 AM UTC

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, -1}? Or god forbid {200, "Monkeyspit", {}}!

The measure of simplicity and complexity is a double-edged sword. Making everything a class for a small project, as the author concludes, is a recipe for confusion and pain. However, not using strictly defined self-contained data types for a large project is also recipe for confusion and pain.

"there's often an aesthetic insistence on objects for everything all the way down"

I don't think there's anything wrong with that -- in many languages arrays are objects, dictionaries are objects, and tuples are objects and they let you be as unstructured as you want to be -- but it's still objects all the way down.

Re: OOP Isn't a Fundamental Particle of Computing

#18

Post by jerf » Wed, Nov 14, 2012, 5:13 AM UTC

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 which Haskell is merely a convenient example. Even more conventional manifest typing, as in C, works well enough here.) If you want to declare that you have a map of Booglies to Wangdoodles, it's trivial, but you're still using off-the-shelf maps and not bashing together trees yourself.

Re: OOP Isn't a Fundamental Particle of Computing

#19

Post by jerf » Wed, Nov 14, 2012, 5:15 AM UTC

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…

It seems like someone always pops up when a dadgum.com article comes up that is anything less than 100% focused on performance, and I once again find myself recommending that you review the sidebar. Anyone who has programmed games on the Super Nintendo, a machine with specs that would be inadequate for a USB bus controller nowadays, understands performance just fine. It's just that he's also come to understand when it doesn't matter, something that some of his fellow assembler programmers don't always end up working out.

Re: OOP Isn't a Fundamental Particle of Computing

#20

Post by zainny » Wed, Nov 14, 2012, 5:18 AM UTC

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

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