11–20 of 141 posts
I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?
I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?
Sometimes just ignoring certain messages is fine: You might slot in an object as a sink to log certain messages and not care about others. Other times you want to be able to do things like delegate certain subsets of messages to other objects without having to know the precise set of messages in the sender or ultimate recipient want to exchange.
Returning errors by default is reasonable, as long as you can override that when it makes sense.
Earlier quoted context omitted.
Sending messages asychronously and not knowing who (or even if anyone) will handle it is pretty desirable. Like a holy grail of writing maintainable software. (think of async communication via a queue) Isn't always possible, but it's worth the constant vigilance to drive each feature towards that type of architecture.
OK, I must be missing something fundamental, then. Let's say you want to take payment and ship a product. You send a message that payment of X is needed. And... nothing happens because the component that handles that isn't listening for whatever reason. Do you wait for a message saying payment was posted? How long do you wait? What about the UI? How long does the customer wait? It seems like a messaging system like t…
I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?
That is not the point. The point is having the ability to fully control how to react to a message. Sometimes just ignoring certain messages is fine: You might slot in an object as a sink to log certain messages and not care about others. Other times you want to be able to do things like delegate certain subsets of messages to other objects without having to know the precise set of messages in the sender or ultimate r…
I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?
I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?
In a typical Simula I program (C++ Java PHP C# etc) if you fatal in your recipient's object your callee and the entire program is going to come crashing down, in something like erlang the callee can keep going
Before jumping to putting everything on a queue, there are downsides like you've identified which is why there's this comment from Rich Hickey on the erlang variant of Clojure: https://github.com/clojerl/clojerl#but-but-rich-hickey-lists...
Essentially, it's good when you need it but an overhead when you don't, kind of like async in my mind, use it when you absolutely need it, but otherwise, you'd be better operating without it
Earlier quoted context omitted.
Sending messages asychronously and not knowing who (or even if anyone) will handle it is pretty desirable. Like a holy grail of writing maintainable software. (think of async communication via a queue) Isn't always possible, but it's worth the constant vigilance to drive each feature towards that type of architecture.
OK, I must be missing something fundamental, then. Let's say you want to take payment and ship a product. You send a message that payment of X is needed. And... nothing happens because the component that handles that isn't listening for whatever reason. Do you wait for a message saying payment was posted? How long do you wait? What about the UI? How long does the customer wait? It seems like a messaging system like t…
I dislike it for modelling RPC which is what you seem to be referring to.
Here's my pet theory on why Kay's vision for OOP didn't win in the marketplace of ideas: The software industry achieves "extreme late-binding" via network protocols like TCPIP/HTTP instead of a single programming language's "message bus".
Instead of using the "message bus" of Smalltalk or Objective-C's "objc_msgSend()", the world has decided to express the evolution of software via multiple programming languages and runtimes and by the mechanism of software updates instead of depending on a single language ecosystem like Smalltalk to write a metaphoric cell biology system to evolve itself.
The majority of software we write isn't burned onto a printed circuit board and never ever updated again. An extreme example of an algorithm that's forever engraved in hardware is the computer on the Voyager space probe.[0] Instead of launching a computer out to space and never touching it again, we have the luxury of just updating the software.
If anyone remembers the 1980s online services like Prodigy and Compuserve, they would have scheduled maintenance outages. E.g. they'd send out a notification that "Prodigy will be down for service from Saturday midnight to Sunday at 4am".
But consider today's massive web properties like Amazon.com, Facebook, Google. They run virtually 24/7 with no scheduled maintenance downtimes. How do they do that even though we know they're constantly deploying new software, microservices, etc -- and -- they're not using an extreme-late-binding programming language like Smalltalk? Because they achieve that dynamism at the http network layer instead of the programming language with devops practices such as "continuous deployment".
E.g. The url can be thought of as a "request message" in Kay's parlance. Here's a url that uses Google Translate to convert Russian text to English:
https://translate.google.com/?hl=en&tab=wT0#view=home&op=tra...
Before September 2016, the Google's backend of software responding to that url was linear algebra on a corpus of text. After that, they completely switched out the translation engine to be a deep-learning neural network. The http layer allowed Google to transparently change out an entire backend stack without users being aware of it. There was no publicized "maintenance outage" to swap out the entire language translation engine. Presumably in the future, that same url ("message") will extremely late bind to a different and better translation engine ("receiver object").
Today, we also have constant software auto updates on the desktop and smartphone. How does Chrome/Firefox evolve new features even though they're written in static C++ instead of dynamic Smalltalk? Because the browsers auto-downloads the updates and install them.
[0] https://www.allaboutcircuits.com/uploads/articles/voyager_fd...
I have a ton of respect for Alan Kay and think he's a genius. But why does it seem like every time he talks about OO it's always painting an apocalyptic picture like we're in some kind of twilight zone alternate nightmare reality of broken patterns and models? Surely our concept of objects and OOD can't be that bad, but his apparently contrary outlook is just so persistent...
Yes, it is. Object orientation is probably the worst idea to ever have appeared in computer science, both from a philosophical and practical point of view: it is an unsound principle and it leads to disastrous engineering practices.
We will be mocked mercilessly by our descendants.
