5 ms·

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 j

• latch 7y ago
  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.
  • kstenerud 7y ago
    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 this would require all calling components to micro-manage anything they're calling, to make sure things actually get done...
    • megous 7y ago
      Message sending function can block until timeout or response is received.
      • tomaskafka 7y ago
        How is timeout and sending message without knowing how it was handled different?
        • megous 7y ago
          Have you programmed anything on the web? fetch() has interface just like that.
    • tybit 7y ago
      I like pub sub for sending events(where the sender doesn’t expect any responses). I dislike it for modelling RPC which is what you seem to be referring to.
    • rswail 7y ago
      If I'm the service that needs a payment, then it is up to me to make sure it happens. If it doesn't, then I need to deal with that, because that's something that can happen with a payment. So if I don't hear from the payment that it has been initiated, then I have to go on the basis that I can't get a payment. But I also don't get to tell the payment how to deal with its internal activities, I don't want to know about it retrying, or working out which payment provider to use etc. Objects arent FiniteStateMachineManagerFactories. They're actual things that your system is built to handle. If an object needs an FSM, it'll get one, just like cells have mitochondria.
    • zeugmasyllepsis 7y ago
      > It seems like a messaging system like this would require all calling components to micro-manage... I think that's part of the trick, actually. When every component of a system behaves in similar ways, it's easier to extract that behavior into re-usable patterns. Rather than each component worrying about handling failure and micromanagement, that job is delegated to an another component, a supervisor or orchestrator. Supervision trees, automatic service discovery, and elastic resource managers all come to mind. What payment systems don't send messages to communicate with the credit card company, or the eCheck service, or Venmo/PayPal/Apple pay? Websites and native apps alike have spinning graphics and loading bars, messages that say "please don't refresh the page while we do this". These systems are fundamentally asynchronous to begin with. By uniformly applying the practices you get consistency, in exchange for a higher low-bar of complexity (which you're likely to exceed anyway).
• ngcc_hk 7y ago
  All apple software use objective c and seems fine. Run time checking is not unreal. Internet run on that. Ethernet run on that. Too much error correction like sna and token ring make the network brittle. You think you help error handling but by enforcing failure you have not decouple the “objects”. By assuming type and minor change the whole thing collapse on you. It is between ibm network and internet. Or osi vs ietf.
  • mpweiher 7y ago
    > objc - fine People forget this, particularly the ones who claim "this can't possibly work". If that's your position, you are simply wrong. Now which works better in what ways is something we can talk about. > Internet This is another big one people seem to not think about. Kay was thinking about scaling up, or rather about taking an idea that can scale up and then scaling it down. The internet and the WWW clearly demonstrate that you must late-bind. In fact, Allen Wirfs-Brock noted how the Internet is a lot like a huge distributed Smalltalk image: it runs all the time, it's late-bound, it's very stateful and you can't take it down and restart it from scratch.
• cygx 7y ago
  Rapid prototyping and hot-patching running systems come to mind. Note that traditionally, Smalltalk environments are modified at run-time and dumped to images for deployment.
• vidarh 7y ago
  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 recipient want to exchange. Returning errors by default is reasonable, as long as you can override that when it makes sense.
  • adwn 7y ago
    That sounds great for a quick & dirty prototype, or for debugging and testing. But it would be an absolute nightmare for building and maintaining large-scale projects.
    • infinite8s 7y ago
      You mean like the internet?
      • adwn 7y ago
        The Internet as a whole [1] is not designed or maintained – it evolves. [1] As opposed to its components (infrastructure, protocols, individual websites), which are designed and maintained, and which would in general be a nightmare to design and maintain if they followed the principles described by vidarh.
        • vidarh 7y ago
          Their point is that a lot of the underpinnings of the internet are based on not assuming safe delivery, nor assuming the sender will get things right, and generally accepting that if you want to interoperate reliably you will have a very hard time if you assume everything works perfectly. But taking it a point further: A huge amount of large websites are built on languages with this level of dynamic features, and often take advantage of it heavily. Every site that uses Rails for example (or any Ruby framework) will likely heavily rely on runtime introspection of the database to dynamically generate parts of the ORM apis. I'm right now working on a Ruby application where I went a step further and axed a large chunk of semi-manual API writing by writing a few small components that dynamically generates most of the API at runtime from small pieces of metadata and the actual state of the database. A large chunk of the userinterface is similarly dynamically generated from data dynamically generated by the dynamically generated backend API. There is no way we could deliver what we deliver with the kind of size team we're using if we could not rely on introspection and dynamic features like this to generate most things.
