He references the Byte magazine Smalltalk issue. There was another issue much later that looked at why objects failed but actually they didn't. They succeeded but they weren't called objects. They were called Visual Basic controls/components. These were a runaway success. VB despite it's limitations enabled a massive amount of software to be written quickly and easily mainly through re-using commercial components.<p>But the components were completely encapsulated. Black box, no source code, no inheritance. You could argue the same for services today. Services are software ICs, you can call them objects it whatever you like but they achieve Brad Cox's objective, which is all that matters. (It's just a pity that people think that a service/component has to run in a separate process always, unlike VB)
It's a shame that, in the minds of many, OOP has come to mean only:<p>* chuck everything vaguely related in a class<p>* share code by using inheritance<p>IMHO, the way Java and C++ have been taught (in practice, if not by teachers) has done a disservice to OOP. So much so that many programmers now don't consider languages to be OOP unless they have the class keyword and inheritance.
If you want to really see OOP in action study Erlang. As the late great Joe Armstrong says in his introductory book, Erlang is a real OOP system - objects can only communicate through message passing. There is no notion of visibility, friendship, inheritance, etc. Objects can hold state and pass messages and that's it - which coincidentally makes concurrency dead simple.<p>What most people think of when they think OOP is C++, Java, and Python which got OOP completely wrong and ruined our perception of OOP. They also tried to use their misshapen OOP hammer on every problem they could find to the point that it’s an overused meme. These days you see languages actively trying to distance themselves from OOP as a form of enticement (Rust and Go being the two prime examples).
Veteran Smalltalker-turned-modern-iot-embedded-polyglot here.<p>OOP is a difficult to judge because it became such a big envelope. Alan Kay famously said in 1997 "I invented the term Object Oriented Programming, and this [C++ and Java] is not what I had in mind."<p>He would later even tell the Smalltalk community that even that wasn't spot on, only an early step, to what he was really after in his visionary's quest that would create a DynaBook that would increase world peace (visionaries always reach big).<p>In my own journeys, my own personal conviction came to be that the "paradigm shift" with the OO movement was to learn to bind behavior to data. This (IMO) fits Kay's ideas about cellular biology and the inspiration he embraced with his ideas. It's all about binding behavior to data.<p>Everyone should read that byte magazine (because apparently 500+ pages was a magazine), especially Peter Deutsch's section on block closures. Smalltalk did more with closures than any other language I've used since. Because closures are objects too.
Superdistribution was a pretty good book. I guess we went a really different direction after the Visual Basic component years. I keep coming back to Superdistribution, Visual Basic components (VBX/OCX), and the concepts from Mirror Worlds[1] (tuples spaces) and wonder if there is still some paths to look at down those roads.<p>1) Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean
This article was an excellent read. Like other commenters, it reminded me of Clemens Szyperski's "Component Software" book. While a component model of software production has succeeded in some niches, it has (so far) failed to become a central organising principle for large scale software production. The article suggests that new micropayment mechanisms such as blockchain might enable Brad Cox's vision of pay-as-you-use software components. But I think this misses the point. I would argue that software differs from physical goods in important ways that make it a poor fit for this model. In particular, software is cheap to modify, evolve and customise, but expensive to specify independent of implementation (cf. Refactoring, Agile processes versus ISO Standards Development.)<p>One issue that Szyperski's book examined was the composition model (i.e. object model: COM, CORBA, JavaBeans, etc) used for defining interfaces between software components and how those interfaces can be composed. The idea of standardizing interfaces and composition mechanisms does not get so much attention today. It seems that things are currently balkanized into language communities, each doing their own thing.<p>The industrial manufacturing concept of "interchangeable components" comprises of two things: (1) standardized specifications, (2) multiple independent manufacturers who are able to independently implement specifications. We do have this kind of practice in, for example, the specification and implementation of the C++ standard library. But that's not how most software is developed, and it is commonly held that it is not how most software should be developed. On the other hand, we do have "component reuse" in the form of software libraries -- but the interfaces are unique and idiosyncratic to each library, not standardised, and there is usually a single "manufacturer".
I don't think this is a failure of OOP itself, nor does it come down to any language's shortcomings.<p>I think it's mostly a market failure. The units of trade were complete software products and/or services/apps these days. Mostly because that's what the end users actually <i>see</i> on the desktop, the atomic unit of software is huge and perceptible.<p>Once upon a time, it looked like it could be different. Component-oriented systems arose. COM, CORBA, CommonPoint, Taligent, D'OLE etc.
(Heck, one might even argue for Amiga filetypes and embedded X windows to belong in the same category)<p>But apart from UI Widgets (ie. windows controls for VS or Delphi), it never seemed like there was a marketplace for it. It also was quite hard to sell to managers, as it's something you can't put in a box or have a big trademark for it.<p>So we ended up with fast food joints and black-box-systems, no ICs, condiments, recipes etc.<p>Open Source could've been an answer/alternative, but the OSS world mostly copies stuff from the programmer's day jobs.<p>(Gnome actually started out with CORBA and KDE had some component structure, too, but that doesn't appear to be anyone's focus, compared to copying notifications and doing flat redesigns)
Two interesting ideas that helped me get insight into OO:<p>1) An object is a poor man's closure; and a closure is a poor man's object.<p>2) Most object-oriented programming is done with mutable state, which muddles what OO is. You don't really need state to have objects.<p>In a closure, the lexical scope is preserved, and the functions defined in it can access it any time. This is very similar to what an object does: <a href="https://stackoverflow.com/a/2498010" rel="nofollow">https://stackoverflow.com/a/2498010</a><p>When objects are immutable, one gets to truly appreciate the elegance of grouping both data and their functions together: <a href="https://dev.realworldocaml.org/objects.html#scrollNav-3" rel="nofollow">https://dev.realworldocaml.org/objects.html#scrollNav-3</a>