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

151–160 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#151

Post by [deleted] »

seanmcdirmid wrote: post #93
michaelochurch wrote: post #92

Earlier quoted context omitted.

The problem with the mutability debate is that most examples show two programs, one mutable and one immutable, on the scale of about 20 lines of code. At the small scale, it's a toss-up which is better. Often the mutable solution's more intuitive for most programmers, and sometimes just flat-out superior: more clear, easier to understand. Mutable state isn't evil. It's necessary in the real world. It's just that stat…

When you have state...I mean real state, it sure is nice to encapsulate that state in an object rather than in what is basically an unencapsulated monad. OO supports state encapsulation, pure FP basically does not, that is a big deal. Immutable programming sort of side steps the issue, that state is needed at all, that an interactive program can somehow be stateless is ridiculous, even many batch programs require som…

[deleted]

Re: OOP Isn't a Fundamental Particle of Computing

#152

Post by colanderman »

tikhonj wrote: post #150
colanderman wrote: post #148

Earlier quoted context omitted.

The pedant in me agrees (class-constrained types are not types and therefore not subtypes), but the pragmatist in me still wants to think of class-constrained types as forming a subtyping hierarchy :) even if doing so requires explicit typecasting. Some food for thought: In Mercury, you can combine existential types with typeclasses like so: type foo ---> some [T] (foo(T) => printable(T)). Pedantically, foo is a dist…

You can do similar existential types in Haskell: {-# LANGUAGE ExistentialQuantification #-} data Foo = forall a. Show a => Foo a [Foo 10, Foo "blarg", Foo (Foo (Foo "str")) However, I think having the extra constructor there is very important. If you were willing to overlook extra syntax and the behavior of the type, then even a normal tagged union starts to look like sub-typing! In fact, in practice, that's exactly…

Thanks for the insights!

Re: OOP Isn't a Fundamental Particle of Computing

#153

Post by se85 »

seanmcdirmid wrote: post #137
se85 wrote: post #109

Earlier quoted context omitted.

Oh really? A pipedream you say? Oh ok then...

Let me reply your one liner with my own: nice elegant composable abstractions are great when they work, and very horrible when they don't.

I don't see how this is any different for "OOP" though (or anything in life for that matter)?

Things are always great till they don't work, and usually are absolutely horrible when they don't.

I see your pipe dream on a daily basis as do many other competent functional programmers so I have to disagree with your entire argument which seems to more related to human error than programming paradigms getting in the way.

Re: OOP Isn't a Fundamental Particle of Computing

#154

Post by wvenable »

papsosouid wrote: post #104
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, -…

As jerf and danieldk point out, your concern is "I want static typing", and has nothing to do with OOP.

Static typing is one way of accomplishing something similar but it's neither necessary nor sufficient. Sure you can define an RGB value as three 8-bit bytes and get something that's valid all of the time. But that's a contrived example because RGB color is defined in terms of bytes! What about every other piece of data in your application?

In simplest terms, OOP combines opaque data structures with the operations performed on them. This should, if done correctly, prevent a whole lot of different kinds of easy to make mistakes. It also helps simplify and organize code.

Re: OOP Isn't a Fundamental Particle of Computing

#155

Post by protez »

The essence of OOP is the Interface, the human interface, which conforms to human brain, rather than machines. It's all about the conceptual framework to abstract out complexity into the names corresponding to what we're trying to program in the first place. That's it. All the verbosity and complexity of OOP is the secondary effect to actualize the particular implementation of the Interface.

On the other hand, the fundamental particle of computing is indeed, not object, nor class, but a sequence of bits. However, the fundamental particle of programming, or collaborative programming so far, has been based on the idea of objects. If one has the better idea, it would be about making the Interface more friendly to human brains.

Re: OOP Isn't a Fundamental Particle of Computing

#156

Post by klibertp »

pjmlp wrote: post #149
klibertp wrote: post #147

Earlier quoted context omitted.

Ok, thanks, now I understand what you mean. Just note that F# is not functional by your definition, because all it's core datastructures (tuples, arrays, lists) are actually objects, with methods on them etc.

Regarding F# I was not sure if I should have mentioned it. Still do not much about it or how its implementation generates code, as the MSIL supports much more than just OO constructs.

Yeah, but it's not possible (I think, but am not 100% sure) to reason about F# code without object semantics because of how it's implemented: it probably could be implemented on top of MSIL without objects, but (again, not 100%, but 95% sure :)) it isn't.

