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

Re: OOP Isn't a Fundamental Particle of Computing

#161

Post by wvenable » Sat, Nov 17, 2012, 4:13 AM UTC

papsosouid wrote: post #160

wvenable wrote: post #159

Earlier quoted context omitted.

> Why do you think RGB being bytes makes it special? Bools aren't bytes... Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation). How would you handle a real complex type like Customer or Order or Window or Button? > That does nothing to prevent errors. Yes, it does. It's effectively the DRY principle -- you can't repeat the data…

>Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation). No they aren't. You are assuming every language is as shitty as Java. This is not the case. There is nothing special about Bool, it is a normal ADT: Bool = True | False >How would you handle a real complex type like Customer or Order or Window or Button? Defining a type for i…

> You are assuming every language is as shitty as Java.

Perhaps. Java, C#, C++, PHP, Python, Ruby, etc.

> Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes.

If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow.

> And how on earth does this bizarre notion address the class of errors you were complaining about, which are type errors?

Just as I said above, it's difficult to alter the contents of an object in a way that an object doesn't allow. In "pure" Alan Kay style OOP an object is something that responds to messages. In loose languages like Python you can reach into an object and mess with it but that is discouraged.

Re: OOP Isn't a Fundamental Particle of Computing

#162

Post by toddh » Sat, Nov 17, 2012, 3:00 PM UTC

DanielBMarkham wrote: post #66

bad_user wrote: post #63

Earlier quoted context omitted.

Most people that have a problem with OOP are conflating it with how OOP gets used in Java. Like if you wanted to represent a RGB pixel on screen, in Java that ends-up being a class having methods like draw() and such. And this is the problem with OOP in Java, because of the limited toolset, you always end up having heavy Objects that have their own behavior instead of functions that operate on a whole composite of su…

"Is this OOP?" Okay, that's beyond my pay grade. I could argue that either way. OOP is the grouping of data and functionality into units called types or classes. So yes, technically, but I know what you mean. I agree that Java is a bad way to start, but I wonder if I wouldn't come at it from just the opposite angle. Start with C, move to structs, then move to something like the class you show, then to more complex ty…

Programs are just wires. We just pretend some of the wires are different.

Re: OOP Isn't a Fundamental Particle of Computing

#163

Post by papsosouid » Mon, Nov 19, 2012, 3:23 PM UTC

wvenable wrote: post #161

papsosouid wrote: post #160

Earlier quoted context omitted.

>Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation). No they aren't. You are assuming every language is as shitty as Java. This is not the case. There is nothing special about Bool, it is a normal ADT: Bool = True | False >How would you handle a real complex type like Customer or Order or Window or Button? Defining a type for i…

> You are assuming every language is as shitty as Java. Perhaps. Java, C#, C++, PHP, Python, Ruby, etc. > Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes. If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow. > And how on earth does this bizarre noti…

>If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow.

That applies just as much to functional programming as it does to object oriented programming. If you don't want people to mess with the internals, then don't export them.