introduction - folk.uio.nofolk.uio.no/trygver/themes/personal/personalprogramming… · web...

Personal ProgrammingTrygve Reenskaug

Department of Informatics, University of Oslo1

AbstractComputer programming celebrates its platinum jubilee on the 21st of June, 2018. Exactly 70 years ago, the world's first programmer wrote the world's first program and then stored and executed it in the world's first stored program computer; affectionately known as Baby. The solitary Baby has morphed into billions of computers that are loosely connected into a single, global machine. Baby's control panel has morphed into graphical user interfaces (GUI) that empower everybody to augment their intellect. The consequences are deeply radical for individuals and society alike. A significant side effect of the GUI is that the computer has faded into the background and the user focuses on the immediate needs.

We present DCI, a new programming paradigm that targets structures of communicating computers. Its goal is readable code that is so intuitive that everybody can grok it and so comprehensive that expert programmers will enjoy using it. DCI programming has been tested on real-life problems. A set of controlled experiments showed that DCI code is more readable than Java code.

A new programming environment, BabyIDE, targets the single, global machine. Different GUIs support programmers having different mental models depending on their interests and proficiency. An MVC system architecture makes the program fade into the background and lets the user concentrate on satisfying his or her immediate needs. My approach is experimental. Smalltalk's universe of objects imitates the single, global machine and is my proving ground. We give two examples: one for experts and another for novices. A video2 illustrates the novice IDE.

Our approach is experimental. The universe of objects found in Smalltalk's image imitates a computer network and is our proving ground. Squeak 3.10.2 is our laboratory where we experiment with various versions of BabyIDE.

A great deal of work remains to make BabyIDE generally available and we are searching for a trailblazer who will take charge of it and take it out into the world.

Keywords: Personal Programming, Novice Programming, Single, Global Machine, IOT, Smart Home, MVC, DCI, BabyIDE, Smalltalk, Object Orientation

1 http://folk.uio.no/trygver/themes/pp/EllenVideo.mp4 © 2017 Trygve Reenskaug. All Rights Reserved

2 Video URL

document.docx ©2018 Trygve Reenskaug of 66 2023-05-11 - 10:38

http://folk.uio.no/trygver/themes/pp/EllenVideo.mp4

Table of Contents1. Introduction..............................................................................................................................................42. Get it Right the First Time.....................................................................................................................103. Ellen's Smart Alarm Clock.....................................................................................................................12

3.1 Ellen's Smart Home.....................................................................................................................................123.2 Ellen's Smart Wakerupper...........................................................................................................................133.3 Ellen's Mental Model of Computing............................................................................................................153.4 What's Next?................................................................................................................................................16

4. Ellen's Mental Model of Computing (cont)............................................................................................17

4.1 Ellen's Data..................................................................................................................................................174.2 Ellen's Context.............................................................................................................................................184.3 Ellen's Interaction........................................................................................................................................19

5. Programming with BabyIDE..................................................................................................................23

5.1 The shared heading of all BabyIDE browsers.............................................................................................245.2 The Context Class browser..........................................................................................................................255.3 The Interaction browser...............................................................................................................................255.4 The Data class browser................................................................................................................................26

6. ProkonPlan: An Example.......................................................................................................................28

6.1 Program Architecture...................................................................................................................................286.2 Model-Context.............................................................................................................................................296.3 Model-Data..................................................................................................................................................306.4 UI-Context...................................................................................................................................................306.5 UI-Data........................................................................................................................................................30

7. Ellen's Object Computer.........................................................................................................................318. The BabyIDE Implementation...............................................................................................................34

8.1 Data..............................................................................................................................................................348.2 Context.........................................................................................................................................................35

Context metaclass........................................................................................................................................35Context instance...........................................................................................................................................36

8.3 Interaction....................................................................................................................................................378.4 Abstraction levels........................................................................................................................................388.5 Resuse and Code Sharing............................................................................................................................39

9. Further work...........................................................................................................................................41

9.1 Technical......................................................................................................................................................41

Choose programming environment for DCI................................................................................................41Port original BabyIDE from Squeak to Pharo.............................................................................................41Reprogram BabyIDE according to the DCI paradigm.................................................................................41IoT testbed for PP........................................................................................................................................42Persistent objects..........................................................................................................................................42Runtime environment..................................................................................................................................42Organize the Data objects............................................................................................................................43Create alpha version.....................................................................................................................................43Error handling..............................................................................................................................................43

9.2 Administrative.............................................................................................................................................44


Build a PP community.................................................................................................................................44Define goals and preliminary project plan...................................................................................................44Find financing..............................................................................................................................................44Build team....................................................................................................................................................44Write an introduction to PP (alpha version)................................................................................................44

10.Other initiatives......................................................................................................................................4511.Summary and Conclusion......................................................................................................................4712.Acknowledgements................................................................................................................................5213.Bibliography...........................................................................................................................................5314.Appendix-1: BabyIDE code for Ellen's Smart Alarm Clock.................................................................55

14.1 Code generated by Ellen's gestures...............................................................................................55

projection: Context-Classes.........................................................................................................................55

14.2 Code "written" by Ellen....................................................................................................................55

projection: EllenAlarmCtx-Interaction.....................................................................................................55

14.3 Data classes are are part of Ellen's infrastruture...............................................................................55

projection: Data-classes...........................................................................................................................55

15.Appendix-2: Classification of sharing technologies..............................................................................5816.Appendix-3: An abstraction hierarchy of the BabyIDE implementation...............................................59

Level 0: hardware........................................................................................................................................59Level 1platform: Microprogramming instruction repertoire.......................................................................59Level 1 body: Microprograms.....................................................................................................................59Level 2 platform: CPU Instruction repertoire..............................................................................................59Level 2 body: CPU executables...................................................................................................................60Level 3: The Smalltalk Virtual Machine (ST VM)......................................................................................60Level 4 platform: Classes............................................................................................................................60Level 4 body: Programming with classes....................................................................................................60Level 5 platform: DCI Context machine.....................................................................................................61Level 5 programs: Object=DCI Context programming...............................................................................61

16.1 Realizing the Object Computer........................................................................................................62

17. DUSTBIN...........................................................................................................................................63

17.1 The Plain Old Java Object (POJO) Execution Model .................................................................6417.2 The Connnected Society...................................................................................................................65


1. IntroductionWe live in a world dominated by computers. More than 2 billion people own one or more that we use for a wide variety of purposes. They use them to collect, create, store, edit, and communicate data. Millions of applications help them keep in contact with their friends and to draw on many different services. Yet, they may not find an application that meets their requirements -- either because it does not exist or because it is too hard to find.

We observed a two year-old girl, Selma, who poked the TV screen and got very upset because it did not answer her manipulations. (She plays with an iPad in the kindergarten). It is a sign of the times that she learns to operate a computer while she is learning to talk. We expect she will find it natural that she can bend her devices to gratify her immediate demands. Personal Programming (PP) is what we call programming done to fulfill personal needs. Some examples: The owner of a smart home will integrate its various Things to create a Personal Home. A child will direct the behavior of his or her toys. A student will create a personal simulation program to better understand a physical phenomenon. A computational chemist will write a personal program that merges several chemical simulations into a coherent whole. An investor will create a personal program for working on the share market. All of them want to take control over their environment with its devices and services; they need to become computer literate:

"The ability to “read” a medium means you can access materials and tools created by others. The ability to “write” in a medium means you can generate materials and tools for others. You must have both to be literate. In print writing, the tools you generate are rhetorical; they demonstrate and convince. In computer writing, the tools you generate are processes; they simulate and decide." (Kay, 1989)

Professional Programmers create programs for many users in many places and situations. In contrast, Personal Programmers create programs for their own use here and now. Where the professional programmer must provide options for different user requirements at different times, the Personal Programmer creates code on the fly to cater for immediate needs. The Professional Programmer is a highly trained expert while the Personal Programmer has other interests and values simplicity and convenience over programming sophistication. In this article, we focus on the interests of the Personal Programmer.

We are entering the connected society. Every thing, every person will be connected through a global communication network. At the 2007 EG conference, Kevin Kelly shared a fun statistics: "The World Wide Web, as we know it, is only 5,000 days old". After having described the past, Kelly asks:

"… what's going to happen in the next 5,000 days? So, I have a kind of a simple story, and it suggests that what we want to think about is this thing that we're making, this thing that has happened in 5,000 days -- that's all these computers, all these handhelds, all these cell phones, all these laptops, all these servers -- basically what we're getting out of all these connections is we're getting one machine. If there is only one machine, and our little handhelds and devices are actually just little windows into those machines, but that we're basically constructing a single, global machine." (Kelly, 2008).

I anticipate this single, global machine and choose to model it as collection of communicating objects. My concern is to empower Personal Programmers to master it. The first challenge is to create a mental model of computing that will form the foundation of user intuition. We look at two candidates: The von Neumann model and the DCI model.


Figure 1: The von Neumann model is a closed system..(vonNeumann-3.png)

The von Neumann model is a closed system that can only interacts with its environment through its input/output channels (Figure 1). Programming in the 1940s and 50s targeted this model, as do most mainstream programming languages today. Communication with other computers or even other programs is outside the scope of these languages and their implied models.

We reject mental models grounded on the von Neumann architecture as the target of Personal Programming and choose the more concrete model based on the DCI programming paradigm and the notion of programming by composition. Where von Neumann targets a solitary computer, DCI targets ensembles of collaborating computers and the world of computing as billions of Internet users experience it.

In the early 1970s, our Prokon project (Reenskaug, 1973) was part of a drive for participative work structures with decentralized command and control in business organizations (Emery & Thorsrud, 1976). The project introduced a vision of managers owning a personal computer that they would use for their own tasks. They could also delegate communication with others to their computer through their computer. (Figure 2).

One such task was to plan the activities of their department. Different departments had different responsibilities and used different technologies so they needed different planning programs. It was considered essential that the managers should understand the logic of their programs and ideally write them personally. The manager should be a Personal Programmer.


Figure 2: Enterprise communication.Thick, straight lines denote computer communication;

thin, wiggly lines denote human communication.1973-08-ICCAS (1).jpg

From time to time, managers would meet to synchronize their individual plans. Computers running below the table in (Figure 3) would communicate to support their owners negotiating above the table.

Figure 3: Planning negtiations on two levelsDistributedComputers-1.gif

We needed a new kind of programming that targeted an ensemble of communicating computers to check the consistency of the overall plan. We first attacked this problem in (Reenskaug, 1977) before Prokon's the money ran out and the project was terminated. The Prokon ideas survived and got a boost when we worked as a visiting scientist in Alan Kay's group at Xerox PARC in 1978/79.

Alan Kay had a vision that spanned from the hardware, though its software, to its use in a personal computer. He called it the DynaBook: "A personal computer for children of all ages" (Kay, 1972). The hardware should be communicating hand-held computers much like current tablets. Kay was instrumental in the creation of what we regard as the world's first PC, the Xerox Alto. Kay called it the Interim DynaBook. Its software was Smalltalk; a virtual computer based on what he termed object-orientation:

"... its semantics is a bit like having thousands and thousands of computers all linked together by a very fast network." (Kay, 1993)

This gave us a conceptual foundation we could use for Prokon's network of communicating computers (Figure 2). Smalltalk's programming environment was class based, i.e., it describes one object at the time. It does not support the programming of collaborations that Prokon


(Figure 2) suggests a logical process for creating enterprise communication architecture:

1. Identify participants with their competence, their responsibilities, and the services they shall provide.

2. Identify communication paths and requirements.

3. Choose human or computer communication technology for each path.

needed (Reenskaug, 1977). Postponing this issue, we focused on another: How can a manager work with a very large plan on a very small screen? The Alto was the hardware, Smalltalk was the software environment, and MVC was the answer (Reenskaug, 1978).

