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.
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.
Reflections on Reflection slides
Some slides have superimposed texts. Can fix?
Thank you. I will read your book again e try hard, now...
How about using AOP to implement this
Fail to see how DCI affects User Experience
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
Signals approach to what DCI is tackling is based on self organization, self regulation and self adaptation.
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.
Going Beyond State/Structure Reflection in Java with Behavioral Tracking
From Anomaly Detection to Root Cause Analysis via Self Observation