I thought about another language I think you'd call functional: Lua. It supports first- and higher-order functions and has no objects at all in the core language. What do you think?

Also, now that I understand what you mean I can agree with you, but you do realize that this is not very common definition of "functional", right? :)

Re: OOP Isn't a Fundamental Particle of Computing

#157

Post by stcredzero »

cwbrandsma wrote: post #128
stcredzero wrote: post #120

Earlier quoted context omitted.

> Treated the way it often is, OOP is not that useful for anything other than namespacing and creating ridiculous hierarchy structures just because "it's oop" and inheritance lets humans do what they love to do - name and categorize things. Leave out inheritance, but keep interfaces, and you get better OOP.

Yes, then you get VB6. Not sure that is the paragon of language design you are looking for. Inheritance is a very useful tool, but like many other things, overuse of inheritance is worse than not using it at all.

Yes, then you get VB6. Not sure that is the paragon of language design you are looking for.

Most of the qualities that make VB6 VB have nothing to do with inheritance. This is a logical fallacy, where you argue by associating one quality with something looked down upon.

http://en.wikipedia.org/wiki/Association_fallacy

Re: OOP Isn't a Fundamental Particle of Computing

#158

Post by papsosouid »

wvenable wrote: post #154
papsosouid wrote: post #104

Earlier quoted context omitted.

As jerf and danieldk point out, your concern is "I want static typing", and has nothing to do with OOP.

Static typing is one way of accomplishing something similar but it's neither necessary nor sufficient. Sure you can define an RGB value as three 8-bit bytes and get something that's valid all of the time. But that's a contrived example because RGB color is defined in terms of bytes! What about every other piece of data in your application? In simplest terms, OOP combines opaque data structures with the operations per…

>What about every other piece of data in your application?

I create a type for it? Why do you think RGB being bytes makes it special? Bools aren't bytes, but I can't pass anything other than True and False for a Bool.

>OOP combines opaque data structures with the operations performed on them.

That does nothing to prevent errors. Having the operations require the correct types does prevent errors on the other hand, regardless of whether or not the operations and data are put into an "object" together or not.

Re: OOP Isn't a Fundamental Particle of Computing

#159

Post by wvenable »

papsosouid wrote: post #158
wvenable wrote: post #154

Earlier quoted context omitted.

Static typing is one way of accomplishing something similar but it's neither necessary nor sufficient. Sure you can define an RGB value as three 8-bit bytes and get something that's valid all of the time. But that's a contrived example because RGB color is defined in terms of bytes! What about every other piece of data in your application? In simplest terms, OOP combines opaque data structures with the operations per…

>What about every other piece of data in your application? I create a type for it? Why do you think RGB being bytes makes it special? Bools aren't bytes, but I can't pass anything other than True and False for a Bool. >OOP combines opaque data structures with the operations performed on them. That does nothing to prevent errors. Having the operations require the correct types does prevent errors on the other hand, re…

> 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 manipulation code throughout the codebase. OOP formalizes some of the best practices for procedural programming.

Re: OOP Isn't a Fundamental Particle of Computing

#160

Post by papsosouid »

wvenable wrote: post #159
papsosouid wrote: post #158

Earlier quoted context omitted.

>What about every other piece of data in your application? I create a type for it? Why do you think RGB being bytes makes it special? Bools aren't bytes, but I can't pass anything other than True and False for a Bool. >OOP combines opaque data structures with the operations performed on them. That does nothing to prevent errors. Having the operations require the correct types does prevent errors on the other hand, re…

> 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 it, just like anything else? I don't understand what is confusing you here. Do you normally just keep your Customers or Orders as a hash table of string:string or something? Even in OO languages, you create a type for them, it just happens that the only way you can create types in most OO languages is making classes.

>Yes, it does. It's effectively the DRY principle -- you can't repeat the data manipulation code throughout the codebase

Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes. I am amazed that you are seriously suggesting that the problem OOP solves is people accidentally writing the same function multiple times, when that was never a problem, and OOP doesn't do anything to address it. And how on earth does this bizarre notion address the class of errors you were complaining about, which are type errors?

Post reply on HN