3 ms·

IIRC, Alan Kay says OO is message passing, encapsulation, and extreme late binding. In java: * message passing is virtual method invocation * encapsulation is

by sreque 6y ago

IIRC, Alan Kay says OO is message passing, encapsulation, and extreme late binding. In java: * message passing is virtual method invocation * encapsulation is through public vs private members * late binding is through the JVM dynamic linking system. While Alan Kay may have had something much more flexible like Smalltalk in mind, I believe the Java OO system meets the spirit of OO well enough and makes certain tradeoffs for good reasons.

dllthomas 6y ago
Virtual method invocation is already "late binding" in quite a few contexts, although dynamic linking certainly takes it further.
andrekandre 6y ago
> message passing is virtual method invocation a virual method call is definitely not a message[1] [1] https://davedelong.tumblr.com/post/58428190187/an-observation-on-objective-c https://davedelong.tumblr.com/post/58428190187/an-observatio...
- sreque 6y ago
  Method calls and virtual method calls are not the same thing.
mumblemumble 6y ago
Alan Kay was also fairly specific about what he meant by encapsulation, and it's not just making things private. For example, he wrote, "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." And, later in the same paper, "Human programmers aren't Turing machines—and the less their programming systems require Turing machine techniques the better." Java's programming culture tends to favor a shallower approach to OOP that cleaves very closely to the fiddly, imperative, state manipulation-oriented approach that is emblematic of procedural programming. A great example of this is Java 8's streams API. There's absolutely no way to evaluate a stream without introducing a state change that will alter its behavior. Which means that, unlike for almost any other comparable API in another language, you can't safely pass around and share instances of Stream for fear that someone might break it on you. It's the shallowest possible interpretation of the abstraction in question, and making it that way was a deliberate decision that motivated by the tacit understanding that Java programmers have a fundamentally procedural way of thinking about the world, and would be confused by something that was truly declarative. The only other language I'm familiar with that takes the same approach is another popular "procedural programming with objects" language, Python. This isn't to say that people can't do principled object-oriented programming in Java. Just that few people do. In part because, if you try, you'll end up constantly picking fights with the JDK. Not entirely unlike how you can do principled functional programming in Java, but it's an uphill struggle.
- sreque 6y ago
  That statement is neat but it looks to have little to do with programming and more to do with programming style. What about Smalltalk, the language, for instance, helps you "eliminate state oriented metaphors" any better than any other programming language?

by sreque 6y ago

dllthomas 6y ago

Virtual method invocation is already "late binding" in quite a few contexts, although dynamic linking certainly takes it further.

andrekandre 6y ago

> message passing is virtual method invocation a virual method call is definitely not a message[1] [1] https://davedelong.tumblr.com/post/58428190187/an-observation-on-objective-c https://davedelong.tumblr.com/post/58428190187/an-observatio...

sreque 6y ago
Method calls and virtual method calls are not the same thing.

mumblemumble 6y ago

Alan Kay was also fairly specific about what he meant by encapsulation, and it's not just making things private. For example, he wrote, "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." And, later in the same paper, "Human programmers aren't Turing machines—and the less their programming systems require Turing machine techniques the better." Java's programming culture tends to favor a shallower approach to OOP that cleaves very closely to the fiddly, imperative, state manipulation-oriented approach that is emblematic of procedural programming. A great example of this is Java 8's streams API. There's absolutely no way to evaluate a stream without introducing a state change that will alter its behavior. Which means that, unlike for almost any other comparable API in another language, you can't safely pass around and share instances of Stream for fear that someone might break it on you. It's the shallowest possible interpretation of the abstraction in question, and making it that way was a deliberate decision that motivated by the tacit understanding that Java programmers have a fundamentally procedural way of thinking about the world, and would be confused by something that was truly declarative. The only other language I'm familiar with that takes the same approach is another popular "procedural programming with objects" language, Python. This isn't to say that people can't do principled object-oriented programming in Java. Just that few people do. In part because, if you try, you'll end up constantly picking fights with the JDK. Not entirely unlike how you can do principled functional programming in Java, but it's an uphill struggle.

sreque 6y ago
That statement is neat but it looks to have little to do with programming and more to do with programming style. What about Smalltalk, the language, for instance, helps you "eliminate state oriented metaphors" any better than any other programming language?