Brad Cox: when OOP was about “Software-ICs” and micro-transactions

https://deprogrammaticaipsum.com/2019/12/02/brad-cox/

by kemenaran • 7 years ago

91 76 7 years ago

deprogrammaticaipsum.com

ChrisSD2• 7 years ago

It's a shame that, in the minds of many, OOP has come to mean only:

* chuck everything vaguely related in a class

* share code by using inheritance

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.

solipsism2• 7 years ago

If you care about this, my advice is to not rail against words taking on new meanings. That's how language works, and it's a losing battle to fight against it.

Just take what you believe is the better definition of OOP and rebrand it.

AlchemistCamp• 7 years ago

That's how language works, and it's a losing battle to fight against it.

The very name of this site is a powerful argument to the contrary. Slashdotters initially dissed it, saying the word "hacker" (as in coder or builder as opposed to criminal) should be retired. Now the older sense of the word is widespread enough that people halfway around the world are aware of hackers in the sense that PG named this forum. Indie Hackers is only further cementing the reversal of the trend that once appeared inevitable.

MaxBarraclough3• 7 years ago

many programmers now don't consider languages to be OOP unless they have the class keyword and inheritance.

If a language doesn't support inheritance, in what sense is it an object-oriented programming language?

It's true that you can use OOP principles in languages that don't have language-level support for OOP. The canonical example of this is the GObject library for C. That doesn't tell us how we should use the term object-oriented programming language though. I don't see why we'd use a more expansive definition.

magicalhippo• 7 years ago

Thinking off the top of my head, how about a language that only had interfaces (ala COM)? Implemented by non-inheritable objects, using delegation instead of inheritance to share code.

I imagine some syntax sugar to help with the delegation to make it less cumbersome.

hhas01• 7 years ago

Self doesn’t have classes or inheritance, and it’s as [single-dispatch] OO as they come.

(Certainly moreso than something like C++, which wouldn’t look out of place on a Melanesian island. Never could figure why C++ and all its typed kin would choose to dispatch [dynamically] on only one argument instead of on all. Playing to their weaknesses, no?)

int_19h• 7 years ago

In every sense. Prototype-based OO has been a thing for a long time now.

If you look at the entire breadth of OO languages and see what they have in common, there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional.

pmontra• 7 years ago

Sending a message to an Erlang / Elixir process to change its internal status (a GenServer) is not conceptually different than calling a method of an object.

The big difference I see between Elixir and (example) Java or Ruby is that everything is an object in those languages but a big Elixir application has only a few GenServers, where keeping a state matters. Everything else is passed as argument, which by the way it's what a GenServer does internally with an endless tail recursion.

discreteevent• 7 years ago

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.

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)

r00fus• 7 years ago

I think the concept of software "parts" (similar to the auto industry - many of the components are made by 3rd parties) is only tangentially related to object oriented programming.

There were always APIs but they're still parts with an exposed interface - now just distributed over the Internet "as a service".

imglorp• 7 years ago

I think we have succeeded at software IC's beyond our wildest dreams at the time: standard, third party components with mostly understood behaviors, documents, and catalogs to obtain them.

Almost everything except C has web loadable modules and online docs (analogous to IC data sheets in retrospect!) at this point, whether it's Perl's CPAN (going back to 1995) or Gems or MVN or whatever through obvious L-Pad disasters and now containers and various Hubs.

edit. What we didn't dream of when the Byte Smalltalk issue came out (should NOT have tossed mine :-) was the implications of networked module repos. Add one or two lines of code and the system goes out and gets a standard module and wires it in for you. This was not on the menu for people shopping for 74xx at Radio Shack and Digikey.

chadcmulligan• 7 years ago

This was the book that defined components https://smile.amazon.com/Component-Software-Beyond-Object-Or... At the time components were going to be the next level above objects - they were the black box that contained a lot of objects and provided a nice programmer interface. Unfortunately the ideas seem to have disappeared, Delphi is an even better example of a component model than VB was imho.

ilovecaching• 7 years ago

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.

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).

fiddlerwoaroof2• 7 years ago

In a dynamically-typed message-passing system, inheritance is just automatically delegating messages to another actor and possibly modifying the results. Erlang may not have explicit inheritance, but people almost certainly implement inheritance-like actor structures to achieve extensible message dispatch.

zozbot234• 7 years ago

inheritance is just automatically delegating messages to another actor and possibly modifying the results.

I don't think this is true. Objects can message themselves as part of base-class code; implementation inheritance means that this has to involve a level of indirection and dispatch, not just explicit delegation.

xscott8• 7 years ago

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).

They definitely distance themselves from inheritance. However both Rust traits and Go interfaces look to me like they're there to appease people who like the .method() calling syntax. (I know there's more to the story than that, particularly for Rust and its type system...) I think either could've gone with multimethods or overloaded functions and have been better for it, but a lot of people seem to really like the object.method() look.

cgrealy• 7 years ago

a lot of people seem to really like the object.method() look.

