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

141–150 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#141

Post by ionforce »

gridaphobe wrote: post #40
hackinthebochs wrote: post #23

Earlier quoted context omitted.

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

Isn't that what interfaces are?

Re: OOP Isn't a Fundamental Particle of Computing

#142

Post by papsosouid »

seanmcdirmid wrote: post #134
papsosouid wrote: post #124

Earlier quoted context omitted.

>do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. No? How would you get to that interpretation when I didn't even say anything about this theoretical person, but rather about you? >For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm! Unless you are doing programming languag…

> Unless you are doing programming language research, yes you can. Yes, I do, but no, its still a problem. With my colleagues, they are even more strict about OOP experience. I'm sort of unusual in that I appreciate FP experience, or I actually demand it, as part of finding well rounded candidates (very difficult in China, to be sure). You don't "transform" the egg chemically from an unbeaten to a beaten state. Inste…

I'm now unable to tell if your post is serious or satire. The strawmen are so glaring and absurd that I have a hard time believing you are seriously attempting to use them to make an argument. Chemistry, seriously?

Re: OOP Isn't a Fundamental Particle of Computing

#143

Post by mercurial »

zwieback wrote: post #129
mercurial wrote: post #75

Given the amount of comments on this article, I feel like I'm the only one who missed the point the author is trying to make. TFA goes from praising the existence and ease of use of data types, particularly collections, in high-level languages such as Python (an object-oriented language) and constrasts it to C and Pascal (neither of which are object-oriented) and then seems to extoll the virtues of relying on basic d…

I had the exact same impression. Your Libya analogy is perfect.

Actually stolen from an old Simpson episode :)

Re: OOP Isn't a Fundamental Particle of Computing

#144

Post by fusiongyro »

tikhonj wrote: post #116
colanderman wrote: post #88

I thought he was going to talk about how OOP can be broken down into several simpler orthogonal concepts, namely: 1) Code reuse (e.g. inheritance) 2) Implementation hiding (e.g. methods) 3) Subtyping (e.g. interfaces) 4) Code composition / programming in the large (e.g. classes) 5) Run-time dynamic dispatch (e.g. instances) Functional languages such as Haskell, Mercury, OCaml, and Scheme do a good job of teasing thes…

Just to be pedantic, what Haskell type-classes provide is not usually known as sub-typing. Sub-typing usually implies some relation between types such that every element of a sub-type is also an element of the super-type. Haskell does not have any sort of sub-typing in this sense. Every single value only belongs to a single type. What you get with type-classes is polymorphism: your function works for all types in the…

I think Matt Might did a great demonstration of something easy you can do with type classes that you can't do easily without them, in this article:

http://matt.might.net/articles/best-programming-languages/

In a project of my own I did a similar thing with intervals to what he did with lattices: I defined a type class for intervals and then made lists of intervals an instance of the class. Greatly simplified my own code for very little cost.

Re: OOP Isn't a Fundamental Particle of Computing

#145

Post by seanmcdirmid »

papsosouid wrote: post #142
seanmcdirmid wrote: post #134

Earlier quoted context omitted.

> Unless you are doing programming language research, yes you can. Yes, I do, but no, its still a problem. With my colleagues, they are even more strict about OOP experience. I'm sort of unusual in that I appreciate FP experience, or I actually demand it, as part of finding well rounded candidates (very difficult in China, to be sure). You don't "transform" the egg chemically from an unbeaten to a beaten state. Inste…

I'm now unable to tell if your post is serious or satire. The strawmen are so glaring and absurd that I have a hard time believing you are seriously attempting to use them to make an argument. Chemistry, seriously?

