Reflections on Reflection

Recorded at:

Summary
Jim Coplien believes that we have done OOP the wrong way for 40 years, and suggests an approach to reflection based on the DCI paradigm and influenced by the human society.

Sponsored Content

Bio

Jim ("Cope") Coplien is the father of Organizational Patterns and one of the founders of the Software Pattern discipline, a pioneer in practical OO design in the early 1990s and is a widely consulted authority, author, and trainer in the areas of software design and organizational improvements. With Trygve Reenskaug he is a co-originator of the Data, Context and Interaction (DCI) paradigm.

SPLASH is the ACM conference on Systems, Programming, Languages and Applications: Software for Humanity. SPLASH is an annual conference that embraces all aspects of software construction and delivery. This is the premier conference at the intersection of programming languages, programming, and software engineering.

I normally agree with Coplien, but I still fail to see how DCI helps us build a world keen to Alexander's vision of his IEEE talk.

I think, or rather, I believe, that the way to catch end user's mental models is to sit down with them and speak to them a lot and design in front of their eyes.

What does it mean? Watching them use the previous systems. Making them talk about their realities. Show them drawings. Ask them to play make-believe with those.

For the user, the user interface is the software. His/her daily life is the system. Anything behind the user interface? Doesn't matter to them.

We should design for the real problems. We shouldn't use abstract words. We abstract them out later. Of course we abstract them out! But we should be able to show the code afterwards to a user, to any user basically, and they should be able to reason about it, and understand how it's connected to their daily life! I call it the "janitor test", and I regularly do it (hint: first remove type declarations: users don't need that).

Classes were never about object orientation: they are a way to structure code. It's a way to put things into a logical structure! Forget Alan Kay, the way we use classes is how it's written by Dahl in Structured Programming from 1972! Is it wrong? It's fine! It's about put the code where you expect to find it! Put things together which change together.

Just like we expect users to be able to find the thing they need right now in a menu structure of a large webpage (think of a government site or such) we build code hierarchies primarily to let programmers find it quickly!

Of course, we should still build code where we can reason about behaviour. You press a button - you should be able to look up what that button does in the sourcecode just by looking up the file structure.

But that's through process and not through structure! Remember what Alexander said in Nature of Order: forget the structure, a structure is only good as the process it was born through! Concentrate on your design process instead, make sure that every single part of that design is about the central topics of the problem you design against!

I fail to see how could we make user-reconfigurable systems if we build context into the whole model. If you build your system around context, how do you expect users to use its elements out of their designed context?

I don't believe everyone should be an architect, but I believe we should design architecture - and let me use a strange definition: architecture is whatever a user can't change for themselves as it'd cost a lot of effort, knowledge, or tools - in a way that users don't even think about it.

I usually say I like to design tapwater applications: when you open the tap, you don't even think about wether the water would flow. It's not natural, especially for high-rise buildings. But it's so well-designed, that for 364 years a day, you don't even have to think about it, and you can reconfigure it to whatever purpose you see it fit, cooking bathing or anything else.

Sometimes I feel that as the developer community as a whole neglected users, the design of our actual buildings - the software - is into the hands of UX designers, and developers are merely the construction workers making dreams a rigid reality.

But I hope this won't be about putting the bolts together for that long. Would DCI be the way out? I'm sorry but I can't see that still.

all data can be viewed as conversational state enclosed in boundaries
by
William Louth

What I have come to realize is that all data (or state) is is created and managed in the context of some conversational boundary that can span many interactions and have a time window of relevance that goes from nanoseconds up to years. These conversations can represent a contract or a transient association but it is the conversations and the signals that are enclosed within them that can drive runtime adaptation (behavior) - it is this that turns a class into an object.

When I first came across this talks title I was hoping to see that reflection would be revisited in terms of behavior and not state or structure (as exposed by classes). There were hints of this possible direction but sadly nothing of significance. What is lacking today is self awareness and the ability to reflect on past, present and predicted behavior.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.