(Figure 4) illustrates an object-oriented worldview with different shapes depicting networked computers, now thought of as objects. An object encapsulates state and behavior and can only interact with other objects through its message interface. An observer inside an object can only see how it is realized, e.g., as a class or a HTML script. An observer in the space between the objects can only see the messages that flow when the objects collaborate within a context. The program that drives this collaboration is distributed among the participating objects; each object being responsible for a part of the overall behavior such as synchronizing the several plans existing in the managers' objects.

Figure 4: An object-oriented system with a Context of interacting roleplaying objects.(DCI-Foundation-4.png)

BabyIDE is a programming environment that leverages the power of MVC to make programming concrete and accessible to its users, the Personal Programmers. The BabyIDE Model is the distributed program as it exists in the participating objects. BabyIDE Views make parts of selected program objects visible and tangible according to the role they play when they collaborate. There can be different Views designed for different programmers ranging from the novice to the expert and from the domain-specific programmer to the general (Reenskaug, 1978). The power and simplicity of programming with BabyIDE will be demonstrated with a video example (section 3)

The DCI programming paradigm serves as the Personal Programmer's mental model of programming (fullOO.info). The DCI Data is the universe of reachable objects. These objects may be predefined, created automatically, or created explicitly by the programmer. The DCI Context encapsulates the objects that are selected to play Roles in a DCI Interaction at runtime. (http://fullOO.info).

A theatre analogy is often used to explain DCI. The DCI Data objects are like actors; they may be working or "resting". The DCI Context is like a stage where actors perform their roles. The DCI Interaction is like the text of the actor's part. Oxford English Dictionary role: "Early 17th century: from French rôle, from obsolete French roule ‘roll’, referring originally to the roll of paper on which the actor's part was written" (Figure 5). In DCI, the roll of paper is called a role-script.


http://fullOO.info/

Figure 5: actors and Interaction roles perform their role-scripts.PP-RoleScript.png

The DCI Context forms an abstraction barrier that shields the Personal Programmer from the complexities of the Data objects and their infrastructure (Figure 6). We demonstrate the power and simplicity of this approach with a video example of personal programming.

Figure 6: The DCI Context as a barrier between programmer and the distributed program objects.

DCI-abstractionLayer-2.png

The rest of the article is organized as follows:

Section 2: Get it Right the First Time is a motivation for writing readable code and formal peer reviews.

Section 3: Ellen's Smart Alarm Clock. is the narration for a video showing how Ellen programs an alarm clock that only wakes her if the weather forecast expects a dry day. See Ellen video.

Section 4: Ellen's Mental Model of Computing describes the beginner's simple mental model.

Section 5: Programming with BabyIDE describes how BabyIDE is utilizes the GUI style of interaction to provide the programmer with a direct manipulation interface.


Section 6: ProkonPlan: An Example illustrates how an expert may use BabyIDE to realize a program with relatively complex system architecture.

Section 8: The BabyIDE Implementation

TBD

discusses the handling of role name spaces in compilers and debuggers.

describes how BabyIDE is implemented as a non-intrusive extension of Squeak/Smalltalk.

Section Error: Reference source not found: Error: Reference source not found briefly describes some other approaches personal programming.

Section 9: Further work: suggests important questions that remain to be answered.

Section 11: Summary and Conclusion summarizes our results and recommends our approach to Personal Programming for general use.

Section 13: Bibliography

Section 14: Appendix-1: BabyIDE code for Ellen's Smart Alarm Clock. Generated automatically from Ellen's program.

Section 15: Appendix-2: Classification of sharing technologies

xxxxxx

Section 16: Appendix-3: An abstraction hierarchy of the BabyIDE implementation

xxxx


2. Get it Right the First TimeIt is well known that peer review with formal code inspection is a very powerful method for removing deficiencies from a program. In addition, both code writers and inspectors learn from the experience. For example, Karl E. Wiegers cites inspections held on Motorola’s Iridium project that detected 80% of the defects present. (Wiegers, 2002) 3

We tried formal code inspections for FORTRAN programming in the early 1970s. The program design evolved through weekly progress meetings, ensuring that everybody groked the current version. The unit of inspection was the subroutine; it was designed to be short and have a clear responsibility. Each subroutine was formally assigned to a team member who wrote the code and compiled it to remove syntax errors. The routine then went back to the progress meeting were it was assigned to another team member for inspection. It was tolerated and even expected that people make mistakes when coding. It was also expected that the code inspector should find all of them and the inspector was solely responsible for the correctness of the code.

The last use of the process was for a small program 4, "FORTRAN with objects". No deficiencies were found in unit testing of 3 out of 4 subroutines. The remaining had only minor bugs. No deficiencies were found in system testing or during the program's lifetime. The best programmer in the team quenched a budding enthusiasm by saying that after all, the program was very simple. True, but the problem was not. The simplicity arose partly from the choice of a database-centric architecture and functional decomposition expressed by the subroutine calling tree, but mainly through the continuous reengineering done at the weekly progress meetings. Database schema and subroutine calling tree were revised every week, partly driven by an increasing understanding of the problem and partly to create small and inspectable routines. Many projects do not have the time and manpower for such elaborate development processes, but they do find time for lengthy testing and rework. In his 1991 Turing Award Lecture, Tony Hoare succinctly stated the value of simplicity:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. …[Hoare-81]

We propose an axiom:

No problem is so complex that it doesn't have a simple solution.

It might take a great deal of time and work to find it, of course.

After the successful code inspection experience, we moved on to programming with objects. We first tried programming in Simula. Its idea of objects seemed to match the Prokon computers well. It failed because Simula required the traditional source code in closed form for the whole system, while the different Prokon managers created and owned their separate codes.

3 This paper was originally published in Cutter IT Journal, July 2002.

4 A front-end to the Fortran compiler that created a bizarre form of a recursive, object-based Fortran.


We could no longer use code inspection in the way we used to because we could no longer identify chunks of code

that were sufficiently isolated for independent inspection.

The behavior of an object is isolated from its environment. An instance method is triggered by receiving a message, but the object neither knows the identity of the sender nor the reason for sending it. The object similarly sends messages, but polymorphism prevents it from knowing the identity of the receiver or what it will do with them. The system architecture may be in the programmer's mind or in some document such as a UML design, but it is not in the code. This deficiency is behind the following observation in the introduction to the Design Patterns book:

An object-oriented program's runtime structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. The runtime structure consists of rapidly changing networks of communicating objects.[GOF-95] p. 22.

and

…, it's clear that code won't reveal everything about how a system will work. [ibid.p.23]

We were thus reduced to rely on testing the code. In the words of Edsger Dijstra:

"Program testing can be used to show the presence of bugs, but never to show their absence!"[REF]

Prokon's main source of funding went bankrupt, and the Prokon project stopped abruptly. It left us with three problems:

1. How to create a network of communicating computers be they real or virtual.

2. How to create a programming environment that most managers could master and like.

3. How to create a distributed program that consolidates the plan fragments created by the different managers.

In 1978, I had the good fortune to be invited as a visiting scientist in Alan Kay's Smalltalk group at Xerox PARC. It was a dream come true. Everybody, even the laser printer, had their own personal computer. All computers were connected locally through an Ethernet and globally through the Internet. My challenge #1 was resolved.

Another PARC invention was the Graphical User Interface (GUI). My MVC pattern separated the substance of the user's mental model from its presentation. Challenge #2 is now resolved by applying MVC to programming. The MVC Model is some representation of the program. The programmer works with this Model through different Views with GUIs that are adapted to the programmer's mental model and goals.

No Smalltalk version touches upon problem #3; the creation of readable, distributed programs. (Reenskaug, 1977) is about message-oriented programming and made a first attempt at creating such programs. Role modeling was first demonstrated in the Tektronix booth at OOPSLA conference in 1986 and yearly afterwards. Role modeling was first described in (Wirfs-Brock & Johnson, 1990) and more fully in (Reenskaug, 1996)


3. Ellen's Smart Alarm ClockThis is the narration script for demonstrating of how Ellen uses BabyIDE to program a smart alarm clock [Ellen video]. Poor quality. Should be redone.

Ellen's smart alarm clock [Ellen video].

Figure 7: TitleTitle-00.png

We live in amazing times.

3.1Ellen's Smart HomeFigure 8: Ellen's Internet of Things

(PP-ProgrammingForAll-2.png)

The things around us come alive and serve us as long as we learn how to control them -- We need to learn how to program.0:13


Figure 9: Ellen is one of many Personal Programmers(PP-titleclip-3.gif)

Let's single out Ellen, as a person among many. She wants to learn how to control her things, and she challenges us with her first, simple example:

3.2Ellen's Smart WakerupperFigure 10: Ellen hiking

(PP-ProgrammingForAll-Part-2.png)

Ellen plans to go on a long hike on the morrow, but only if it's going to be a dry day. So, she needs to program an alarm clock that checks the weather forecast before it wakes her. 0:42

Figure 11: A Lego construction toyOO-Lego-3.png

Ellen is fully at home with the idea of composition. She has, for example, experience with her Lego construction toy. It provides her with a bucketful of bricks of different shapes and colors. She picks bricks one by one and joins them to compose whatever she is building. 1:04


Figure 12: Ellen's IDE.(PP-Ellen-DemoTool-2)

A programming paradigm, that I call DCI, lets Ellen compose her program in the same way. The Lego bricks become objects that that represent things in Ellen's world. She selects one by one and connects them in a Context to become her program.1:25

One of the objects represents a bedside alarm that has replaced her old alarm clock. She picks it up, moves into her Context, and names it: WAKERUPPER.

While a Lego brick is a dead chunk of plastic, Ellen's objects are smart, they can do anything a computer can do. So she augments the WAKERUPPER with a script that tells it what she wants it to do for her: 1:59

wakeMeWAKERUPPER soundAlarm.

She tests it, and it works. 2:05

Next, she needs a weather service, finds it in her box of objects, drags it in, connects it up, and tells it what she wants it to do for her: 2:25

checkWeatherFORECASTER expectedRainfall = 0

ifTrue: [WAKERUPPER wakeMe]

And then, finally, she selects a TIMER that will perform this program tomorrow morning:

waitTillMorningTIMER waitUntil: '06:00'.FORECASTER checkWeather.

That's it, the program is complete and Ellen can set her alarm clock.2:48


3.3Ellen's Mental Model of ComputingFigure 13: Ellen's Mental Model of computing

(PP-InsertMenu.png)

You may have noticed that Ellen's code is far from conventional. Ellen has an object-oriented mental model of what goes on. More specifically, her model is based on a programming paradigm called DCI.

Figure 14Ellen's DCI window for Personal Programming.PP-window-timer-1.png

This paradigm gives her a powerful separation of concerns in three orthogonal projections.

They are called Data, Context, and Interaction.

The Data are stand-alone objects such as the objects that represent things in Ellen's home and Web services.

The Contexts are structures of roles that selected objects play to meet Ellen's goals.

An Interaction is the code within the contexts that augments the objects to make things happen.

DCI scales, so that Ellen can grow from the novice Personal Programmer to the expert without ever having to change her fundamental mental model of computing. 3:53


3.4What's Next?Figure 15: What's next?

Title-04.png

The programming tool that I have shown here is an experimental proof-of-concept implementation that I have called BabyIDE. Much work is needed to develop it into a general tool that can be used by all.

Figure 16: More at http://folk.uio.no/trygver/themes/PP'(trygve-color-2010-retouch-high.jpg)

I'm an octogenarian and I lack the necessary energy for this work. So I'm searching for an innovator who will identify with the goal and realize its potential.

The alarm sounds, the world is waiting, and it is time to wake up.4:32


4. Ellen's Mental Model of Computing (cont)

We showed the Ellen demo (section 3) to a farmer who had been using computers for many years but who had never written a program. We brainstormed a number of possible applications of Ellen's technology on her farm when she came with a pertinent observation: "This doesn't feel like programming at all." She was right, of course. Ellen's composition of her smart clock was more like setting up a playlist in a music server than programming in the conventional sense of the word. There was no source file, no compilation stage, and no concrete program. Instead, Ellen selected objects from her environment and applied the DCI paradigm to control the flow of messages that reifies her needs. A theatre metaphor helps Ellen grok/assimilate the DCI programming paradigm: A Data object is like an actor. Both exist in the environment and both have capabilities that determine the nature of the roles they can play. Actors play their roles together with other actors on a stage; data objects play their roles together with other objects in a context. Actors receive signals that cue their behavior; roles receive messages that cue their scripts.

