>, he realized that while software routinely has trouble scaling, cells can easily coordinate and scale by a factor of over a trillion, creating some of the mos

>, he realized that while software routinely has trouble scaling, cells can easily coordinate and scale by a factor of over a trillion, creating some of the most fantastically complex things in existence, capable of correcting their own errors. By comparison, the most sophisticated computer software programs are slow, tiny, bugfests. Kay's conception of OOP starts with a single question: how can we get our software to match this scalability? 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=translate&sl=auto&tl=en&text=%D1%81%D1%87%D0%B0%D1%81%D1%82%D0%BB%D0%B8%D0%B2%D1%8B%D0%B5%20%D1%81%D0%B5%D0%BC%D1%8C%D0%B8%20%D0%B2%D1%81%D0%B5%20%D0%BF%D0%BE%D1%85%D0%BE%D0%B6%D0%B8 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_fds_nasa.jpg https://www.allaboutcircuits.com/uploads/articles/voyager_fd...