Wikipedia programming paradigms page

[Matthew Browne]

Hi all,
I'm wondering what the group thinks about adding DCI to the list of
programming paradigms on this page:

https://en.wikipedia.org/wiki/Programming_paradigm

[James Coplien]

You could, and I think it would be worth it, but it would be a lot of work. And you'll take a lot of flack in feedback. In some sense DCI is at a lower level that this article, but given that most practice was confused about OO I can see that DCI is a worthy landmark worth talking about. I can see adding something to the OOP section noting that most of the languages listed are class-based and that Kay’s vision of OO eluded most software practice over the years. Cap it off by saying that a return to true OO has measurable benefits and cite the Valdecantos paper.

> --
> You received this message because you are subscribed to the Google Groups "object-composition" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/object-composition/f6f1c1de-ba57-407b-a2c7-5453dc05984e%40gmail.com.

[Matthew Browne]

Hi Cope et al.,
One of the things I was debating about, if I were to edit the article, is whether DCI should go under imperative or declarative, or in its own category. I think I can answer my own question and say imperative, since all of our current examples are at least mostly imperative, but I have also seen some instances in Rune's examples where certain objects are immutable and a more FP style is used (not that that in itself is the definition of "declarative"), so it makes me wonder. TBH I don't like the hierarchical organization of the paradigms under declarative and imperative, especially given how it's becoming more common to mix paradigms in the same language, and the article itself notes that there has been criticism of this. But obviously I'm not proposing to reorganize the whole article.

Cap it off by saying that a return to true OO has measurable benefits and cite the Valdecantos paper.

Good idea—I should definitely cite that paper.

I'm not sure that I would go so far as to claim that DCI is a full realization of the original OO vision (if that's what you were getting at). It's certainly much more of a realization of it than class-based programming, but as I was researching more about Alan Kay, one of the things I learned is that the original version of Smalltalk allowed you to send truly arbitrary message strings to objects, and the objects had complete freedom to parse and process the messages however they wished. If you wanted to, you could even have an object (or set of objects) that responded to a particular DSL used by that object and not others. In this sense, objects were a bit like what we have now with web services, where services define their APIs, and HTTP and other protocols allows a lot of freedom in the format of the messages that are sent. The conflation of messages and methods came in the next version of Smalltalk, for pragmatic and performance reasons. BTW, I realize that I'm describing a bunch of stuff that you're already familiar with (and I learned it all mostly thanks to references from you), it's just easier to make my point by describing it like this.

I have been looking into Multisynq, formerly known as Croquet. Kay was one of the architects of the original Croquet system, especially the first version written in Smalltalk. The Smalltalk version isn't maintained anymore so I haven't looked into it too deeply (other than skimming through an interesting paper about its architecture), but I believe the core design of Models is essentially the same in the current iteration. In any case, in Multisynq, the "Models" are distributed objects that have a similar flexibility for messaging as what I described above, via a pub-sub approach.

All of this to say that DCI is certainly a lot closer to the original OO vision than other implementations, but I don't think it goes all the way (at least not in its current form...I was experimenting with something DCI-like on top of Multisynq). I also think that that's fine: DCI is super useful for what it's designed to do, and I don't think it necessarily needs to be replaced by something else in that context (i.e. objects within a single app running on a single machine). However, I still think it would be accurate to say that DCI is much better at reflecting mental models than traditional class-based programming (and to me at least, mental models are an even more important cornerstone of OO than "messaging"), and that role methods do offer a lot of flexibility in how objects communicate that isn't possible with just classes.

[Matthew Browne]

Update: I went ahead and updated the programming paradigms article on Wikipedia. I didn't think it was necessary to edit any other parts of the article, so I kept it simple and just added another bullet point under the "object-oriented" category. This is how it looks now:

• Class-based – object-oriented programming in which inheritance is achieved by defining classes of objects, versus the objects themselves
• Object-based - paradigm in which the object has a construct to encapsulate state and behavior.
• Prototype-based – object-oriented programming that avoids classes and implements inheritance via cloning of instances
• Data, Context and Interaction - object-oriented programming where objects take on roles in a given context, as a means for the programmer to orchestrate interactions between objects

If anyone thinks that description isn't quite right or should be improved, let me know.

Thanks,
Matt

[James Coplien]

On 21 Feb 2026, at 14.22, Matthew Browne <mbro...@gmail.com> wrote:

Update: I went ahead and updated the programming paradigms article on Wikipedia. I didn't think it was necessary to edit any other parts of the article, so I kept it simple and just added another bullet point under the "object-oriented" category. This is how it looks now:

• Class-based – object-oriented programming in which inheritance is achieved by defining classes of objects, versus the objects themselves
• Object-based - paradigm in which the object has a construct to encapsulate state and behavior.
• Prototype-based – object-oriented programming that avoids classes and implements inheritance via cloning of instances
• Data, Context and Interaction - object-oriented programming where objects take on roles in a given context, as a means for the programmer to orchestrate interactions between objects

If anyone thinks that description isn't quite right or should be improved, let me know.

Just some random things I noticed about it. Rambling a bit.

Classes are about much more than inheritance. They were introduced as a template concept, mainly for efficiency, and of course build on the legacy of data structures in earlier languages.