Ellen's IDE follows the MVC architectural pattern (Reenskaug, 1978). The Model is invisible to Ellen; it consists of the fragments of code that, taken together, specify the execution of Ellen's system. Her three Views (Figure 14) help her build her mental model while she uses them to create her alarm clock.

4.1Ellen's Data

In the Introduction, we argued for basing Ellen's mental model of computing on Alan Kay's notion of object-oriented programming:"Thus its semantics are a bit like having thousands and thousands of computer all hooked together by a very fast network".5 Her ground rules are based on Alan Kay's ideas:

1. Everything is represented by an object

2. Objects communicate by sending and receiving messages (in terms of objects)

3. Objects have their own memory (in terms of objects)

4. Objects have behavior that defines the meaning of received messages.

5 Complete text in.section Error: Reference source not found: Error: Reference source not found


Figure 17: DCI Data(PP-Ellen-Objects.png)

Ellen's data are like the actors. Her objects (Figure 17) are stand-alone objects; each provides a self-explanatory message interface that she draws upon to compose her program. Some of them are general service objects that she finds on the Internet; others represent familiar things in her smart home. Objects can also be instances of local classes. She can write such classes when she becomes more proficient, or an expert can write them for her.

An object-oriented program needs to answer three questions:

1. What are the objects?

2. How are they interconnected?

3. What do they do?

The questions are open-ended and many professional programmers find it hard to answer them. (Wirfs-Brock & McKean, 2003) discusses various techniques that help them find good answers. It is easier for Ellen because all her objects are pre-defined and her program is for fulfilling her immediate needs here and now. Example: The farmer wanted to be warned if a bull calf was off its food because it probably needed special attention. One candidate object was the automatic feeder that could report the feeding history of each bull calf. Another was a timer that could check this history at regular intervals. A third was a device that could warn her of the situation.

The point is that she perceived a need, poked around in existing objects to select the ones that could help her, and then composed a program that served her needs. This is much more concrete than if she started from scratch and had to invent a solution and create the objects she needed. Ellen is only interested in what the objects can do for her; i.e., their provided interfaces. The way they are implemented, for example with classes, is irrelevant to her.

4.2Ellen's Context

Most theatrical plays involve more than one actor that performs their roles in the context of the play. Likewise, a personal program involves more than one object that performs their roles within the DCI context (Figure 18).


Figure 18: EllenAlarmContext(EllenAlarm-diagram.GIF)

In a theatre, the director casts actors to play the roles. Similarly, Ellen casts objects to play the roles of her alarm clock by moving objects into her context. Ellen can map any object to one of her roles as long as it has the capabilities needed by the role. For example, any weather service may play the FORECASTER role in Ellen's program as long as it handles the expectedRainfall-message correctly.

Ellen's programming tool, BabyIDE, remembers Ellen's gestures by generating code for casting objects to her roles:

TIMER^ResourceDictionary at: #clock ifAbsent: [nil]

FORECASTER^ResourceDictionary at: #weather

WAKERUPPER^ResourceDictionary at: #speaker

As a novice, Ellen will never see this code. Expert programmers, however, may want to replace it with a more sophisticated code for mapping objects to the roles.

A DCI Context is represented by an object, so it can play a role in another, outer Context. An application that needs Ellen's smart alarm clock can let an EllenAlarmContext play a role in this app.

The DCI notion of Contexts is recursive.

4.3Ellen's Interaction

In the theatre of old, the actors were reading their parts from rolls of paper (Figure 19). Cues transferred the control from one actor to another. Correspondingly, role-scripts augment the behavior of the roleplaying objects and messages transferred the control from one object to another.


Figure 19: Actors reading their roles6 on the stage.PP-RoleScript.png

Ellen first selected the objects that let her compose her smart alarm clock in a context while she envisaged the flow of messages that would reify her idea of a smart alarm clock (Figure 18). Her next task was to fill in the role-scripts that made this happen. (Figure 20).

Figure 20: Message sequence chart for Ellen's activateAlarm system operation.

(Runtime-MSC-2.png)

The idea of role-scripts is new to Ellen, and we endeavor to introduce it as smoothly as possible. We have chosen Squeak/Smalltalk for her scripting language because it is conceptually simple and is easy to read. Ellen creates and edits a role-script in a text editor (middle-bottom pane in Figure 12). This is a conventional "remember and type" kind of user interface; it requires that the language is part of her active vocabulary. For example, she must know the language to be able to type:

checkWeatherFORECASTER expectedRainfall = 0

ifTrue: [WAKERUPPER wakeMe]

We prefer to give her a "see and select" kind of interface so that only requires her to read the code; it can be part of her passive vocabulary. The exact nature of this interface is for further

6 Oxford Dictionary: role: Origin. Early 17th century: from French rôle, from obsolete French roule ‘roll’, referring originally to the roll of paper on which the actor's part was written.


study. We have created a preliminary solution in the form of a 2-level menu of code templates (Figure 21). A balloon text helps Ellen when the mouse hovers over a menu item.

Figure 21: Coding by menu selectionPP-InsertMenu.png

A benefit of this form of visual programming is that its generated code is visible and editable, thus helping Ellen to gradually include PP programming in her active vocabulary.

We have also looked at the visual programming environment in Etoys; an object-oriented computer environment for use by children (Galas & Freudenberg, 2010). In this environment, scripts are composed with drag- and drop operations on tiles (Figure 22). This idea could be carried over to PP where it, like in Etoys, would generate the role-scripts.

Figure 22: Faked Etoys script for checkWeatherPP-Ellen-weather-ETOYS.png

Personal Programmers are adults who will be reasonably sophisticated since they understand the many devices in their smart home. We believe most will be best served with a menu driven programming interface, but some may prefer something like the more intuitive Etoys interface.

Many mainstream languages like Java has built-in syntax constructs for structuring the program. In Smalltalk, these constructs are replaced by ordinary messages to objects. For example, the Java code

class ForLoopExample3 { public static void main(String args[]){ int arr[]={2,11,45,9}; for (int num : arr) { System.out.println(num); } }}

yields the output


211459

The same algorithm in Smalltalk is

arr := #(2,11,45,9).arr do: [:num | Transcript show: num]

For Ellen, this means she starts with a very simple base language. She adds new objects (classes) as needed to extend her capabilities without ever having to change her fundamental model of computing. arr in the above code is an instance of class Array which is a subclass of Collection. Messages understood by all Collections are do:, size, ifEmty:, ifNotEmpty: , asSortedCollection, select:, collect:, ...

We envisage the mentors will make new system classes and subsets of their message interfaces available to Ellen as she needs them. < Can she do it herself? Online tutorial? >


5. Programming with BabyIDEBabyIDE1 is an interactive development environment for programing in orthogonal projections according to the DCI paradigm. Each projection tells part of the story; all projections taken together tell the whole story. BabyIDE provides specialized browsers for the Data, Context, and Interaction kinds of projections.

Ellen uses a variant of BabyIDE, the PP tool, that is scaled down for the novice (Figure 12). Professional programmers use the full BabyIDE that is described in this section and exemplified in (section 6: ProkonPlan: An Example).

BabyIDE has different browsers for different kinds of projections:

The Data Class browser for working with regular Smalltalk classes. These classes specify the state of the system through their own and derived attributes and their associations with other classes. The Data classes also specify local behavior realized within the encapsulation of their instances.

The Context browserfor working with the Context as a class. The public interface of its instances includes the system operations that are reified by the Context. This class also includes the essential methods that bind Roles to objects during the execution of a system operation.

The Interaction browserfor editing the Interaction diagram with its roles and the links between them. It also supports creating and editing the role-scripts that drive the peer to peer communication when the system performs a system operation.

The different browsers are described in more detail below. We stress that an actual programmer may only see a selection of these browsers, code for remaining browsers will then be generated automatically as we have seen in Ellen's programming interface.

BabyIDE makes the program architecture visible and tangible with browsers for each projection. The BabyIDE browsers support the DCI separation of concerns so the work done on a projection in one browser is almost independent of work done on other projections in other browsers. BabyIDE is modeless; each browser carries its own state so that work in a browser can be suspended and resumed at will.

We use the code generated by Ellen as an example throughout.


5.1The shared heading of all BabyIDE browsersFigure 23: BabyIDE heading(BB11PP-Window-annotated.png)

The headings in all BabyIDE browsers are (Figure 23):

1. This button closes the window.

2. A menu button, its commands are ▪ remove application Remove this application from the system.▪ change application Change the application that is handled by this IDE.▪ new projection: Add a new projection to this application. (Not implemented)▪ printHtml for this App: Export the code for this application as a read-only HTML file,