• meheleventyone 7y ago
  You step into the call and see what the object did with the message. In Smalltalk if a message cannot be dispatched to an object or it's inheritance hierarchy and there is no custom handling then I believe it errors or pops open the debugger for you.
• slifin 7y ago
  Not that I'm advocating the approach but I think the benefit is that if your recipient is out of action then your callee survives 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-here-some-of-the-reasons-why-he-chose-not-to-use-the-actor-model-in-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
  • DSingularity 7y ago
    Why better without async? You feel the same about std::async?
    • TFortunato 7y ago
      As parent mentioned, there is overhead to using async: both in actual execution (e.g. likely spinning up another thread, plus creating a future object) and cognitively (in terms of following control flow, and knowing when exactly things are happening). It's not that it isn't great when you do need it, but there are also plenty of cases where you don't need it and it's just unnecessary overhead.
• mirsadm 7y ago
  In my experience silent failure leads to some of most difficult to debug systems that end up in a not quite right state. Fail as early as possible has always worked better for me, bugs are found much earlier.
  • mpweiher 7y ago
    Things are different in-the-small vs. in-the-large. You can't statically typecheck the internet. Oh, and no-one said the failure needs to be silent.
    • dwd 7y ago
      Totally agree failure should be announced for another object to observe and decide to do something about. I didn't feel the author got the messaging part. 'You send some data to an object' kind of misses the point. Going back to Kay's inspiration in cellular function the messaging is more a broadcast, though proximity matters as far as which other cell responds (Internet routing tables are a good approximation but you need something more dynamic to allow objects to be created and destroyed).
• eternalban 7y ago
  Have successfully completed tasks call home to mama. No call no work. Easy. Alan Kay and fellow minded et al. are looking at Biology and to an extent Physics as the successful approach to pervasive computation at large. It is the desirable feature set of the biological organism that informs that perspective: self-healing, self-regulating, regenerative systems operating in an open-ended operational context. So that is the holy grail. Or at least one of them. Clearly biological systems can do all that. Can we do this with software? That's what Alan Kay wants us to find out.
  • kstenerud 7y ago
    Biological systems do that because they evolve. Interactions between independent systems happen due to chance changes in some of them. But the nature of the interaction is not something controlled. Switch one bit of a genetic code and a whole bunch of behaviors change (the ultimate in side effects). This is the anti-Dijkstra; a system that cannot be fully reasoned about. What we're seeing in "successful" biological systems is survivorship bias. They are useful because the system they operate in happens to be such that their function is useful to the system (they are in a temporary equilibrium). And that system is not under anyone's control, nor can it be, because every tiny change in one component, or the environment they operate in, alters that equilibrium in ways we can't predict. But there's no controlling entity pushing biology towards a particular function, so this doesn't matter in nature. A computer system modeled after this would be by nature difficult to fathom and brittle to change.
    • zubairq 7y ago
      Yes so true
    • eternalban 7y ago
      I was not discussing fitness. Even unfit organisms are constituted according to the same organic order as the fit specimen.
• jackcviers3 7y ago
  You aren't. You don't have a "program." You have millions of tiny isolated processes that can send messages to one another. Since you cannot observe the state of any process from the outside, and cannot tell if it has failed or not, you have to rely on other things (think tcp/network protocols) to indicate message reception and processing. You can reason about your protocols, as they have an algorithm. But your object graph as an entire entity is a bunch of black boxes with very few observable properties about which to reason, or indeed even need to in the world of isolation.
• walterstucco 7y ago
  Tracing. BTW that's how Erlang works and it's much easier to debug than many other languages I used Tooling is important