Live data from Hacker News

The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

cs.cmu.edu

21–30 of 45 posts

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#21
post #15

Earlier quoted context omitted.

Jonathan aldrich does come from the UW side of PL, which leans toward objects (a bias I share as well). But he knows his FP. Still, I'm not much for arguments by authority; either you see a proper comparison in the paper or not (I haven't looked closely enough). What both William and Jonathan both seem to miss, however, is more a discussion on object thinking, which I think would make the difference between OOP and f…

I don't think this is really an argument from authority since I'm not saying 'he's right because he has a PhD and teaches at a renowned university'. I'm saying that assuming he's ignorant of FP given both what he says in the paper and his background is silly and shallow. It's not really fair to say that Aldrich 'misses' a discussion of object thinking, he just chooses to put the focus of that particular paper elsewhe…

Everyone reads these papers from different perspectives, so it's quite easy to say someone missed something (fair or not).

My criticism is that an analysis of OOP is incomplete if you avoid looking at...objects. It's like saying, we are going to ignore the objects themselves, and just focus on the technical features of the objects to see what the technical advantage of these features are. It is very reductionist...while objects favor a more holistic manner of thinking.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#22
post #19

Earlier quoted context omitted.

Jonathan aldrich does come from the UW side of PL, which leans toward objects (a bias I share as well). But he knows his FP. Still, I'm not much for arguments by authority; either you see a proper comparison in the paper or not (I haven't looked closely enough). What both William and Jonathan both seem to miss, however, is more a discussion on object thinking, which I think would make the difference between OOP and f…

Given the difference in both OOP and FP, I agree it certainly would be an interesting contrast to explore. Especially now, as FP is becoming more mainstream.

I really need to sit down and write that essay, but I always have better things to write and design essays are difficult to sell. A lot of the FP programming that goes on is just weak OOP with some immutability, closures, and list comprehensions. The real hardcore FP avoids not only mutation, but also aliases and identifiable objects. Object thinking is impossible in that context because nothing can have a name (beyond rolling your own GUIDs); it really is different.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#23
post #7

Earlier quoted context omitted.

Didnt we just move beyond scribd?

Sorry, I don't understand what you mean. I'm not suggesting scribd... Google cache is not scribd; it's plain html and not heavy javascript. I only referenced scribd as an additional link automatically added that had been done before, so it's not a biggie implementation-wise (maybe the old code is even still there), although I wouldn't expect it to be difficult anyway. There wouldn't even need to be a check for if goo…

PDFs are not really meant to be converted into HTML. The converted formatting would suck, especially for the double column ACM format used.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#24
post #20

This was 2013 and he never heard of the CLOS arguments against traditional objects as he describes it, and he attributes Alan Kay with generics and method based OO dispatch, the functional approach? All these arguments were already cleared in the early 1990's, and people still don't get it. CS scholar's shouldn't care about the popularity of certain languages, or do they wanna teach VB or PHP? Objects are of course e…

  Objects are a poor man's closures.
  Closures are a poor man's objects.
  -- Guy Steele

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#25
post #6

The author is accidentally promoting functional programming, without realizing it. He emphasizes "interoperable extensions" and "service abstractions" but what he's really describing are functional type signatures and interfaces. His writes: "I now propose a candidate for the leverage provided by object-oriented service abstractions in design: The key design leverage provided by objects is the ability to define nontr…

Given the definition of 'object' used, things like modules, namespaces and first class functions can be (in some languages: are) objects

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#26
post #15

Earlier quoted context omitted.

I don't think this is really an argument from authority since I'm not saying 'he's right because he has a PhD and teaches at a renowned university'. I'm saying that assuming he's ignorant of FP given both what he says in the paper and his background is silly and shallow. It's not really fair to say that Aldrich 'misses' a discussion of object thinking, he just chooses to put the focus of that particular paper elsewhe…

Everyone reads these papers from different perspectives, so it's quite easy to say someone missed something (fair or not). My criticism is that an analysis of OOP is incomplete if you avoid looking at...objects. It's like saying, we are going to ignore the objects themselves, and just focus on the technical features of the objects to see what the technical advantage of these features are. It is very reductionist...wh…

We probably (broadly) agree more than disagree. One reason FP/OOP comparisons are difficult is that FP is closely related to a mathematical formalism while OOP isn't and can't be. I think the tack he's taking is 'can we explain the popularity of OOP in terms of "technical" or really, "practical programming/software engineering" advantages'. It's a tricky needle eye to thread.

The objection 'that approach can't lead to useful insight' is a reasonable one but I don't think he's taking the approach out of ignorance or because he spaced out on something while typing it up - it's a deliberate choice, whatever its merits.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#27
Reading about this stuff reminds me of watching a grass fire: there's a huge amount of smoke and activity going on, but I'm really not sure where the flames are -- or if it should concern me.

Working with Ocaml and F# over the past few years, in small and smallish medium-sized systems, I've been fortunate to have an environment where I can use any paradigm I want in a natural setting. And while I've gone from an OO-diehard to an FP fan during that time, I haven't given up on objects.

I think systems "mature into" objects. I do not believe they should start with them. (Which is completely opposite of what I thought several years ago) Functionality gets created, tested in various scenarios, and then -- and only after a good amount of exercising by various other systems -- does it get grouped into ADTs, objects, or whatnot.

Note that I am describing how these things are created, not what they are. For practical purposes I could care less whether this chunk of bytes is exposing a service or providing a type. Of much more immediate concern is why should it be in this shape? I think if you start functionally, you are free to let the problem domain determine the shape of the mature code. Whereas if you start with some kind of preconceived notions of where you're ending up and why, you're making assumptions about the optimized solution that may have no justification.

tl;dr -- you're asking the wrong question.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#28
post #10
post #3

html version http://webcache.googleusercontent.com/search?q=cache%3Ahttp%... I'd almost forgotten this trick, just google cache: http://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf request: could HN do this automatically pls? (similar to how it used to provide a second link to scribd for pdf) I always prefer a html version, to assess it. If it's interesting, and diagrams/formulae are garbled, I can always get the…

PDFs render inline wonderfully for me in both browsers I use without plugins.

I'm on a phone (but maybe that would be fast enough... I'm using stock: no plugins)

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#29
post #7

Earlier quoted context omitted.

Sorry, I don't understand what you mean. I'm not suggesting scribd... Google cache is not scribd; it's plain html and not heavy javascript. I only referenced scribd as an additional link automatically added that had been done before, so it's not a biggie implementation-wise (maybe the old code is even still there), although I wouldn't expect it to be difficult anyway. There wouldn't even need to be a check for if goo…

PDFs are not really meant to be converted into HTML. The converted formatting would suck, especially for the double column ACM format used.

Have a look at my link above. It's surprisingly good.

Re: The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

#30
post #29

Earlier quoted context omitted.

PDFs are not really meant to be converted into HTML. The converted formatting would suck, especially for the double column ACM format used.

Have a look at my link above. It's surprisingly good.

Google webcache in china? My vpn isn't working.
Post reply on HN