There’s a pretty simple reason for that: autocomplete.

In most halfway decent dev environments, typing “object.” will present you with a list of possible operations on that object. OTOH, if you want to do “method(object)” you need to know the method name (in all current scopes, including globals).

I’m not saying this is the only or even best way to write code, but it’s definitely a factor IMHO.

pjmlp• 7 years ago

Go and Rust OOP view of the world are also possible in C++, Java, Python, C#.

It is a matter of actually learning about OOP concepts in general, and Kant features in particular.

Swift's protocol oriented programming actually goes back to Objective-C protocols, Java's inspiration for interface types or Smalltalk traits (post-Smalltalk-80).

bernawil2• 7 years ago

completely wrong and ruined our perception of OOP.

or maybe Erlang is its own thing and OOP -as what most people are thinking when talking about it- is the set of practices followed in languages descended from the cross between C and Smalltalk.

This explains how every introductory course in OOP using either Java, C#, Python, etc. will list some sort of OOP principles always including something along "objects talk to each other though message passing" which is hand-waved simply as something to do with taking other objects by ref

  // taking a reference
  bar.someMethod(foo)

Or some form of import method

  import Foo;
  
  class Bar {
    someMethod() {
       // init the import
       foo = new Foo() 
       // ... do something with it
       foo.someMethod()
    } 
  }

which is worse since you need a huge disclaimer to explain that in practice you need to account for Dependency Injection and something for Mocking.

protomyth2• 7 years ago

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.

1) Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean

DonHopkins5• 7 years ago

Nice book, but it's too bad David Gelernter's brain went bad.

https://www.washingtonpost.com/news/speaking-of-science/wp/2...

protomyth2• 7 years ago

Given the false reporting done by the Washington Post on the Covington kids when they had video of the incident, I place no value in their reporting. Thanks for dragging politics into this discussion.

jasim2• 7 years ago

Two interesting ideas that helped me get insight into OO:

1) An object is a poor man's closure; and a closure is a poor man's object.

2) Most object-oriented programming is done with mutable state, which muddles what OO is. You don't really need state to have objects.

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: https://stackoverflow.com/a/2498010

When objects are immutable, one gets to truly appreciate the elegance of grouping both data and their functions together: https://dev.realworldocaml.org/objects.html#scrollNav-3

tudelo5• 7 years ago

RE 2 do you mean you don't need to have mutable state to have objects? Unless I have a huge misunderstanding of what you mean by 'state', it seems like state is necessary for objects to exist..

lelandbatey• 7 years ago

I think the grandparent comment is saying that you do not need your state to be mutable; that writing software where your state is immutable is useful and elegant.

derblitzmann• 7 years ago

One book[1] I read explained this in detail, amongst other similar concepts. It was really interesting and helped me think of how functional concepts could work in OOP languages.

1: https://www.elegantobjects.org/

abecedarius2• 7 years ago

You don't. See http://wcook.blogspot.com/2012/07/proposal-for-simplified-mo... by William Cook. However, objects help to tame mutable state.

quelltext3• 7 years ago

I think "state" is simply an overloaded term and that causes misunderstandings here. I believe by "state" GP meant specifically mutable state on the level of the programming language abstraction.

"Having state" often implies mutability, i.e. to be in a given state means the same thing can be in different states/configurations as well.

On the other hand people often also use the word "state" to refer simply to a "current state" of something at a given time, and then under this interpretation there is state in immutable objects.

As you already know, "representing (real world) state at some step/time" does not require mutability on the language level. These immutable objects are state snaphots of a hypothetical mutable object. Operations on them cannot mutate them, but instead derive a new snaphot that represents the new state at a given time after the operation. So working with those snapshot does represent state and state changes and models real world state, but the individual snaphots/immutable objects cannot be mutated.

Whether those immutable objects deserve the monicker "object", I don't really have a opinion on, but I wouldn't outright deny it.

Are they useful in similar ways that mutable objects are? I'd say so.

Immutable objects can still get you polymorphism/subtyping and encapsulation, features often ascribed to object oriented programming.

bernawil2• 7 years ago

"Objects" in OOP, as in "let's couple data with behavior" necessarily means mutable state, otherwise they are just types. Use only immutable data; write abstract classes only; do polymorphism with interfaces and you'll end up with something very similar to what people mean by 'type-level programming' in Haskell.

mhd• 7 years ago

I don't think this is a failure of OOP itself, nor does it come down to any language's shortcomings.

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 see on the desktop, the atomic unit of software is huge and perceptible.

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)

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.

So we ended up with fast food joints and black-box-systems, no ICs, condiments, recipes etc.

Open Source could've been an answer/alternative, but the OSS world mostly copies stuff from the programmer's day jobs.

(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)

travisgriggs• 7 years ago

Veteran Smalltalker-turned-modern-iot-embedded-polyglot here.

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."

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).

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.

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.

RossBencina• 7 years ago

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.)

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.

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".

Brad Cox: when OOP was about “Software-ICs” and micro-transactions

Related Stories