see (section 14: Appendix-1: BabyIDE code for Ellen's Smart Alarm Clock) for an example.

3. The application is Ellen's Smart Alarm, BBa11PP. (The obscure name prefix is chosen to get around the lack of name spaces in Squeak).

New projections are added as needed. Each projection is edited in an appropriate browser. An example with many projections is in (section 6: ProkonPlan: An Example).

A Context object forms the context for the execution of one or more Interactions. The roles are declared in the Context and are shared by its Interactions.

There are two browsers in the Context projection: The Context class browser and the Interaction browser. A swap to class/swap to Interaction button toggle between them.


5.2The Context Class browserFigure 24: The Context class browser.

(BB11PP-ContextClass-annotated.gif)

The panes of the Context class browser (Figure 24) are:4. The selected projection is Context. 5. A list of Context classes, EllenAlarmCtx is selected. A button toggles to the Interaction browser.6. The superclasses of the selected class are shown in a multi-select list that acts as a presentation

filter. 7. The method categories of the selected class and any selected superclasses are shown in a

multiselect list. This is a presentation filter; only methods belonging to the selected class, the selected superclasses and the selected method categories are shown. By convention, the API category is reserved for the interface that instances of this class export to the environment, i.e., the system operations it reifies. The role binding category is selected here.

8. A list of methods in the selected method categories. (There is one method for each role in the role binding category; it binds the role programmatically to an object. The role binding methods are always executed together as one atomic operation to ensure consistency. Ellen generated these methods automatically when she moved Data objects into her Context).

9. A code pane showing the source code of the selected method. This is a text pane, and it lets the programmer to write code in Smalltalk's default language for methods.

5.3The Interaction browser

The Interaction browser (Figure 25) is where we specify how a DCI program realizes a System Operation within a network of communicating objects. The code in this projection answers three critical questions for each System Operation:

What are the objects? The roles identify the participating objects; the actual objects are selected at runtime by the Role binding methods in the Context Class browser (Figure 24).

How are they interlinked? The programmer answers this question by painting a network of connected Roles in the Interaction Diagram.

What do they do? The browser answers this question by augmenting selected Roles with Role Scripts. These scripts become ephemeral parts of the roleplaying objects while needed at run-time.


Figure 25: The Interaction browser.(BB11PP-ContextInteraction-annotated.png)

The panes of the Interaction browser (Figure 25) are:4. The selected projection is Context.5. A list of contexts. EllenAlarmCtx is selected. A button toggles to the Context class browser.

(Multiple Interactions within a Context is for further work.)6. The Interaction diagram where the programmer work with roles (select, link, add, remove, and

rename). The FORECASTER role is selected. 7. A list of FORECASTER role-scripts, FORECASTER>>checkWeather is selected. 8. An editor for the selected role-script. Role scripting is discussed in (section 4.3). (While a

Smalltalk method accesses instance variables by name as declared in the class definition; a Role script accesses roles by name as declared in the Interaction diagram.)

(Figure 29) shows a more complex example.

5.4The Data class browser

Any object can play a role in a Context. This means that an instance of any Squeak class can play a role, including an instance of a Context class. It also includes objects with no available class such as objects found on the Internet (of Things).

In the BabyIDE Data projection, we edit the declaration of classes that are specific for the current application in the Data class browser (Figure 26).


Figure 26: The Data class browser.(BB11PP-Data-annotated.gif)

The panes in the Data class browser (Figure 26) are:4. The selected projection is Data.

5. A class list showing the local Data classes. BBa11MetOffice is selected. This a dummy that simulates an Internet service. Internet access is not used in this version of BabyIDE.

6. The superclasses of the selected class are shown in a multi-select list that acts as a presentation filter.

7. The method categories of the selected class and any selected superclasses are shown in a multi-select list. This is a presentation filter; only methods belonging to the selected class and the selected superclasses are shown. The API category is selected. By convention, its methods form the external interface of this class.

8. A list of methods in the selected method categories. The expectedRainfall method is selected.9. A code pane showing the source code of the selected method.


6. ProkonPlan: An ExampleProkonPlan is a simple planning tool. (Figure 27) shows its user interface.

Figure 27: ProkonPlan user interface.(Prokon-3-annotated.png)

An activity represents a task that needs to be done. It has a certain duration; it cannot start before all its predecessor activities are completed; and it must end before any of its successor activities can start.

The panes are:

1: identifies the program version and offers a menu for triggering various operations on the model.

2: shows the properties of the selected activity and allows them to be edited.

3: shows the activity dependency graph.

4: shows the earliest and latest start and finish times given the project start and finish times that are specified by a menu command in pane 1. The yellow, top bars show earliest and the bottom, green bars show the latest times.

5: shows the results of automatic resource allocation. We see that the resources are named Ava and Joe.

6.1Program Architecture

The program architecture rests on two orthogonal principles for separation of concerns: MVC and DCI. The primary separation is along MVC lines; the Model and the User Interface (UI). The user interface (Figure 27) is a typical application of MVC. The user experiences this interface as an extension of his or her mind. This "magic" of MVC (Figure 28) is achieved by faithfully reflecting the user's mental model in the Model code and by using well known graphic languages for the Views so that they are readily intuited by the user. An invisible


Controller sets up the Views in the window and coordinates them by making the selection of an activity show itself in all Views simultaneously.

Figure 28: MVC(MVC4.gif)

Each of UI and Model are further separated along DCI lines (Figure 29):

Figure 29: BabyIDE for ProkonPlan.(IDE-Prokon.png)

6.2Model-Context

This projection defines Model behavior, i.e., the operations on the Model itself. The Contexts are FrontloadCtx, BackloadCtx, ResourceAllocationCtx. They are edited in Context class and Interaction browsers (Figure 24), (Figure 25).

In (Figure 27, pane 5), we see that the UI-Ctx activity is performed by Joe in week 2 and 3 and is then finished by Ava in week 4. This is probably not the desired allocation, but rather a side effect of the chosen allocation algorithm. While simple algorithms compute front- and backloading, the optimal allocation of resources depends on local circumstances. We suggest that the user should code this particular algorithm so that he or she could modify it on the fly to get an acceptable plan. This is feasible because the code is wholly contained within a single Context, ResourceAllocatiaonCtx.


6.3Model-Data

This projection reifies the static part of the user's mental model. The Model is a structure of objects that faithfully reflects the user's mental model. Their classes are DBase, Model, Activity, Dependency, Resource. They are edited in class browsers (Figure 26).

6.4UI-Context

The UI-Context projection include the display operations that create what the user sees on the screen and respond to user commands. There are many intricate coordinate calculations that we like to hide in separate Contexts: DependencyDisplayCtx, GanttDisplayCtx, and ResourceDisplayCtx. There are also Contexts for the user commands: AddActivityCtx and AddDependencyCtx. They are edited in Context class and Interaction browsers (Figure 24), (Figure 25).

6.5UI-Data

The user interface (UI) bridges the gap between the human mind and the computerized Model. Usually this is done by an instance of a Controller class and one class for each View (here 5). In Squeak, these classes build on its Morphic framework. A View object is responsible both for retrieving data from the Model and for presenting it with Morphic class library. The UI-Data classes are Controller, DependencyView, ActivitySymbol, DependencyLine, ActivityTextView, BlurbView. They are edited in Data class browsers (Figure 26)


7. Ellen's Object ComputerWe are entering the connected society. Every thing, every person will be connected through a global communication network. At the 2007 EG conference, Kevin Kelly shared a fun statistics: "The World Wide Web, as we know it, is only 5,000 days old". After having described the past, Kelly asks:

"… what's going to happen in the next 5,000 days? So, I have a kind of a simple story, and it suggests that what we want to think about is this thing that we're making, this thing that has happened in 5,000 days -- that's all these computers, all these handhelds, all these cell phones, all these laptops, all these servers -- basically what we're getting out of all these connections is we're getting one machine. If there is only one machine, and our little handhelds and devices are actually just little windows into those machines, but that we're basically constructing a single, global machine." (Kelly, 2008)

We choose to model this single, global machine as collection of objects all connected through an any-to-any virtual bus. A stack of communication protocols holds the bus together. Several proprietary stacks with their associated Things and software packages have been created for specific application markets. Each of them forms a closed system and its software and Things can't be used anywhere else. Several groups are competing to create the real thing, the single, global machine. It will be founded on a stack of open, widely accepted communication protocols. This stack will open a huge market for its software and hardware components.

We are mainly interested in the protocols for identifying and accessing the networked objects and mechanisms for accessing their resources. The details of this work are outside the scope of this article, and we choose two candidates as a foundation for our thinking. The first is UUID, a standard that provides a globally unique 128 bit identifier for each and every object on the Internet:

"When generated according to the standard methods, UUIDs are for practical purposes unique, without depending for their uniqueness on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is close enough to zero to be negligible." (Wikipedia: UUID)

The second candidate is the self-descriptive interfaces and other properties that are provided by RESTful advice coupled with data coded with the HTML5 markup language. [Wikipedia: "Representational state transfer" and "HTML5"].


Figure 30: Ellen's object computer.ObjectComputer-1.png

The emerging single, global machine is distributed and has no physical or logical center. Ellen perceives herself as being in the center of an object computer that reifies the DCI programming paradigm. Its Data objects are the objects of the single, global computer merged with the objects of her personal ST image. They are illustrated as yellow stars in (). Each object has an immutable and globally unique identity. It is encapsulated, which means that its state and behavior can only be accessed through its message interface.

Ellen creates a Context to make her object computer serve each of her needs. She selects Data objects to play its roles, augments their behavior with role-scripts to make them behave properly in an Interaction. Every message in an Interaction is sent from a role-script to an object trough a role it is playing. There is a method in the Context base class that intercepts all Interaction messages and ensures that they are handled properly by their receiver:

Context>>to: roleName send: selector withArgs: argCollection if (the role named roleName has a script named selector)

{execute it} if (the object currently playing the role named roleName is a UUID)

{send message to its UUID over the Net}if (the object currently playing the role named roleName is a regular ST object)

{send a regular ST message to to the object playing the role named roleName} end

BabyIDE (section 5) is Ellen's tool for programming her personal object computer. Objects in the Smalltalk object (class) library and the objects of the single, global machine are outside Ellen's control and not handled by the current Data class browser. Later versions of the browser will be extended to edit references to these objects.

with objects in the Smalltalk object (class) library and the objects of the single, global machine.

To Ellen, all objects are alike and all messages have the same semantics. All Interaction messages are passed from role to role. This is an illusion, the details of a message reception depends on the nature of the receiver.

Ellen is working with a machine consisting of uniform objects and only objects.


and are all the same to Ellen. They are Ellen's Data objects, so she can make them play roles in a DCI Context, augment their behavior with role-scripts, and send messages to them through the roles in an Interaction.


8. The BabyIDE ImplementationBabyIDE is a Squeak implementation of Ellen's mental model of computing of section 4 and Ellen's object computer of section 7. The purpose of the implementation is, like the Smalltalk virtual machine, to maintain the programmer's illusion of working with a DCI or Smalltalk computer. This section is written for Smalltalk programmers who are interested in the details of the BabyIDE runtime system.

Alan Kay and his team performed successful experiments with teaching children to program with Smalltalk-72. Its downside was that it did not scale to full-sized problems. Smalltalk-76 was the version I used at PARC. It scaled but lost the children. The children have moved further and further out of sight in later variants such as Smalltalk-80, VisualWorks, Squeak, and Pharo. The needs of adult Personal Programmers or Kay's children of all ages have not been addressed by any version of Smalltalk after Smalltalk-72 as far as I know.

BabyIDE is implemented as a non-intrusive extension of Squeak 3.10.2. Squeak is about objects, and every object is an instance of a named class. There is only one name space in Smalltalk and there is a significant risk for name collisions if a user imports code created by somebody else. We have partially mitigated the problem by augmenting class and other global names with a prefix that identifies an application. This serves us in the short term but it gives us neither safe nor elegant class names like BBa11Alarm.

BabyIDE uses the Squeak SystemOrganization to organize global objects belonging to different applications. The format of the category name is <appName>-<projection name> as illustrated in (Figure 31). Three visible applications are: BB9Planning (section 6), BBa10Pong (a game), and BBa11PP (Ellen's smart alarm clock).

Figure 31: BabyIDE organzerBabyIDE-organization.png

Figure 23 ff. shows BabyIDE opened on BBa11PP: Ellen's smart alarm clock. It shows Ellen's two projections, Data and Context. BBa11PP-Roles is a hidden projection that holds the Interaction role-scripts, see below.


8.1Data

The Data objects are stand-alone objects as described in section 7. In Ellen's smart alarm clock, all the Data objects are instances of regular Smalltalk classes. An invocation of one of its methods puts an activation record on the stack (Figure 32). Contrast with the role-script activation record in (Figure 33)

Figure 32:An instance method activation record with associated objects.RuntimePOJOMethodScope.png

In a production version, many of the objects will be distributed on the web. An object identification must be globally unique such as a UUID7 and the object's provided interface must be visible.

The demonstration Data objects are stored in a global dictionary, ResourceDictionaryUUID. Its entries are UUID -> aBB1UUID. The standard UUID is a 128-bit number but we use a simple string for the sake of readability. Different subclasses of BB1UUID are planned to support different access mechanisms. The current class yields a simplified placeholder that only accesses regular instances of Squeak classes; i.e., the BB1UUID resources.

8.2Context

Roles represent object identity; an object property that is not described in the object's class. Consider system behavior as a trace of the message flow during an execution as a directed graph. The identity of the visited objects is likely to change from one execution to another. DCI is used to describe system behaviors where the topology of the trace stays constant. The nodes of the graph are the roles and the edges are the links. (Note that classes do not enter into the argument).

Every Context is subclass of BB1Context. It has important logic both in the class and in the metaclass.

Context metaclass

The class side of a Context is responsible for the topology of the roles. Roles represent object identity; an object property that is not described in the object's class. Consider system

7 Wikipedia: Universally unique identifier; ISO/IEC 9834-8:2005.


behavior as a trace of the message flow during an execution as a directed graph. The identity of the visited objects is likely to change from one execution to another. DCI is used to describe system behaviors where the topology of the trace stays constant. The nodes of the graph are the roles, the edges are the links. Note that classes do not enter into the argument.

The topology8 is created graphically in the Interaction diagram and remembered in the form of automatically generated class methods. Programmers who prefer the textual representation may write the same code by hand:

EllenAlarmCtx class>>roleStructure^super roleStructure

at: #FORECASTER put: #(#WAKERUPPER );at: #WAKERUPPER put: #();at: #TIMER put: #(#FORECASTER );

yourself.

and similarly for the diagram geometry.

Context instance

The instance side of the Context is responsible for 1. binding roles to objects at runtime2. reifying the interface provided by the Context

The object to be bound to a role is declared in a method named after the role:

EllenAlarmCtx>>FORECASTER^ResourceDictionaryUUID at: #weather ifAbsent: [nil]

All roles are bound in an atomic operation to strengthen consistency:

BB1Context>>remap| messName |self newRoleMap.self class roleNames

do: [:rNam | messName := rNam asString asSymbol.roleMap

at: messNameput: (self perform: messName ifNotUnderstood: [nil])].

self checkRoleMap.^roleMap.

Each messages in the provided interface is fielded by an instance method in the Context's API method category. It is responsible for initializing the instance, putting it on top of the Context stack, and triggering the first role method:

EllenAlarmCtx>>startself triggerInteractionFrom: #TIMER with: #waitTillMorning andArgs: #().

BB1Context>>triggerInteractionFrom: triggerRoleName with: selector andArgs: argsself executeInContext:[self remap.(roleMap at: triggerRoleName ifAbsent: [nil])

ifNil: [self inform: 'Data object for role named ' , triggerRoleName , ' is undefined. '. ^self]ifNotNil: [^self to: triggerRoleName send: selector withArgs: args]].

The last statement, to: roleName send: selector withArgs: argCollection, transfers the execution model from the regular Squeak model where methods are executed in the context of a class (Figure 32) to the Interaction model where methods (role-scripts) are executed in the context of a DCI Context (Figure 33).

8 The Interaction diagram (6) in (Figure 18).


8.3Interaction

Executable methods and role-scripts are instances of class CompiledMethod. A CompiledMethod is essentialy an array of ByteCodes and does not have a backpointer to the class that compiled it. For DCI, this means that a role-script may be compiled and stored in one class and executed by an instance of another . The classes of the objects that will be playing a role at runtime is unknown at compile time. We therefore create a hidden class to compile and remember the scripts of a role. The name of the class is globally unique: <context class name><role name>, e.g., EllenAlarmCtxWAKERUPPER. Its class category is: 'BBa11PP-Roles'.

We have extended the default compiler for methods to compile role-scripts in the context of a Context role topology. This structure is a directed graph with the roles as its nodes and their mutual visibility through the links. (Figure 25 pane 6).

Encoder>>init: aClass context: aContext notifying: req …" Begin DCI special. "(aClass superclass == BB1RuntimeRole and: [class roleName notNil]) ifTrue:

[((class contextClass collaboratorsFor: class roleName) , #(cc))do: [:roleName |

self scopeTableAt: roleName put: (BB1RoleNode new asVariable: roleName contextName: class contextName)]].

" End DCI special. "...

One of Ellen's role-scripts was:

WAKERUPPER >>wakeMeWAKERUPPER soundAlarm

The compiler adds hidden code to access roleplaying objects at runtime. This hidden code can be made visible by pressing ctr/y in (Figure 25 pane 7): Note that link to the method, program counter, etc. is not shown in the figure.

WAKERUPPER >>wakeMe(BB1ContextStack playerForRole: #cc9) "This is clumsy code for finding the CurrentContext object. "

to: #WAKERUPPERsend: #soundAlarm withArgs: {}

BB1ContextStack class>>playerForRole: roleName ^self currentContext at: roleName

An invocation of the wakeMe method puts an activation record on the stack (Figure 33).

9#cc is a role that is always played by the CurrentContext


Figure 33: A role-script activation record with associated objects. (RuntimeDCIScriptScope.png)

The following method is the heart of the BabyIDE invocation mechanism.

BB1Context>>to: roleName send: selector withArgs: argCollection | receiver roleClass compiledMethod |receiver := roleMap at: roleName.roleClass := self class roleClassForRoleName: roleName.roleClass ifNotNil: [compiledMethod := roleClass compiledMethodAt: selector].compiledMethod ifNotNil:

[^receiver withArgs: argCollection asArray executeMethod: compiledMethod]ifNil:

[(receiver isKindOf: BB1UUID) ifTrue: [^receiver send: selector withArgs: argCollection]ifFalse: [^receiver perform: selector withArguments: argCollection asArray]]

The Personal Programmer sends messages to objects without considering or even knowing their nature. Roles may be seen as smart UML ports and the above method defines their behavior:

If there is a role-script for this message, execute it whatever the nature of the receiver. If the receiver is a reference to a possibly remote object, forward the message to it. The receiver is a regular Squeak object. The object receives a regular Squeak message.

8.4Abstraction levels

The BabyIDE described here rests upon an implementation of Squeak, which rest upon a stack of abstractions down to the hardware gates:

Table 1: Abstraction levels below our PP implementation

Abstraction Concretization

Hardware components Rests of HW gates etc. Builds components, recursively.

Microcode Rests on HW components, builds CPU instructions.

CPU Programs Rests on CPU instructions and programs, builds programs recursively. Example: Squeak runtime system.

Squeak Rests on Squeak runtime system. Is a universe of stand-alone objects: where an object is an instance of a class (an object).

1. Everything is represented by an object


2. An object is an instance of a class (an object)

3. Objects communicate by sending and receiving messages (in terms of objects)

4. Objects have their own memory (in terms of objects)

5. Objects have behavior that defines the meaning of received messages.

Builds ensemble of classes that are planned to be instantiated and executed. Example: BabyIDE.

DCI Rests on Squeak, builds structures of collaborating objects. The class can be seen as the microcode of objects.

Data: Objects

Context: A structure (directed graph) of objects where the node objects are called roles and the edges are communication links.

Interaction: Code scripts superimposed on the roles to make them collaborate to achieve one or more desired functions (use cases).

Example: Ellen's smart alarm clock.

PP The Squeak universe of objects is extended with the objects found on the Internet.

8.5Resuse and Code Sharing

Personal Programmers need a forum or marketplace for reuse and sharing programming resources. (Table 2) shows some common sharing technologies:

Table 2: Classification of reuse and sharing technologies

Technology Resuse and Sharing

1 Subroutines/procedures FORTRAN, Algol, C, etc.Share subroutine/procedure library: APIsRequires: Shared subroutine call mechanism.Example: https://en.wikipedia.org/wiki/Carbon_(API)

2 Class Java, Ruby, & Friends (C++?), etc.Shared class library extension.Requires: Shared superclasses.Example: https://docs.oracle.com/javase/8/docs/api/

3 Objects BabyIDEShare objects locally or over the Internet.Requires: shared standards for object identification and access.Example: Ellen's smart alarm clock.


Monticello (Squeak, 2018) is a comprehensive, distributed, optimistic, concurrent, versioning system for Squeak packages. A Monticello package is an executable string of executable Squeak statement that declare whole classes, extension methods for existing classes, or other Squeak statements. Monticello thus supports the sharing of methods (procedures), classes, and references to objects such as OOIDs.

Many Monticello repositories are in existence and different version of a package can be distributed among them.

Monticello packages for a web client and a Web server have been published. The former can form the foundation of a PP object access mechanism and the latter as a mechanism for publishing an object on the Web.


9. Further workI am an octogenarian and I lack the necessary energy for bringing PP to fruition. So I'm searching for an innovator who will identify with the goal and realize its potential. The following list of some of the things that need to be done is neither ordered nor prioritized.

9.1Technical

Choose programming environment for DCI

I have considered basing PP on different mainstream languages such as Java, JavaScript, or Ruby, but have rejected them all. The reason is that they lack the reflective capabilities required for DCI and are aimed at stand-alone, von Neumann computers rather than networks of communicating computers such as the Web or IoT.

All variants of Smalltalk target universes of communicating objects and have the reflective capabilities needed for BabyIDE. I strongly feel that any implementation of DCI should be free and open source to encourage a community of users and contributors with varying needs and preferences. This takes us to Squeak or Pharo. I have argued that Squeak's volatility and complexity does not make it a good candidate for PP. Pharo (https://pharo.org/) is an open source project released under the MIT license. Pharo is a fork of Squeak where the class library has been cleaned up and the system reorganized with a minimized core and with additional functionality added as separate packages. This fits well with the novice programmer who can start from a small core and add packages to learn more and do more as her needs arise until she becomes an expert.

Pharo is targeted at the professional developer while PP is targeted at the non-professional and occasional programmer. Pharo has a very active development community. It is clear that many of its features are potentially useful to PP while their associated complexity could form a barrier for the non-expert. This indicates that BabyIDE should be isolated from Pharo by representing Pharo functionality as resource objects in BabyIDE. Such isolation may also be necessary for privacy and security reasons.

Port original BabyIDE from Squeak to Pharo

Modify Pharo compiler to handle DCI role-scripts.10 and port BabyIDE user interface to Pharo. The port may be simple since Pharo also has Morphic.

Reprogram BabyIDE according to the DCI paradigm

The current BabyIDE has grown organically as a laboratory experiment. It should be redesigned and implement using the current BabyIDE. The architecture of the Prokon/Plan example (section 6) could inspire the new architecture and implementation.

10 In Squeak 3.10.2, this entailed creating VariableNode subclass: #BB1RoleNode instanceVariableNames: 'receiver arguments selector'Object

subclass: #BB1Context instanceVariableNames: 'roleMap' and enhancing the methods:

Encoder>>init: aClass context: aContext notifying: req Parser>>messagePart: level repeat: repeat)


https://pharo.org/

IoT testbed for PP

The PP project needs to experiment with BabyIDE in a realistic environment. The project should therefore collaborate with one of the many IoT projects, preferably a free, open source project.

Persistent objects

The value of a program materializes when an end user applies it to create valuable data; the hardware and software being means to an end. Personal Programmer may tolerate program errors or even crashes but hey will not tolerate loosing their personal data, including personal programs.

At regular intervals, Pharo and other application runtimes issue a new version of their system. Sometimes, this invalidates old programs and old data may become unreadable. At one stage, this made us reject both Squeak and Pharo as the foundation of PP. We have later learned that this volatility is an unavoidable side effect of living software, a side effect it shares with most languages and operating systems. The consequence is we must store valuable user data in a persistent repository.

An object that exists in the Pharo image has behavior; it can do things. An object that resides in a repository is dead; it cannot do anything. We need a mechanism that will extract essential information from an object and encode it as a persistent record in a repository.

In an old program, now in the Valhalla of undocumented programs, the encoding and decoding of object information was delegated to the classes of the objects, the metaclasses. Whenever the object information changed, its class encoded the information, tagged it with a type and a version number, and stored the record in the repository under its global identifier. An object record was retrieved from the repository; its kind selected its class, and its version number selected the appropriate decoder. This mechanism made metaclasses responsible for maintaining backward compatibility and users could always read old data independent of the system developers' inventions over time. The onus of ensuring backward compatibility was on the system developers; they must provide decoders for old data regardless of their new capers.

A similar mechanism may be used to ensure persistent data objects for PP.

Runtime environment

BabyIDE is a Personal Programmer's private window onto the global universe of objects including her own image (Figure 30).

Technically, a Pharo installation consists of a Virtual Machine (VM), an Image, and optional text files holding source code.

---------------------------------

BabyIDE development system. Pharo including BabyIDE that is launched in the normal manner. This will be the environment for the PP developer.


BabyIDE as an application that can be downloaded into the user's personal device (PC, tablet, smartphone, etc.)

BabyIDE as a service. The BabyIDE image is partitioned into a shared and private part. The private part includes the objects that are owned by the Personal Programmer . Examples are Contexts and role-scripts. The shared part consists of the system objects that are owned by the service provider and that are hidden from or used by the Personal Programmer. The Etoys user interface can act as a model.

Organize the Data objects

The emerging IoT will form an extremely complex system with its billions of independent objects, each running in its own process. (Wikipedia: "Internet of things"). It is a challenge to hide this complexity from the Personal Programmer. Its resolution will probably require an understandable exception handling both in BabyIDE and in the IoT partition used by the program. A possibility is to organize objects in RESTful repositories or servers:

Representational State Transfer (REST) is an architectural style that defines a set of constraints and properties based on HTTP. Web Services that conform to the REST architectural style, or RESTful web services, provide interoperability between computer systems on the Internet. REST-compliant web services allow the requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operations. (Wikipedia)

REST gives the self-descriptive message interfaces needed by BabyIDE both for choosing the appropriate interface standard programmatically and for informing the user (Figure 21).

We touch upon this solution with the BB1UUID class in the current BabyIDE. Its instances are accessors to the remote resource, for example through the method

send: selector withArgs: argCollectionthat knows how to trigger remote resources11.

Create alpha version

The current version of PP is a full Squeak implementation that is used for demonstration and experimentation. It shall be followed by an alpha version that offers a programming interface for PP that isolates the PP programmer from the underlying Squeak or Pharo image.

An alpha version of BabyIDE shall be made available to anybody who has the courage and interest to be on the bleeding edge of the development.

Error handling

According to David Roe, the IoT could have has many as 50 billion connected devices12 by 2020 and households may have as many as 500 IoT devices by 2022 (Roe, 2018). Many, if not all of these devices will be developed by people who neither has the time nor the expertise to protect the devices adequately against technical and human threats to their integrity.

11 There is an important distinction between an accessor and a wrapper. A wrapper pretends to be the remote object and behaves exactly like it. It shares its identity and wrapper == remote object. This shared identity violates a fundamental rule: An object has an immutable and globally unique identity. Breaking this rule can cause what is called Object schizophrenia where one object is mistakenly used instead of another.

12 Such as sensors, actuators, and computers.


Around 1980, I asked a master student to establish 100%reliable communication network in our then new Ethernet. The poor person was running around the lab disconnecting cable contacts, inserting new bridges, etc. He was getting more and more frustrated: Every time he protected against one failure mode, he found another. Then he read this in an article: "You can protect against any threat you can put on a list, but there will always be many more threats that aren't on the list." He happily completed his thesis and I learned an important lesson:

The general problem of handling the threats is outside the scope of the PP project. Nevertheless, the project must handle the uncertainties inherent in the roleplaying objects and in the links that bind them together.

PP is about connecting Ellen's mind to something she already knows and minimizing the new concepts she needs to assimilate. Ellen's mental model is a model of objects that represent well-known concrete things in Ellen's world. Her conceptual objects are error-free and an Interaction tells a complete story. The initial model gets prohibitively complex if we let it include general error handling in an uncertain world. The challenge to the PP implementer is to let Ellen retain her illusion of an error-free system and still capture the malfunctions that will occur from time to time in the concrete system. As an example, consider that the weather forecast is unavailable when Ellen's smart alarm clock needs it. Should it wake her or should it let her sleep on? Who decides and how reify the decision? Whatever the solution, the key question must be:

How do we explain this solution to a novice such as Ellen?

9.2Administrative

Build a PP community

Define goals and preliminary project plan.

Find financing.

Build team.

Voluntary, crowd funding, budget

(possibly 5-10 people 5-10 years depending on ambition.)

E.g: around a mailing list or other social media.

Write an introduction to PP (alpha version)

It would be nice with a free book for new users.


10. Other initiativesThe DCI programming paradigm has been reified by James O.Coplien (Cope) in a research language he calls trygve:13.

The trygve language allows you to think about your program in terms of mental models of some phenomenon that you bring to the table. It’s called object-oriented programming, so we’re going to talk about classes as a supporting cast rather than as the star players. Here, objects are the stars of the show. We talk about objects in terms of the names our compressed mental models give them as they interact to solve some problem. Those names are Roles. Any given Role is just a name but at the same time is much more. The Role “fireman” is just a name for some human being in a particular Context, but it also elicits a host of associated behaviors. Those behaviors that are germane to the Role itself, without much regard for the Role-player, are called scripts in trygve (computer scientists call them methods) — little recipes for doing very small tasks.

And trygve departs from Java in yet more fundamental ways. Java tried to be a pure OO language by outlawing global functions, but that is a simplistic hope at best. It ended being only a class-oriented programming language. Like most languages of its kind it has many features to finesse class relationships. These features encourage class-oriented thinking, overuse of inheritance, and programmer convenience over end-user mental models. So you will find neither friends, or static objects, or the concept of super, nor the protected access property in trygve.

The trygve language is just one part of a system design that supports end user mental models. In the end, trygve’s main contribution is to the left-brained side of computation — the enactment of scripts. Users still engage their right brain during program enactment but in modern computing, such activity is usually associated with the visual cortex. Identifying the right entities (objects) happens on the screen, and Model-View Controller (MVC) has been designed as the bridge between end user and computer in that regard. MVC and trygve can powerfully be combined to provide the most expressive links between the end user and the machine.

The source code of a trygve program may contain the following elements14:

class className {class declaration}…context contextName {. role roleName {. . role-script header () {role-script body} requires {role-player interface}. . …. }. …. context instance variable declaration. …. public contextName () {// the context constructor maps roleNames to role-players. . roleName = expression;. . …}

public system-operation-name () {. . system-operation script // this script reifies and triggers a use case.}. ……}

The code differs from Java with its two special keywords: context and role, words that have roughly the same meaning as in section 4: Ellen's Mental Model of Computing (cont). The trygve source code is a complete text that declares the program as a whole. This makes it

13 http://fulloo.info/Documents/trygve/trygve1.html

14 Example code in http://fulloo.info/Examples/TrygveExamples/


http://fulloo.info/Examples/TrygveExamples/

possible to analyze the program automatically and support functionality such as its typing system. BabyIDE and PP are based on Smalltalk. They lack the notion of a source code in closed form and can only provide dynamic typing. In trygve, the roles form an unordered set, while in BabyIDE and PP they form a directed graph that declares role visibility. The graph is also part of the programming language in BabyIDE. (Figure 18).

The DCI paradigm has been reified in several mainstream languages such as Ruby, C++, Scala, and Java. Also in Rune Funch's Marvin DCI language. 15

Stephan Hermann's ObjectTeams 16have a concept similar to the DCI role and share many of the properties of DCI. ObjectTeams creates a role by wrapping the role-player with a separate object, thus having several identities for an entity that is conceptually a single object. This does not cause any problems in many cases, but this object schizophrenia may cause malfunctioning that is hard to track down.17

----------------------Fragments/ideas:------------------------

For kids: EToys, Scratch, mainstream language (Python) pre-processors?

School curriculums to make everybody computer literate.

Carl Hewitt defined the Actor Model in 1973 as a mathematical theory that treats “Actors” as the universal primitives of concurrent digital computation.Carl Hewitt defined the Actor Model in 1973 an actor is a process like nodes in a neural networkImperative actors send an RPC destined for an actor with known interface, type, Relevant model for BabyIDE/IoT?https://www.infoq.com/articles/reactive-cloud-actorshttps://dzone.com/articles/distributed-systems-done-right-embracing-the-actor-model

DCI: sequential (synchronous). Actors is parallel; not studied here. Harder to read code. too abstract for Ellen.

15 http://fulloo.info/Examples/

16 http://www.eclipse.org/objectteams/

17 James O. Coplien, 2014: Why isn't it DCI if you use a wrapper object to represent the Role? http://fulloo.info/doku.php?id=why_isn_t_it_dci_if_you_use_a_wrapper_object_to_represent_the_role


http://fulloo.info/doku.php?id=why_isn_t_it_dci_if_you_use_a_wrapper_object_to_represent_the_role

http://www.eclipse.org/objectteams/

http://fulloo.info/Examples/

11. Summary and ConclusionTBD

There are many initiatives for teaching programming to non-professionals, particularly to kids. They are all targeted at the von Neumann model. I rejected these solutions in the introduction and deem them outside the scope of this article.

I set out to empower Ellen, a novice Personal Programmer, to harness the resources of her personal devices as well as the resources available over the Net. The first challenge was to offer her a mental model of her digital environment. I chose a model consisting of objects and objects only: "An object is an entity that encapsulates state and behavior that can only be accessed through the object's message interface.18" The second challenge was to base her IDE on a concept that she will experience as being simple and intuitive. I selected the idea of composition, an idea that Ellen learned early in life and that forms part of her intuition. It is very likely that she has experience with Lego, the toy where children compose structures from bricks and bigger structures from sub-structures recursively. There is a short leap to see the objects as the Lego bricks of computing and structures of communicating objects as structures of Lego bricks.

From Ellen's point of view, all objects are similar and are handled in the same way. They are shown as yellow starts in (Figure 34). Under the hood, they come from different sources and have different access mechanisms: The objects of the single, global machine are accessed over the Web. Ellen's IDE is implemented in Smalltalk. For security reasons, Ellen cannot be allowed to modify the Smalltalk class library, but she can instantiate its classes. Ellen can freely create and instantiate her personal classes. Mechanisms in BabyIDE maintains the illusion that all the objects appear as the same kind of entity.

Also fig 30Figure 34: Ellen's object computer.

ObjectComputer-1.png

18 Alan Kay coined the term object-orientation: "Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network" (Kay, 1993). Note that the attention is on the runtime, compile-time ideas such as classes are of secondary importance.


The DCI programming paradigm was launched in 2008 and has an active community centered around the [email protected] mailing list and its home page: http://fullOO.info. The community has adapted DCI to a number of programming languages. Contact the mailig list for details. DCI has been compared to Java in a controlled experiment that showed that DCI code is more readable than Java code (Valdecantos, 2016).

Personal Programming with its modified BabyIDE has been my solitary project financed with my pension. The IDE is a demonstration program and is not ready for general use. The next step should be to establish a project with its own financing and team of researchers.

Personal Programming has been demonstrated to a number of visitors. The few programmers among the visitors didn’t see the point; they neither needed DCI nor Personal Programming, thank you. All the non-programmers appeared to see the point and all had ideas about services they would like to develop for their own use. One of them, a farmer, had a number of useful applications. One was to monitor her beef calves. There was probably something wrong with a calf that was off its food and she should give it extra attention. Another was to monitor her cattle food silos; her program would alert her when the silos were nearly empty and help her select and order the next lot of grain feed. The farmer had been using computers for many years but had never written a program. She came with a pertinent observation: "This doesn't feel like programming at all." She was right, of course. Ellen's composition of her smart clock was more like setting up a playlist in a music server than programming in the conventional sense of the word. There was no source file, no compilation stage, and no concrete program. Instead, Ellen selected objects from her environment and applied the DCI paradigm to control the flow of messages that reifies her needs.

The response from the few non-programmer visitors was encouraging. I do not believe they would have been as understanding and creative if I had demonstrated how to write a simple Python program for the same purpose. I claim that the programming technology presented in this article will lead to programs that are easy to read, write, and grok for the Personal Programmer. Personal Programming has a low entry threshold, yet Ellen can learn more and do more until she can do everything that the single, global computer can do.

---------------------Fragments/ideas:------------------------

-------------------------- Conclusion ------------------------

Programming by composition is intuitive and a promising candidate for personal programming.

The hypothesis underlying this article is that communication-centric software such as provided by the DCI paradigm will be easier to understand for the layperson and more readable for the expert.

DCI is a paradigm for making code easy to read and grok.


"Programming by composition" is intuitive and easy to use. It is disruptive; opening a new world of programming.

---------Include farm examples?----------

Farming

Kraftforautomat-skadet okse -spiser ikke: Varsle

Kraftforautomat-Silo-tom-bestrille-velge: bestillingsskjema

fødsel-sensor-varsle: lys, kamera

Melketank-vaske-glemmeSlåPå

lyskontroll fjøs

-------------------------------------------------------------

DCI scales, so that Personal Programmers can grow from the novice to the expert without changing their fundamental mental model of computing.

Mainstream professional programmers target a stand-alone von Neumann computer where a program is a sequence of instruction to be executed by its CPU. Personal Programmers target a network of communicating computers where a program specifies how and why messages flow through selected objects to achieve a task. Programming by composition is a disruptive technology that can supersede the older sequential model for Personal Programmers.

--------------------- ----------------------- Yet another model -----------------------

The POJO model gives computers the capability to store and transform data. The DCI execution model enhances this model with a capability for controlling the communication between objects: Data storage is accomplished in an object’s state variables. An object’s apparent state can be derived, i.e., computed from other state. Data transformation is realized by an object’s own methods and in role-scripts. Data communication is executed by message interaction in the context of a network of objects that are identified by their roles (Figure 35).


Figure 35: The three cabilities of computersthreeCapabilities-2.gif

von Neumann machine >>> instance methods --- role-scripts <<< Kay O-O machineor:inside observer >>> own behavior collective behavior <<< outside observer

DCI adds data communicationas the third basic capability of computing,

the other two being data transformation and data storage

--------------------- Programming by composition -------------------

BabyIDE reifies the DCI paradigm into a non-intrusive extension of a Smalltalk image. I claim that a further extension, which I have called Personal Programming, regains the children while retaining the Smalltalk 76 scalability and more (see above).

PP based on innate capacity for composition; hides abstract complexity of von Neumann model with its 3GLs

'DCI provides powerful separation of concerns that enables formal code inspection. The Data objects are stand-alone so that their classes are not concerned with peer-to-peer collaboration. Therefore, each Data class can be isolated for code inspection and unit testing. Similarly, system behavior is divided into separate contexts for the system operations. Every context is isolated from the rest of the program and can be separately inspected and tested.

We believe that the Context-Oriented foundation will feel natural to many people because it builds on the well-known notion of assembling smaller things into bigger things. A context is built from objects. The 'glue' that keeps them together is the messages that flow between them.

A series of new products can be developed, each offering increased functionality while being backward compatible with earlier products. With time, it could develop into a preferred tool


for professional application programmers while systems programmers may stay closer to the hardware with assembly and 3GLs.

PP will open a market for both free and premium objects

The first release should be minimal, designed for the novice Personal Programmer and almost obvious to use.

The target group are people who need to program to achieve some personal goal.o I have aimed at the smart home as a first application. That market will be ready

for PP when there are millions of owners of smart homes who are frustrated at the complexity of their systems and will realize the benefits from a simple and unified way of controlling it.

o The education market (teachers) may come earlier. PP will let them focus on their subject since the threshold for beginning to use PP is low. Today, people talk about "teach the kids coding". That's a mistaken goal. It should be: "Teach the kids to harness computers to reach a goal outside the computer". Teach them to create simulations could be a first step.

PP can give people control over the Things in their smart home. That articular market will be ready when there are millions of people who struggle to control their smart home.


12. AcknowledgementsThe work that has led to the DCI paradigm, BabyIDE, and Personal Programming has taken many years of ups and downs. I could not have stayed the distance if had not been for the encouragement I received from men I deeply respect, the foremost being Dave Thomas and Bran Selic.

I have long known James O. Coplien (Cope) and thank him for many rewarding discussions over the years. Our common ground has been our focus on people. The value of a system is its value for its users. Users can be the end users of an application or its developers using a programming environment. We had both been following our separate paths when searching for a common truth we both have felt must be out there somewhere. On Aug 28, 2008, I launched a new programming paradigm I called DCI - Data, Context, and Interaction. It was accompanied by BabyIDE, an Interactive Development Environment written in Squeak19. I spread the good news to a large number of people over the Web. There was no response except one: Cope wrote: "Til lykke, Trygve. It's not often that one can claim two great life accomplishments in one life." At long last we joined forces to further the DCI ideas. I am grateful for Cope's invaluable contributions to this work. Also for the dissemination of DCI which could not have happened without him.

My sincere thanks to the active community centered around the [email protected] mailing list for their contributions to the DCI paradigm and its dissemination.

The BabyIDE implementation rests heavily on Traits. My sincere thanks to Nathanael Schärli, Stéphane Ducasse, Andrew Black, and Adrian Lienhard for providing this very pow-erful extension of the Squeak class paradigm.

The concepts of Personal Programming and Ellen's object computer stem in part from Smalltalk that was created at Xerox PARC by Alan Kay, Dan Ingalls, Adele Goldberg and the Learning Research Group .The value of their disruptive ideas cannot be overestimated.

19 BabyIDE works under Squeak version 3.10.2. It is not easily converted to later, more complicated versions.


13. BibliographyAlan Kay, A. G. (1977). Personal Dynamic Media. Computer(March 1977), 31-41.

Emery, F., & Thorsrud, E. (1976). Democracy at Work: The Report of the Norwegian Industrial Democracy Program (International Series on the Quality of Working Life).

Kay, A. (1989). User Interface: A Personal View. (Viewpoints Research Institute) Retrieved from http://www.vpri.org/pdf/hc_user_interface.pdf

Kay, A. (1993, March). The Early History of Smalltalk. ACM SIGPLAN Notices archive, pp. 69-95.

Reenskaug, T. (1973). Administrative control in the shipyard. Tokyo: ICCAS conference. Also at http://heim.ifi.uio.no/~trygver/1973/iccas/1973-08-ICCAS.pdf. Retrieved from http://heim.ifi.uio.no/~trygver/1973/iccas/1973-08-ICCAS.pdf

Reenskaug, T. (1977). Prokon/Plan - a Modelling Tool for project Planning and Control. IFIP Congress, 717--721.

Reenskaug, T. (n.d.). MVC, XEROX PARC 1978-79. Retrieved from http://folk.uio.no/trygver/themes/mvc/mvc-index.html

Wiegers, K. E. (2002). Seven Truths About Peer Reviews. Retrieved from http://www.processimpact.com/articles/seven_truths.html

Old References to be moved to Bibliography

Google: object identityhttps://www.google.no/search?q=XHTTP&oq=XHTTP&aqs=chrome..69i57.2471j0j8&sourceid=chrome&ie=UTF-8

[DCI-Wiki] Data, Context, and Interaction; http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction

[Holbæk-Hanssen-75]Holbæk-Hanssen, E., Håndlykken, P., Nygaard, K.: "System Description and the DELTA Language". DELTA report No. 4. Second printing. Norwegian Computing Center, 1975.

[IFIP-66] IFIP-ICC Vocabulary of Information Processing; North-Holland, Amsterdam, Holland. 1966; p. A1-A6.


[OORAM-92]

Trygve Reenskaug: Working with objects. The OOram Software Engineering Method. Manning/Prentice Hall 1996. ISBN

0-13-452930-8.

Out of print. Late draft may be downloaded here .PDF

also

Trygve Reenskaug et.al.: OORASS: Seamless Support for the Creation and Maintenance of Object-Oriented Systems. JOOP 27-41 (October 1992)

[Reed-05] David Reed: Organization of Programming Languages. Creighton University, 2005

[ReeCop-09]

Reenskaug, T., Coplien J.; The DCI Architecture: A New Vision of Object-Oriented Programming. An article starting a new blog: (14pp)

http://www.artima.com/articles/dci_vision.html

[Ree-09] Reenskaug T.; . [WEB PAGE] http://heim.ifi.uio.no/~trygver/2009/commonsense.pdf

[UML-11]

OMG Unified Modeling LanguageTM (OMG UML), Superstructure. Version 2.4.1; Object Management Group; Aug.2011;

http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF

[Webster] http://www .merriam-webster.com

[Wikipeadia]http://en .wikipedia.org/wiki/

The work is released under CC-BY-SA . See http://cr eativecommons.org/licenses/by-sa/3.0 /


14. Appendix-1: BabyIDE code for Ellen's Smart Alarm Clock.

" Exported from Squeak 7179-basic.348 last modified on 21 November 2017 by: Trygve"

14.1 Code generated by Ellen's gestures

projection: Context-Classes

Class: EllenAlarmCtxBB1Context subclass: #EllenAlarmCtx instanceVariableNames: '' category: 'BBa11PP-Context'

instanceMethods: role bindingFORECASTER ^ResourceDictionary at: #weather

TIMER ^ResourceDictionary at: #clock

WAKERUPPER ^ResourceDictionary at: #speaker

14.2 Code "written" by Ellen

projection: EllenAlarmCtx-Interactionrole-scripts: FORECASTERcheckWeather FORECASTER expectedRainfall = 0 ifTrue: [WAKERUPPER wakeMe ]

role-scripts: WAKERUPPERwakeMe WAKERUPPER soundAlarm

role-scripts: TIMERwaitTillMorning TIMER waitUntil: '15:13'. FORECASTER checkWeather.

14.3 Data classes are are part of Ellen's infrastruture

projection: Data-classesBB1ResourceObject subclass: #BBa11Alarm instanceVariableNames: '' category: 'BBa11PP-Data'

instanceMethods: API

soundAlarm (AbstractSound majorScaleOn: PluckedSound default) play.


instanceMethods: accessing

balloonText | strm | strm := TextStream on: Text new. strm nextPutAll: 'Bedside Alarm' asText allBold." strm cr; nextPutAll: 'self soundAlarm' asText allItalics." ^strm contents

defaultRoleName ^#WAKERUPPER

resourceID ^#speaker

BB1ResourceObject subclass: #BBa11MetOffice instanceVariableNames: 'nextAnswer' category: 'BBa11PP-Data'


expectedRainfall " Always return 0 for demo purposes. " ^0


balloonText | strm | strm := TextStream on: Text new. strm nextPutAll: 'Weather forecast' asText allBold." strm cr; nextPutAll: 'self expectedRainfall' asText allItalics." ^strm contents

defaultRoleName ^#FORECASTER

resourceID ^#weather

BB1ResourceObject subclass: #BBa11PP instanceVariableNames: '' category: 'BBa11PP-Data'

BB1ResourceObject subclass: #BBa11Time instanceVariableNames: '' category: 'BBa11PP-Data'


delayFor: seconds (Delay forSeconds: seconds) wait.

waitUntil: timeString | secondsDelay | secondsDelay := ((Time readFrom: (ReadStream on: timeString)) subtractTime: Time now) asSeconds. secondsDelay < 0 ifTrue: [secondsDelay := secondsDelay + (24*60*60)]. Transcript cr; show: 'Timer delay = ' , secondsDelay printString , ' seconds.' . (Delay forSeconds: secondsDelay) wait.


balloonText | strm | strm := TextStream on: Text new. strm nextPutAll: 'Timer' asText allBold.


" strm cr; nextPutAll: 'self waitUntil: ''hh:mm'' ' asText allItalics." ^strm contents

defaultRoleName ^#TIMER "#CLOCK"

resourceID ^#clock

classMethods: instance creation


15. Appendix-2: Classification of sharing technologies

TBD

It is interesting to note that the object computer model opens a new technology for sharing software. We see from Table 1 that of the three technologies, the third is least dependent on the environment. <New idea that could do with more thinking>

Table 1: Classification of sharing technologies

Sharing technology

Sharing

1 Subroutines/procedures

FORTRAN, Algol, C, and friendsBehavior: Sharing subroutine/procedure library: APIsExample: https://en.wikipedia.org/wiki/Carbon_(API)State: No sharing or a shared database.API applied within a single program.Collapses if you redefine programming language.

2 Class Java, Ruby, & Friends (C++?)Shared class library.Example: https://docs.oracle.com/javase/8/docs/api/Library applied a within a single program.Collapses if you redefine the mother of all classes: class Object.

3 Objects The Object ComputerObjects/services available through communication network.Example: https://www.yr.no/place/Norway/Oslo/Oslo/Meteorologisk_institutt/data.html#phpDCI Context binds roles to objects, known by their identity and external interface. Collapses if you redefine communication standards.Objects used within the confines of a computer network.Collapses if you redefine communication standards.


16. Appendix-3: An abstraction hierarchy of the BabyIDE implementation

TBD

Ellen's world is a uniform world of objects that represent various things and services. They range from the remote weather service through her local bedside alarm to objects within her computer like the timer service. Her window into this world is the computer used for her demonstration. It is actually a regular PC with its Intel chips, Windows 7 OS, Squeak version 3.10.2., and our PP implementation. This complex system can be simplified into the 5-level abstraction hierarchy described below.

Figure 6 showed how the DCI Context acts as a barrier between the Personal Programmer and the infrastructure below it. There are many ways to implement this infrastructure, we decide to look closer at the way it is done in our own computer. We know that the heart of the hardware is an Intel processor and that it has a von Neumann system architecture (Figure 1).

We have zoomed in on (Error: Reference source not found) to see a layered architecture that schematically describes the implementation of PP on our computer.

In a bit more detail, but still very schematically, we zoom in to find 5? abstraction levels.

Level 0: hardware.

An Intel chip can have millions of transistors on that are combined into gates that are combined into components. Components are combined into larger components recursively. At the top of this hierarchy, we find components that reify our computer's microprogramming instruction repertoire.

People share VLSI integrated circuits at this level.

Level 1platform: Microprogramming instruction repertoire.

Microcode is "a technique that imposes an interpreter between the hardware and the architectural level of a computer". As such, the microcode is a layer of hardware-level instructions that implement higher-level machine code instructions or internal state machine sequencing in many digital processing elements. (Wikipedia)

Level 1 body: Microprograms.

Microinstructions are combined into microprograms. Some of these programs reify the instruction repertoire of our computer's CPU.

There is no public sharing at this level.

Level 2 platform: CPU Instruction repertoire.

We here find instructions for storing data, transforming data, and for communication with entities in our computer's environment.


Level 2 body: CPU executables.

This is where we find most computer programs such as applications and operating systems.

A computer program is a collection of instructions that performs a specific task when executed by a computer. A computer requires programs to function.

A computer program is usually written by a computer programmer in a programming language. From the program in its human-readable form of source code, a compiler can derive machine code—a form consisting of instructions that the computer can directly execute. Alternatively, a computer program may be executed with the aid of an interpreter. (Wikipedia)

One kind of CPU programs define a virtual computers with a different instruction repertoire. For example, a FORTRAN runtime system sustains the illusion of programming a FORTRAN computer. Similarly, a Smalltalk runtime system sustains the illusion of programming a Smalltalk computer.

People share applications, subroutine and procedure libraries, APIs, etc.

Level 3: The Smalltalk Virtual Machine (ST VM).

The ST VM is a virtual computer with many points in common with our concrete computer of level 0. Both have stored programs that can be manipulated as data. The level 0 memory consists of a closed collection of bytes while the level 3 virtual memory consists of a closed collection of objects in its image. The level 0 behavior is controlled by its microinstructions while the level 3 behavior is controlled by method objects.

An ST object is an instance of a class and encapsulates state and behavior. It has an immutable identity that is unique within the image. Its instance variables represent its state and its named methods control its behavior.

Level 4 platform: Classes

The level 3 ST VM provides an instruction repertoire that can

Create classes.

Create Objects as instances of classes.

Remove unused objects with automatic garbage collection.

Execute methods (instances of class CompiledMethod) in a stack machine.

Send messages

Receive messages

Level 4 body: Programming with classes.

An ST object is an instance of a class that declares how it is constructed. The ST-VM separates operations for sending messages from the methods that receive them. The class says everything about how an instance will handle the messages it can receive, but nothing about the senders of those messages or their reason for sending them. The class also says everything about the messages an instance can send, but nothing about the receivers of those messages or what they will do with them. This makes an ST object stand-alone; there is no concept of a program involving message passing.


The essence of object=orientation is that objects collaborate to achieve a goal, but ST does not support this collaboration. This deficiency is mitigated with what we like to call class-orientation but it is usually called object-orientation. Knowing the goal, the programmer designs the message flow offline, possibly using a tool like UML. The design answers three essential questions:

1. What are the objects?

2. How are they interlinked?

3. What do they do?

The programmer then writes specialized class declarations for each stand-alone object with methods for its behavior. Links between objects are split in two: a sender end and a receiver en. The code does not express how the two will be connected at runtime and [GOF-95] p. 22 can write: "…, it's clear that code won't reveal everything about how a system will work." We regard the widespread use of class-oriented programming as most unfortunate since it prevents developers from reasoning about their code and forces them to rely on testing. (section 2).

The DCI programming paradigm connects the links and the programmer codes coherent collaborations. There is no need for specialized classes and the remaining classes are reduced to declaring classes for simple, stand-alone objects. These declarations are reminiscent of the level 1 micro instructions. Where a microprogram reifies one stand-alone CPU instruction, a class declaration reifies one kind of stand-alone Data object.

Level 4 Class declarations are like the microcode of objects.

On this level, people share classes in the form of class libraries such as the Java class library.

Level 5 platform: DCI Context machine

Level 3 programs reify (section 4: Ellen's Mental Model of Computing (cont)) in the form of a DCI Context machine . A part of the platform is class Context. It is the superclass of all Contexts where each Context reifies one or more use cases or system operations. The Context script compiler is like the common ST method compiler except that its environment is a Context with its roles rather than a class with its instance variables. Another part of the platform is BabyIDE which is normally used for all DCI programming.

Level 5 programs: Object=DCI Context programming

This level is a non-intrusive extension of level 4: Classes. It is divided into two sublevels: the Context subclass and one or more Interactions.

A Context class is a subclass of the platform class Context. Its main responsibilities are to:

provide methods that reify the context's provided message interface, declare the roles and the links between them, map all roles to objects in an atomic operation, form the environment for the compilation of role methods, trigger the execution of one or more Interactions,' let an instance be the environment for the execution of role methods.


An Interaction specialize roleplaying objects according to their responsibilities in the overall Interaction. The specializations are in the form of role-scripts that ephemerally augment the objects behavior when executed at runtime. This contrasts with the compile time specializations of class-oriented programming. Further, the Interaction as a whole is the context20 of the execution of a DCI role-script while an isolated class is the context of the execution of an ST instance method.

16.1 Realizing the Object Computer

We started this section with the idea of a Single, global machine (SGM). Our first model was to see its parts as objects according to Alan Kay's definition of object=orientation, making it resemble a gigantic ST image.

20 Note lower case c!


17. DUSTBINMaterial that has been deleted from the article, but may be moved back in later.

Alan Kay's group at Xerox PARC worked on his vision of the Dynabook: A Personal Computer for Children of All Ages 21. Kay's mental model of computing marked a complete break with the past; he called it object-orientation:

"Smalltalk’s design–and existence–is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages. Philosophically, Smalltalk’s objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealisations of concepts–Ideas–from which manifestations can be created. That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea–which is a-kind-of itself, so that the system is completely self-describing– would have been appreciated by Plato as an extremely practical joke.

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole–like data structures, procedures, and functions which are the usual paraphernalia of programming languages–each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computer all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.

Though it has noble ancestors indeed, Smalltalk’s contribution is a new design paradigm–which I called object-oriented–for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modeling the ever more complex dynamic systems and user relationships made possible by the silicon explosion."22

Object systems divide memory into two parts; A heap and a stack. The heap is a part of the memory that is reserved for objects. The stack is a LIFO list that acts as both a computation stack and a call stack with method activation records. The memory management system is part of the runtime system, often called the virtual machine (VM).

When a class is instantiated, the VM places the new object in an available part of the heap. The block of memory that represents the object includes a link to the object's class (an object) and a slot for each instance variable. An object is encapsulated, which means that its state and behavior can only be accessed through messages. The object has an immutable and globally unique identity (ID). The VM maintains a dictionary that binds object IDs to the location of the object on the heap. (Conceptually, that is. There are many different implementations.) An object

21 Kay 72

22 [Kay-93]


stays on the heap until it is no longer accessible and the VM removes it automatically with its garbage collector.

Our mental model of computing is the object computer described in section Error: Reference source not found as it is reified in Squeak/Smalltalk with its BabyIDE extension. The DCI execution model is based on the BabyIDE implementation.

For comparison, we also include a conceptual description of the runtime behavior of a conventional OO program. We call it a POJO model (Plain Old Java Objects). In reality, we describe the Squeak/Smalltalk execution of a class oriented program, assuming that the Java runtime is similar in principle even if it differs greatly in detail.

We present an object system as seen from two observation points (Figure 4). The POJO model observes an object seen by an inner observer (section 17.1). It describes the object's inner construction, i.e., its class.

In the DCI model , an outer observer sees the interaction of participating objects in a Context. (section Error: Reference source not found).

17.1 The Plain Old Java Object (POJO) Execution Model

We imagine a Smalltalk class that reifies Ellen's weather service and use it as an example. (Figure 36) illustrates an instance of this class. A dashed square denotes the object, rounded, dashed rectangles denote its methods, and curved, red arrows denote a message flow.

Figure 36: An object seen from inside its encapsulation boundary. (Runtime-Object.10.png)

A Smalltalk program exists as objects in the Smalltalk image. A new class object is created programmatically with a message to its superclass object:

superclass subclass: #NameOfNewClass…..

There is thus no language for specifying a complete Smalltalk program, only a default language for specifying the methods of an existing class. Source methods are translated by the class' compiler into sequences of instructions for a stack-oriented interpreter. The instructions are eight-bit numbers called byte-codes. (Figure 37).

Message transmission is as follows:

1) A calling method in the sender executes a message send operation. The message includes the sender, the receiver, the message name, and possible message arguments.

2) The execution of the calling method is suspended.


3) The VM adds a method activation record to the top of the stack as illustrated in (Figure 37). The activation record includes any actual parameters, local variables, and a link to the receiver.

4) The VM follows the receiver's class pointer to find the class object with its message dictionary where it looks up the method using the message name as a key. The VM repeats the lookup along the superclass chain if necessary. (The message is replaced by a doesNotUnderstand- message if no method is found. This messages always finds a method, its default behavior is to raise an exception).

5) The VM augments the activation record with a link to the selected method and a program counter for this method.

6) The VM triggers the execution of the byte-codes of the selected method in the context of the receiver (Figure 37). A method can access its local variables and the receiver’s instance variables23. It can also send messages to self and other objects it knows about, and the process is repeated from point 1) above. It is important to note that a method is executed in the context of the receiver object; the class is a mere repository. The class neither receives nor sends messages.

