- Forum
- Lounge
- Programming Ugly
- Page 5
Programming Ugly
The problem with Kay's definition is that it evolved over time. But the definition I gave is indeed very close to what he proposed in 1970s. It was primarily objects communicating using messages. Thinkgs like polymorphism, inheritance etc. were added later.
| Alan Kay wrote: |
|---|
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. |
Last edited on
| In a way: yes. Think of it as component-oriented programming — except that a new component is dynamically created every use case to suit the end user mental model. |
Having that kind of interface might be nice for the user, but the extra work the designer would have to do seems way greater than the amount of effort a user would need to look up the information they need.
firedraco:
No, the programmer also needs to master this mental model to maintain the code. In some sense the main goal of DCI is readable code. Code in which one can read the end user mental model is code that can be understood and maintained.
This reasoning in the above quote too easily leads to crappy designs. And it is subtle — it is not something that you can point out explicitly in the interface design. I like to give the example of Microsoft Word: try to insert a figure in the middle of a paragraph just where you want it. Because your mental model of what is going on is different than that of the programmer, you get bad behavior.
Brenda Laurel (another PPS person) talks about this at length in her book, Computers as Theatre. She develops Laurel's Paradox: whether the programmer should take the end-user mental model, or the end user should try to figure out the programmer mental model. Doing both leads to strange loops in the design process. In the end, the end user mental model must prevail, and that comes from Alan Kay. And object orientation was the term he coined to capture the design of a system with that facility.
rapidcoder:
That is the nerd slice of Kay's definition. The definition you gave was about building software out of objects that interact with each other — totally devoid of interaction with human beings. Your objects are mechanical collections of state and methods — nothing related to mental models. Your definition was equally good for Parnas modules as it is for objects — there is no notion of dynamics (what Kay calls late binding). Your definition missed the concreteness and importance of reifying the interactions between the objects, which is where the action takes place — what Kay calls messages. One of the largest problems with contemporary OO is that programmers live inside the objects looking out. You need to program from the system looking at the objects from the outside.
In a nutshell, what the definition is missing is the Dynabook vision, which goes at least back to the 1970s and maybe earlier. Fundamental to Kay's vision is that objects are extensions of the human mind, and that the computer serves as an adjunct to human cognitive and volitive processing. In that sense it's all about mental models. This is what Trygve Reenskaug got from working with Kay at PPS. It's tied up in Trygve's invention of MVC while working with Kay in 1978.
But as you correctly point out, it has little to do with C++, and both your definition and the Kay quote above have much more to do with OOP than any of the previous definitions that have arisen on this thread. Many of the definitions that others have offered here can work easily with C++ as most developers here understand it. So your definition is halfway there — the computer half. The end-user is the other half. Trygve now calls MVC MVCU instead — the "U" emphasizing the User. Kay had the same perspective, tuned to reach the most basic of human mental faculties so as to create machines accessible to children. The problem is that it requires a level of appreciation of very basic psychological issues of design that are proving to elude programmers in at least some programming languages. DCI is rooted in those issues.
| Having that kind of interface might be nice for the user, but the extra work the designer would have to do seems way greater than the amount of effort a user would need to look up the information they need. |
No, the programmer also needs to master this mental model to maintain the code. In some sense the main goal of DCI is readable code. Code in which one can read the end user mental model is code that can be understood and maintained.
This reasoning in the above quote too easily leads to crappy designs. And it is subtle — it is not something that you can point out explicitly in the interface design. I like to give the example of Microsoft Word: try to insert a figure in the middle of a paragraph just where you want it. Because your mental model of what is going on is different than that of the programmer, you get bad behavior.
Brenda Laurel (another PPS person) talks about this at length in her book, Computers as Theatre. She develops Laurel's Paradox: whether the programmer should take the end-user mental model, or the end user should try to figure out the programmer mental model. Doing both leads to strange loops in the design process. In the end, the end user mental model must prevail, and that comes from Alan Kay. And object orientation was the term he coined to capture the design of a system with that facility.
rapidcoder:
| The problem with Kay's definition is that it evolved over time. But the definition I gave is indeed very close to what he proposed in 1970s. |
That is the nerd slice of Kay's definition. The definition you gave was about building software out of objects that interact with each other — totally devoid of interaction with human beings. Your objects are mechanical collections of state and methods — nothing related to mental models. Your definition was equally good for Parnas modules as it is for objects — there is no notion of dynamics (what Kay calls late binding). Your definition missed the concreteness and importance of reifying the interactions between the objects, which is where the action takes place — what Kay calls messages. One of the largest problems with contemporary OO is that programmers live inside the objects looking out. You need to program from the system looking at the objects from the outside.
In a nutshell, what the definition is missing is the Dynabook vision, which goes at least back to the 1970s and maybe earlier. Fundamental to Kay's vision is that objects are extensions of the human mind, and that the computer serves as an adjunct to human cognitive and volitive processing. In that sense it's all about mental models. This is what Trygve Reenskaug got from working with Kay at PPS. It's tied up in Trygve's invention of MVC while working with Kay in 1978.
But as you correctly point out, it has little to do with C++, and both your definition and the Kay quote above have much more to do with OOP than any of the previous definitions that have arisen on this thread. Many of the definitions that others have offered here can work easily with C++ as most developers here understand it. So your definition is halfway there — the computer half. The end-user is the other half. Trygve now calls MVC MVCU instead — the "U" emphasizing the User. Kay had the same perspective, tuned to reach the most basic of human mental faculties so as to create machines accessible to children. The problem is that it requires a level of appreciation of very basic psychological issues of design that are proving to elude programmers in at least some programming languages. DCI is rooted in those issues.
Last edited on
I have implemented an experimental network protocol analyzer (in C++)
based on the DCI.
You can get more details from
http://dimitri-christodoulou.blogspot.com/search/label/DCI
and source code here:
https://github.com/dimitrs/DCI-NIDS
based on the DCI.
You can get more details from
http://dimitri-christodoulou.blogspot.com/search/label/DCI
and source code here:
https://github.com/dimitrs/DCI-NIDS
Topic archived. No new replies allowed.