Live data from Hacker News

Objects, Identity, and Concept-formation (2008)

blog.higher-order.com

31–40 of 42 posts

Re: Objects, Identity, and Concept-formation (2008)

#31

The term "object-oriented" was coined by Alan Kay, and he did provide a much more precise meaning. Unfortunately, the term became a fad and was then diluted into all sorts of vaguely related ideas. http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented I find the original idea deep and worth thinking about.

Kay's concept survives if you substitute "function call" for "message". Sending a message to an object and receiving a reply is closely analogous to invoking a function and obtaining a return value. Unfortunately, his overall model implies single dispatch. Sure, "everything is an object", but only one thing is the leftmost argument: the thing that receives the message; and the other things are just arguments.

Re: Objects, Identity, and Concept-formation (2008)

#32
post #16

Earlier quoted context omitted.

I have no idea how defining the type of a function's domain is supposed to be indicative to dynamic dispatch or associated methods with classes. I think I don't understand your example :-( Perhaps you can elaborate, since I don't know much about either of these languages. Regarding existential types: yes, there's an intimate relationship between existential quantification and OOP. But you can distinguish the differen…

Julia/Clojure/Lisp does dynamic dispatch on the argument types of the function - it's called multimethods. So it seems to fit your criteria of "dynamic dispatch + associating methods to classes". And in some sense, it is used for object orientation - CLOS is built on it. But on the other hand, these languages are very far from what one would normally normally call "object oriented". I do agree with you that there is…

CLOS is completely, thoroughly, dyed-in-the-wool object oriented. It gives you generic functions which dispatch methods, by considering the class type of every (specializable) parameter. CLOS also avoids the silly problems by not putting methods into a class scope and dealing with symbol-table conflicts upon inheritance: like when inheriting from "graphical" and "lottery", working out whether the "draw" method renders pixels, or performs a lottery pick.

The CLOS design absolutely nails OO, and that's even before we look at the meta-object protocol.

Re: Objects, Identity, and Concept-formation (2008)

#33
post #13

Well, the author recommends induction as a means of figuring this out, and it seems for induction to work we need to have some existing example to induce the principle from (if I am remembering my maths, I might not be). So to figure out our concept it may be worth taking a look at what the use of object-oriented features is, and use that as a starting point. Maybe, again I am a little rusty on my inductive reasoning…

The article author was referring to inductive reasoning in the sense of epistemology, which is not the same as mathematical induction. In fact, mathematical induction is a deductive reasoning technique. Here's the relevant wiki article: http://en.wikipedia.org/wiki/Inductive_reasoning

You might also refer to this as "recursion" when talking about computer programming.

Re: Objects, Identity, and Concept-formation (2008)

#34
post #30

Earlier quoted context omitted.

Please, identify which things can't be done with parametric polymorphism. It is not clear what you are referring to.

[deleted]

Could somebody please elaborate on what that means and how it applies in this context?

Re: Objects, Identity, and Concept-formation (2008)

#35
post #17

Earlier quoted context omitted.

"has nothing to do" ... says you! I didn't describe static parametric polymorphism. Some of the things I described are doable with static parametric polymorphism in some limited circumstances.

Well, you described parametric polymorphism (a generic Nth function) and then switched to talking about dispatching on tags at runtime. You are mistaken; those really are completely unrelated concepts.

[deleted]

Re: Objects, Identity, and Concept-formation (2008)

#36

The term "object-oriented" was coined by Alan Kay, and he did provide a much more precise meaning. Unfortunately, the term became a fad and was then diluted into all sorts of vaguely related ideas. http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented I find the original idea deep and worth thinking about.

Kay's concept survives if you substitute "function call" for "message". Sending a message to an object and receiving a reply is closely analogous to invoking a function and obtaining a return value. Unfortunately, his overall model implies single dispatch. Sure, "everything is an object", but only one thing is the leftmost argument: the thing that receives the message; and the other things are just arguments.

Wow, just no. Sending a message to an object is more like calling your mom. Applying a function is like...applying a function. There is no real analogue for that, it's just math.

Re: Objects, Identity, and Concept-formation (2008)

#38

Earlier quoted context omitted.

Kay's concept survives if you substitute "function call" for "message". Sending a message to an object and receiving a reply is closely analogous to invoking a function and obtaining a return value. Unfortunately, his overall model implies single dispatch. Sure, "everything is an object", but only one thing is the leftmost argument: the thing that receives the message; and the other things are just arguments.

Wow, just no. Sending a message to an object is more like calling your mom. Applying a function is like...applying a function. There is no real analogue for that, it's just math.

It seems you need more time to think about it.

Message passing can be synchronous, and function calls asynchronous

Also consider remote procedure calls.

Re: Objects, Identity, and Concept-formation (2008)

#39

Earlier quoted context omitted.

Wow, just no. Sending a message to an object is more like calling your mom. Applying a function is like...applying a function. There is no real analogue for that, it's just math.

It seems you need more time to think about it. Message passing can be synchronous, and function calls asynchronous Also consider remote procedure calls.

A function is well defined in mathematics; see http://en.wikipedia.org/wiki/Function_(mathematics) . Note that the definition doesn't really differ for computer science. Procedures, on the other hand, may or may not be functions according to whether they behave like them (match their properties).
Post reply on HN