7) The VM removes the activation record from the stack upon method completion and resumes the execution of the calling method from where it was suspended.

Figure 37: Memory locations that are visible in an instance method during execution.

(RuntimePOJOMethodScope.png)

17.2 The Connnected Society

The emerging single, global machine is art of something greater called the connected society. The connected society share a multitude of different data targeted at humans: Text, pictures, music, etc. There is also technical data targeted at machines in machine-to-machine communication (m2m). The functioning of his communication requires that a vast number of standards on different levels are in place. The International Telecommunication Union has published a discussion and overview in (Choi & Kim, 2016). An excerpt from (p.112):

23 Static, global and other special variables may also be visible; they are not discussed here.


"Principles for Data Eco-society

The future data eco-society is based on the ability of everyone to share data, access data, and transform that data into knowledge. Here are the basic principles that are essential for the future data eco-society:

(Open) Open data can be used in various parts of human life and business. It makes it easier for people to access valuable data. From the viewpoint of standardization, "open" data is available and within the reach of the public, without barriers for its reuse and consumption. The future data eco-society provides open, equal, inclusive, and universal access of data to anyone who wants it.

(Trust) Data trust (including security and privacy) is a prerequisite for the development of the future data eco-society. Published documents should be digitally signed and include information like publication/creation date, authenticity, and integrity. Digital signatures help people trust that the data has not been modified since it was published. This trust is required to reduce all kinds of risk when it comes to using open data.

(Equal Opportunity) The opportunity to benefit from open data should be equally available to everyone. This works when open data is not restricted by privacy, security, and privilege limitations as well as copyright, patent, and trade regulations. This requires some harmony between the private sector and the public/social/government organizations.

(Linked Open Data) Data is composed of sets of data records linked together and organized by those links. These linked lists are useful for retrieving and identifying the properties of the data records. Metadata includes the descriptions and other related information of those links. These links and metadata information help define the relationship between data.

(Collaboration) ICT technologies help open data freely benefit everyone. The ability to better share information encourages innovation by encouraging collaboration. It is important to think about how open data standards can technically and legally ensure users’ access to relevant and reliable public data. To promote the spread and sharing of open data, step-wise standardization is essential. "