Totally serious. You picked beating, which is THE classic side effect operation, and you had no idea what was going on? If so, just refresh your memory on what beating the egg actually does (spoiler: people don't beat eggs because they are angry at them):

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

Your argument doesn't become strong just because you accuse me of logical fallacies, and actually, that's all you are really doing here. Good day.

Re: OOP Isn't a Fundamental Particle of Computing

#146

Post by papsosouid »

seanmcdirmid wrote: post #145
papsosouid wrote: post #142

Earlier quoted context omitted.

I'm now unable to tell if your post is serious or satire. The strawmen are so glaring and absurd that I have a hard time believing you are seriously attempting to use them to make an argument. Chemistry, seriously?

Totally serious. You picked beating, which is THE classic side effect operation, and you had no idea what was going on? If so, just refresh your memory on what beating the egg actually does (spoiler: people don't beat eggs because they are angry at them): http://en.wikipedia.org/wiki/Mixture Your argument doesn't become strong just because you accuse me of logical fallacies, and actually, that's all you are really do…

Well that is genuinely impressive then. Please explain to me how the fact that no chemical reaction occurs when beating an egg is in any way relevant, or even related to the discussion, or anything I said. I didn't say beating an egg caused a chemical reaction, and at no point would anyone who has even the loosest grip on reality consider that to be relevant at all.

Had you just suggested that beating eggs is a side effect, and thus not purely functional you would have gotten a response. But when you go so far off the rails that the only reasonable explanations are that you are trolling or insane you shouldn't expect people to take you seriously enough to bother responding.

Yes, beating an egg changes the state of the egg from unbeaten to beaten. Yes, this is a difference, however it is not a difficult to understand difference. I explain it all the time, that's why I used it as an example. "With functional programming, instead of the egg_beater function changing the egg, it takes in the unbeaten egg, and returns to you a beaten egg. If you gave the unbeaten egg a name, you can still use it.". That is easy to understand, which is why people respond with "oh, ok" instead of confusion. This concept has to be understood when teaching OOP too, as generally methods that just change state return "this" so you can chain method calls: egg->beat()->fry(). So proposing that it is some unfathomable difficulty with learning FP is ridiculous.

Re: OOP Isn't a Fundamental Particle of Computing

#147

Post by klibertp »

pjmlp wrote: post #121
klibertp wrote: post #107

Earlier quoted context omitted.

I think I don't understand what you mean. Why does it matter how lambda is implemented on the language level if it retains lambda semantics? Also, it seems that only languages you think worthy of being called "funtional" are various (typed or not) lambda calculi implementations? What is Scala, then? Not functional at all, too? Could you maybe provide a few examples of languages you'd call "functional" or "supporting…

Standard ML, Haskell, Miranda, Lisp, Scheme, OCaml, F#

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.

Re: OOP Isn't a Fundamental Particle of Computing

#148

Post by colanderman »

tikhonj wrote: post #116
colanderman wrote: post #88

I thought he was going to talk about how OOP can be broken down into several simpler orthogonal concepts, namely: 1) Code reuse (e.g. inheritance) 2) Implementation hiding (e.g. methods) 3) Subtyping (e.g. interfaces) 4) Code composition / programming in the large (e.g. classes) 5) Run-time dynamic dispatch (e.g. instances) Functional languages such as Haskell, Mercury, OCaml, and Scheme do a good job of teasing thes…

Just to be pedantic, what Haskell type-classes provide is not usually known as sub-typing. Sub-typing usually implies some relation between types such that every element of a sub-type is also an element of the super-type. Haskell does not have any sort of sub-typing in this sense. Every single value only belongs to a single type. What you get with type-classes is polymorphism: your function works for all types in the…

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 distinct type from any other. However, any T which is printable is effectively a subtype of foo, since you can use it wherever a foo is expecected, modulo some ugly syntax:

['new foo'(5), 'new foo'("apples"), 'new foo'([1, 2, 3])]: list(foo)

I believe you can do something similar in OCaml using module types. (Of course OCaml has true subtyping via polymorphic variants and functional objects.) I am not as familiar with Haskell, so I'm not sure if it supports existential types or not.

Dependent languages like Coq go even further -- you can augment types with arbitrary predicates to form "sigma types" which can act as subtypes of one another. You can even write entire programs using sigma types without explicit typecasting. However they remain distinct from true types, and therefore do not provide true subtyping (regardless how well-executed the illusion is).

Re: OOP Isn't a Fundamental Particle of Computing

#149

Post by pjmlp »

klibertp wrote: post #147
pjmlp wrote: post #121

Earlier quoted context omitted.

Standard ML, Haskell, Miranda, Lisp, Scheme, OCaml, F#

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.

Re: OOP Isn't a Fundamental Particle of Computing

#150

Post by tikhonj »

colanderman wrote: post #148
tikhonj wrote: post #116

Earlier quoted context omitted.

Just to be pedantic, what Haskell type-classes provide is not usually known as sub-typing. Sub-typing usually implies some relation between types such that every element of a sub-type is also an element of the super-type. Haskell does not have any sort of sub-typing in this sense. Every single value only belongs to a single type. What you get with type-classes is polymorphism: your function works for all types in the…

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 what you use where you would use sub-typing in a different language. There are some significant differences, but I'm sure you can see a parallel.

There is also an intuitive parallel between existential types and normal tagged unions. The existential type is somewhat like a way to create a tagged union for an unbounded number of types. This naturally means it can't actually be tagged--the tag loses its meaning and you now can't recover the type of the contents--but in practical terms they're similar.

As I said, thinking of it like sub-typing is a pretty good intuitive guide (although it might lead you astray sometimes). I was just being pedantic; there's something about formal semantics and type theory that just raises the pedant in me :P.

Post reply on HN