Wikipedia programming paradigms page

9 views
Skip to first unread message

Matthew Browne

unread,
Feb 5, 2026, 4:02:20 PM (12 days ago) Feb 5
to object-co...@googlegroups.com
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

unread,
Feb 6, 2026, 3:37:31 AM (12 days ago) Feb 6
to object-co...@googlegroups.com
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

unread,
Feb 6, 2026, 8:23:25 AM (11 days ago) Feb 6
to object-co...@googlegroups.com

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.

Reply all
Reply to author
Forward
0 new messages