If you drag inheritance into this then you’ll also have to bring in delegation. Delegation is a subtle concept, difficult to describe — it’s easy if you understand it, but most people have a very degenerate notion of what it is. It requires some magic to implement called “thunks” that are a bit reminiscent of how a DCI language needs to manage types at run time.

At one time there was a big argument between the Clu camp — which advocated objects with out classes and the use of delegation for incremental modification of behavior, over inheritance — and the inheritance camp. There was a famous paper published called “The Treaty of Orlando” more or less showing that they can formally be mapped equivalently into each other. That begs mentioning.

And since we’re now in Clu territory you need to invoke abstract data types. They are really key here, because they are what most people think object-oriented programming is. C++ is a great abstract data type language, as are Java and most of the rest.

Since you use the term “object-based” it is worth noting that there is a historic distinction between “object-based” and “object-oriented” which comes from Grady Booch. Basically, to him,  object-oriented entails what Peter Wegner calls inclusion polymorphism, which is implemented as virtual functions in C++ and messaging in Smalltalk. It’s object substitutability realized at run time. Object-based programming is what you get with Clu. I don’t know if Grady differentiates object-based programming from ADTs, and he rejects Alan Kay’s rejection of the likes of C++ as having missed the mark.

The important point here is that Grady thinks he understands the difference between object-based and object-oriented; most people agree with him; and it has nothing to do with how Kay distinguishes his definition from what C++, for example, provides. The key distinction for us isn’t between object-based and object-oriented but between what Grady calls object-oriented and what we call object-oriented.

At some point, the notion of a network of objects that cooperate to implement an algorithm could be introduced to underscore our description, and that’s grounded in what Kay has published (the original Dynabook paper.)

So there are many concepts here: they overlap; some of the boundaries are contentious; etc. To cover it well is probably a 30- or 40-page white paper at the least, and perhaps even a book. The trick is to scope that down to something encyclopedia-sized that conveys the main points, or slices them so that all points presented are important, while just letting others fall on the floor.

[Matthew Browne]

Hi Cope,
Thanks for the feedback. I haven't read all of this yet, but I just wanted to clarify that the only change I made was to add the bullet point for DCI; I just quoted the other 3 bullet points for context—they were already there. Of course that doesn't mean that the other descriptions of OOP in the article shouldn't be improved. But I was mostly interested in whether or not what I wrote for DCI is a good summary.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/2FA2B159-56D1-448D-BA06-BFC092B7C5A5%40gmail.com.

[James Coplien]

My point is that what you say depends on context. DCI “fits in” with these other concepts in specific ways, and it is by differentiating it from these other things that one defines it.

I would define DCI as a style of programming that sets up networks of objects to work together to solve some problem in the space of those objects, expressed as a network of interactions between objects whose responsibilities are characterized in terms of the roles those objects play in that interaction.

Details differentiating it from the others rounds out the whole article.

Your initial definition could be misconstrued to just be a Java program where all object interactions take place via interfaces, or a C++ program where they all take place via abstract base classes.

I think your essay is excellent, but think that what I wrote above (while still clumsy) goes more to the heart of the interaction between roles, objects, and their interactions.

If we were to start over I’d call it something like Cooperative Responsibility Flow specification, with “Responsibility” to be taken in the sense of (shudder) the “S” in SOLID.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/a55a3aa9-7e4f-48f4-9170-7a109adedb85%40gmail.com.

[Matthew Browne]

On 2/21/26 3:13 PM, James Coplien wrote:

I would define DCI as a style of programming that sets up networks of objects to work together to solve some problem in the space of those objects, expressed as a network of interactions between objects whose responsibilities are characterized in terms of the roles those objects play in that interaction.

That's a good distillation, but it's quite a mouthful! How about:

"A paradigm that emphasizes run-time behavior of networks of objects, whose responsibilities are granted dynamically based on roles they play in interactions with other objects"

Or, to distinguish more from class-oriented programming:

"A paradigm that emphasizes run-time behavior of networks of objects (as opposed to classes at compile-time), whose responsibilities are granted dynamically based on roles they play in interactions with other objects"

It links to the DCI Wikipedia page, so people can get more details there.

I think your essay is excellent

Thanks. I'm not quite sure what you're referring to...do you mean my initial reply in this thread on Feb. 6th?

If we were to start over I’d call it something like Cooperative Responsibility Flow specification, with “Responsibility” to be taken in the sense of (shudder) the “S” in SOLID.

You're probably aware of this, but the "Single Responsibility Principle" in SOLID isn't what most people think. Here's a quote from Uncle Bob, who of course is the one who coined the principle:

Of all the SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.

Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles—it is not the SRP.

(from his book Clean Architecture)

He clarifies:

This principle is about people.

A module should be responsible to one, and only one, actor.

Nothing terrifies our customers and managers more than discovering that a program malfunctioned in a way that was, from their point of view, completely unrelated to the changes they requested.

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/DFC59899-11FA-4EF4-A222-EB65681D888C%40gmail.com.

[James Coplien]

On 21 Feb 2026, at 22.42, Matthew Browne <mbro...@gmail.com> wrote:

That's a good distillation, but it's quite a mouthful! How about:

"A paradigm that emphasizes run-time behavior of networks of objects, whose responsibilities are granted dynamically based on roles they play in interactions with other objects”

Yeah, I know mine was not very carefully crafted but I’d figure you could do better. Carry on.