Personal Programming - Universitetet i oslofolk.uio.no/trygver/themes/Personal/PP-009 - Copy (4).pdf · 2019-03-07 · programming code and which is, consequently, more accessible

PP-009 - Copy (4).docx 2019-03-07 11:35 ©2018 Trygve Reenskaug Page 1 of 88

Personal Programming Trygve Reenskaug1

Abstract

TBD

Computer programming celebrated 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 in Internet, a single, global machine. Baby's control panel has morphed into graphical user interfaces (GUIs) 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 can focus on immediate needs.

I introduce Loke, a personal object computer that is a network of collaborating personal and public objects such as an extended IoT (Internet of Things). Loke is programmed according to the Data, Context, and Interaction (DCI) paradigm. The Data are the objects; the Context is a configuration of objects that play their roles to jointly achieve a particular goal; and the Interaction is the code that drives their collaboration.

The goal of DCI is to provide readable code that is significantly more intuitive than traditional programming code and which is, consequently, more accessible to a broader community. The code is so comprehensive that the expert can enjoy using it. The embryonic Loke exists as an experiment in my laboratory while the DCI programming paradigm has been tested on real-life problems.

A new programming environment, BabyIDE, targets Loke. Different GUIs support programmers with different mental models of computing depending on their interests and proficiency. An MVC system architecture makes the program fade into the background and lets the user concentrate on satisfying their immediate needs. I give two examples: one for experts and another for novices. A video2 illustrates the novice IDE.

My approach is experimental and my laboratory is a software model of Loke. I considered two alternative foundations for its implementation and rejected the von Neumann machine because it lacks the essential peer-to-peer communication. I landed on Smalltalk because it is a universe of communicating objects much like Internet, the single, global machine.

Comment [B1] The abstract strikes me more like an introduction, since it is more than a concise summary of the contents, which is what I believe an abstract is supposed to be. The opening paragraph is a rather loquacious and somewhat indirect introduction to the problem being addressed. I think it could be stated more concisely and more explicitly. Comment [B4] Is this bit perhaps too detailed for an abstract? (it’s a judgement call, I guess)

keywords:

Personal Programming, Novice Programming, Single, global Machine, IoT, Smart Home, MVC, DCI, BabyIDE, Smalltalk, Squeak, Object Orientation

1 Department of Informatics, University of Oslo; mailto: trygver'at'ifi.uio.no; http://folk.uio.no/trygver/ 2 http://folk.uio.no/trygver/themes/Personal/EllenVideo.mp4

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


Table of Contents A. Prologue ...................................................................................................................................... 4 B. Novice Programming .................................................................................................................. 9

B.1. Ellen's Smart Alarm Clock .......................................................................................................... 10 B.2. DCI is Ellen's Mental Model of Computing ................................................................................ 12

B.2.1. Ellen's Data ...................................................................................................................... 14 B.2.2. Ellen's Context ................................................................................................................. 14 B.2.3. Ellen's Interaction............................................................................................................. 15

B.3. A new way of programming ........................................................................................................ 16

C. Loke: Ellen's Personal Object Computer .................................................................................. 17 C.1. A new technology for sharing ...................................................................................................... 18 C.2. Prokon's Computer-Assisted Collaboration ................................................................................. 19 C.3. Professional Programming with DCI ........................................................................................... 20

C.3.1. The need for simplicity .................................................................................................... 20 C.3.2. Remove bugs early ........................................................................................................... 21 C.3.3. Prepare for change ........................................................................................................... 22 C.3.4. An important remark: ....................................................................................................... 22

D. The BabyIDE implementation .................................................................................................. 23 D.1. The Data objects .......................................................................................................................... 23 D.2. The Context class: The topology of the execution graph ............................................................. 26 D.3. The Context instance: The execution environment ...................................................................... 27 D.4. The Role Scripts .......................................................................................................................... 27 D.5. The Interaction ............................................................................................................................. 29

E. Epilogue .................................................................................................................................... 32 E.1. Further work ................................................................................................................................ 32

E.1.1. IoT testbed for PP ............................................................................................................ 32 E.1.2. Persistent objects .............................................................................................................. 32 E.1.3. Scratch programming interface ........................................................................................ 33 E.1.4. Choose programming environment for DCI .................................................................... 33 E.1.5. Organize the Data objects ................................................................................................ 34 E.1.6. Error handling .................................................................................................................. 35

E.2. Other initiatives ........................................................................................................................... 35 E.3. Summary and Conclusion ............................................................................................................ 37 E.4. Acknowledgements ..................................................................................................................... 42 E.5. References ................................................................................................................................... 43

F. Appendix 1: Smalltalk .............................................................................................................. 46 G. Appendix 2: BabyIDE .............................................................................................................. 49

G.1. The shared heading of all BabyIDE browsers ............................................................................. 49 G.2. The Interaction Browser .............................................................................................................. 50 G.3. The Context Class browser .......................................................................................................... 51 G.4. The Data Class browser ............................................................................................................... 52 G.5. Appendix 3: ProkonPlan; An Example ........................................................................................ 54

H. DUSTBIN ................................................................................................................................. 57 H.1. The abstraction hierarchy of the BabyIDE implementation ........................................................ 66 H.2. Abstraction Level 0: hardware. .................................................................................................... 66

H.2.1. Abstraction Level 1: Microprogramming ........................................................................ 66 H.2.2. Abstraction Level 2 platform: CPU Instructions .............................................................. 67 H.2.3. Abstraction Level 3: The Squeak Environment. .............................................................. 67 H.2.4. Abstraction Level 5: DCI Context machine ..................................................................... 68

H.3. Appendix: Squeak reverse engineering ....................................................................................... 71 H.4. SRE Introduction ......................................................................................................................... 72 H.5. The Demo Program ..................................................................................................................... 73 H.6. SRE Execution Tracer. ................................................................................................................ 73 H.7. SRE Object Inspector for investigating a Single Object .............................................................. 73 H.8. SRE Context Browser for Displaying an Object Substructure. ................................................... 74

H.8.1. Projection 1: Domain Collaboration ................................................................................ 75 H.8.2. Projection 2: Instantiation and Inheritance hierarchies .................................................... 77


H.8.3. Projection 3: The Stepping Collaboration ........................................................................ 77 H.8.4. Projection 4: The Instantiation Hierarchy ........................................................................ 80

H.9. SRE Conclusion ........................................................................................................................... 82 H.10. SRE Acknowledgements ........................................................................................................ 83 H.11. Old, unused References .......................................................................................................... 83 H.12. Levels of abstraction .............................................................................................................. 85


A. Prologue

Modern computer programming celebrated its platinum jubilee on the 21st of June, 2018. Exactly 70 years earlier, the world's first programmer wrote the world's first program, stored it and executed it in the world's first electronic, digital, stored-program computer at the Victoria University of Manchester, England. The architecture of the computer, affectionately known as Baby , followed the then well-known von Neumann model (Figure 1). Baby is morphing into billions of communicating computers, many of them connected into a single, global machine. (Kelly, 2008).

Figure 1: The von Neumann model forms a solitary system. vonNeumann-3.png

Like a computer, an object is an entity that encapsulates state and behavior and has a globally unique identity. The state is in the form of references to other objects. Object behavior is triggered by received messages; the object neither knows the sender of a received message nor its reason for sending it. The triggered behavior can cause a change in the state of the object and also make the object send messages. Generally, the object neither knows the identity of the receiver of a sent message sends nor what the receiver will do with it. In short, the object is stand-alone and unaware of any context.

In software engineering and computer science, abstraction is the process of removing physical, spatial, or temporal details or attributes in the study of objects or systems in order to more closely attend to other details of interest3. A common abstraction on objects in programming and computer science is the class abstraction. It is supported by a multitude of languages such as Java and Ruby:

1. An object is an instance of a class. 2. The class discloses the inner construction of the object. 3. The instances of a class form an unordered set that hides the identity of its

members. 4. An instance of a class has no information about its environment, i.e. its

context

Just like a single gear in a clockwork, an object by itself isn't very interesting. The essence of object-orientation is that objects collaborate to achieve a goal. The alternative role abstraction describes an object in the context of its collaborators:

1. An object is an entity with an immutable and globally unambiguous identifier4.

2. The object provides an interface that can be invoked by messages from itself or other objects.

3. The object plays a role in its collaboration with other objects. 4. The object's encapsulation hides its inner construction.

3 https://en.wikipedia.org/wiki/Abstraction_(computer_science) 4 See for example https://en.wikipedia.org/wiki/Object_identifier

https://en.wikipedia.org/wiki/Abstraction_(computer_science)

https://en.wikipedia.org/wiki/Object_identifier


The class and role abstractions are complementary: what's exposed in in the class abstraction is hidden in the role abstraction. Conversely, what's exposed in the role abstraction is hidden in the class abstraction.

The class and role abstractions are complementary: What's exposed in in the class abstraction is hidden in the role abstraction. Conversely, what's exposed in the role abstraction is hidden in the class abstraction.

My style of research is to experiment with software in my laboratory. I considered two alternative foundations for this laboratory. I rejected a von Neumann machine because it lacks the essential peer-to-peer communication. I landed on Squeak, a version of Smalltalk, because it is a universe of communicating objects much like the single, global machine. For both, the concept of an object is the same in model and reality when it is viewed in the role abstraction but different when viewed in the class abstraction.

I merge the objects of a distributed machine such as the Internet with a personal universe of objects such as the objects of my Squeak laboratory and get a personal object computer (Figure 2). I name it Loke after a powerful but somewhat sneaky god in Old Norse mythology who sometimes assists the gods and sometimes works against them.5 The Loke computer is personal and private in the sense that a smartphone is personal and private. It is an instance of a general platform that is personalized by augmenting it with data such as address books, bookmarks, letters, and personal programs according to the needs and preferences of its owner.

Figure 2: Loke,Ellen's Loke with its personal and public objects. ObjectComputer-4.png

The ground rules for Loke are6:

• Everything is represented by an object • Objects have their own state (in terms of objects) • Objects communicate by sending and receiving messages (that in are

objects). • Objects have behaviors (e.g., methods and scripts) that define the meaning

of received messages. • An object is an instance of a class (which is represented by an object).

The instruction repertoire of the Baby computer was realized in electronic circuits that interpreted its instructions. Today, a typical von Neumann computer has replaced some

5 Loke is sometimes called Loki. He can take on many different shapes according to whim. https://en.wikipedia.org/wiki/Loki#Scandinavian_folklore 6 Inspired by (Kay, 1993)

https://en.wikipedia.org/wiki/Loki%23Scandinavian_folklore


of the hardware circuits with microprograms that realize the computer's instruction repertoire. Similarly in Smalltalk, the instruction repertoire of an object is realized by methods declared in its class:

Classes can be seen as the microcode of object-orientation.7

In a von Neumann computer, a program is a collection of instructions for performing a specific task. In Loke, the behavior of a program emerges from each of its objects behaving according to its nature. There is no notion of a program in closed form that controls the message flow.

The Data, Context, Interaction (DCI) programming paradigm embraces the notion of programming Loke: System state is declared as Data in the class abstraction; System behavior is achieved by Contexts that muster participating objects to play their roles in Interactions 8. This DCI model of computing is on an abstraction level above the von Neumann model and builds on it.

The operators of the Manchester Baby computer worked it through a control panel. This panel has morphed into graphical user interfaces (GUIs) that empower each and every one of us to augment our intellect.9 The consequences are deeply radical for individuals and society alike. We still find archaic control panels in everyday products. Two examples from my kitchen spring to mind: My dishwasher and my electric cooker both confuse me with obscure icons and button-presses. Even worse is my local "Internet of Things" with its VCR and TV and their multi-button remote controls.

MVC, Model - View - Controller is a conceptual model of the GUI (Figure 3). (Reenskaug, 1978). The User experiences MVC as an extension of their mind. The "magic" of (Figure 3) is achieved by first making the computer's digital model correspond to the user's mental model of the domain and second by choosing well-known representations (i.e., languages) for presenting the Model information in the Views so that it can be readily intuited by the User. An invisible Controller sets up the Views in a window on the screen and coordinates them by making a selection show itself in all Views simultaneously. The Users no longer feel they are running von Neumann computers but achieve their goals by interacting directly with their mental model through the Views. A significant side effect of a successful GUI is that the underlying computer fades into the background in the user's mind.

Figure 3: MVC MVC4.png

A program for the Baby computer was a sequence of instruction that were copied into its memory and the execution started with its first instruction. The general workflow has essentially remained unchanged from the beginning to this date: Write the program text;

7 https://en.wikipedia.org/wiki/Microcode 8 https://en.wikipedia.org/wiki/Data,_context_and_interaction 9 https://en.wikipedia.org/wiki/Graphical_user_interface#History

https://en.wikipedia.org/wiki/Microcode

https://en.wikipedia.org/wiki/Data,_context_and_interaction

https://en.wikipedia.org/wiki/Graphical_user_interface%23History


load it; and execute it on a von Neumann computer. Modern GUIs have changed the nature of computer use for almost all categories of users. A notable exception is a large group of mainstream computer programmers who have excluded tables, graph-based representations, etc., as viable media for program specification.

In this article, I explore how the DCI model of computing can be combined with MVC-based programming tools to help a broader category of computer users master computer programming. I call them personal programmers to distinguish them from the professionals. While a Professional Programmer is a highly trained expert, the Personal Programmer writes programs for personal use on their Loke and values simplicity and convenience over programming sophistication. I propose that they are best served by a multi-media Integrated Development Environment such as BabyIDE. The objects of the resulting programs are distributed among participating objects and are represented as an MVC Model.

Some of the Model's objects will be private, some will be shared. The shared objects must be unchangeable just as the objects of a certain release of Smalltalk are unchangeable. They may be different in a new release but they are then different objects with different IDs.

Views on the Model let the programmer work with the program seen in different projections. The projections are like an engineering projections with heir plan and side views of a solid (Figure 4).

Figure 4: Engineering drawing of a solid in three projections.10 First_angle_projection.png

Different parts of the Model can be handled by different Views, pre-defined, or created automatically. Interactive Development Environments, IDEs, can be created for different categories of users. Novice users can enjoy a low entry threshold with simple Views while an expert user will appreciate the power of expression of a high abstraction level. Both build on the same conceptual Model and the transition from novice to expert can be a smooth growth guided by the Personal Programmer's increasing needs.

To make the discussion concrete, I have chosen to exemplify the DCI/MVC technology by focusing on personal programming of Internet of Things (IoT) applications. I could, of course equally well have chosen differently.

This article is an interim report from an ongoing project. The rest of the article is organized in four parts and two appendixes:

Part B: Novice Programming. Ellen, a novice Programmer, has a simple problem that she solves through a simple View on the program. I illustrate how she programs a smart 10 Picture ©Emok 2008, https://commons.wikimedia.org/w/index.php?curid=4280545 reproduced by permission

https://commons.wikimedia.org/w/index.php?curid=4280545


alarm clock that will wake her in the morning if the weather forecast promises a dry day (B.1). An amateur video illustrates the idea11. Ellen's DCI-based mental model of computing will evolve in her mind as she creates more and more programs and gains programming experience (B.2). Her smart alarm clock heralds a way of programming a structure of communicating objects rather than a stand-alone CPU as we find it in a von Neumann machine (B.3).

Part C: Loke. I discuss the nature of Loke and how it how it can be used.

Part D: The BabyIDE implementation. BabyIDE is based on DCI and implemented as a non-intrusive extension of my Squeak laboratory. The DCI software comes at the top of an abstraction hierarchy starting with the hardware microcode and ending with the DCI Interaction.

Part E: Epilogue. (E.1): Some work that remains to be done, (E.2): Other initiatives that are related to personal programming, (E.3): Summary and conclusion, (E.4): Acknowledgements, (E.5): References. Web references are in footnotes.

Appendix 1: Smalltalk: There is more to Smalltalk than is generally recognized.

Appendix 2: BabyIDE: A detailed description of BabyIDE with its tools and a comprehensive example with an architecture that combines MVC with DCI.

11 http://folk.uio.no/trygver/themes/Personal/EllenVideo.mp4

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


B. Novice Programming

I recently observed a two year-old girl, Selma, poking the TV screen and getting 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 before she learns to talk. I expect she will later find it natural to bend her devices to gratify her immediate demands. Personal Programming (PP) is what a person does 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 their 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 the share market. All of them want to take control over their environment with its devices and services; they need to become computer literate. People experience their computer through its user interfaces, and an Interactive Development Environment (IDE) facilitates their writing process. I have experimented with an IDE for inexperienced Programmers. I call it BabyIDE/Novice and have three requirements:

1. BabyIDE/Novice shall provide a low entry threshold by building on an idea that is well known to a novice programmer. The IDE shall protect the programmer from the complexities of the hardware and its programming languages by working on a higher abstraction level. I have chosen the idea of composition for its foundation; an idea I believe is shared by most if not all humans. (The well-known Lego toy lets children compose their projects from small bricks).

2. BabyIDE/Novice shall help the novice build a comprehensive mental model of computing. This is achieved by displaying the generated code.

3. Problems to be solved with BabyIDE/Novice shall scale from the first, small projects of the novice to the larger projects he or she can tackle as she learns to become an expert. This is achieved by building on the Loke model of computing.

I have created a proof-of-concept implementation of BabyIDE/Novice to demonstrate its principles. This Part describes a demonstration of the program using the terminology of the novice but aims its contents at the mentor who will demonstrate it. Readers of this part are expected to have intuited the idea of an algorithm from using the Scratch programming language or similar12.

12 https://en.wikipedia.org/wiki/Scratch_(programming_language)

https://en.wikipedia.org/wiki/Scratch_(programming_language)


B.1. Ellen's Smart Alarm Clock Households are in danger of being overwhelmed by disruptive smart home technologies (Figure 5). I expect there will be many such households. I design my solution for 100 million home owners, just to pick a large number, and single out Ellen to represent any one of them. Ellen owns a smart home with an IoT that connects to her many Things. The IoT is again connected to the Web and thence to the whole Internet. This gives Ellen access to a vast number of resources that she can muster to serve her needs.

Figure 5: Ellen's Internet of Things PP-ProgrammingForAll.png

Ellen challenges us with her first, simple example. She 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 create an alarm clock that checks the weather forecast before it wakes her, but first she needs to learn how to program it. She needs a solution that is easily learned: I can't expect 100 million people to attend extended courses. The Danish philosopher Søren Kierkegaard has given this excellent advice:

If One Is Truly to Succeed in Leading a Person to a Specific Place, One Must First and Foremost Take Care to Find Him Where He is and Begin There.13

So the critical question is: "Where can I find the Ellens of this world?". I tried to find a common ground for all humanity and looked up psychological research into the behavior of young babies. I didn't find any good answers. There was no consensus and the research had only been on very small and select groups of infants. I lowered my goal and asked for some idea that is intuitive for a large and varied group of people. The idea of composing something from smaller parts is a good candidate. Most children have probably created a cow by sticking four pins into a cork. The composition of LEGO® bricks into what Lego calls projects is an experience shared by many (Figure 6):

Lego products are sold in 130 countries. UN has 193 Member states. 75 billion LEGO bricks are sold per year, about 10 for each of the world population of 7,6 billion. On the average, each person on Earth owns 75 Lego bricks.14

13 https://teol.ku.dk/skc/sab/citater/ 14 https://www.telegraph.co.uk/finance/newsbysector/retailandconsumer/8360246/Lego-in-numbers.html

https://teol.ku.dk/skc/sab/citater/

https://www.telegraph.co.uk/finance/newsbysector/retailandconsumer/8360246/Lego-in-numbers.html


Figure 6: A Lego construction toy OO-Lego-3.png

Ellen's Lego construction toy provides her with a bucketful of bricks of different shapes and colors. She picks bricks one by one and joins them to compose her project. Ellen composes her program in the same way. The Lego bricks become her resource objects that represent things in Ellen's world. She picks them one by one and joins them to compose her project, which is her program. (See an animation of the process here).

Ellen's box of objects appear as icons in the window called "Resources" in Ellen's IDE. (Figure 7, right). She selects one by one and drags it into her workspace in the window called "Context" in the IDE (Figure 7, left). She names it according to the role it plays in her project and creates a road map by connecting it to other objects. This is a client-server connection as is assumed in most IoT communication standards. It is important to understand that Ellen only works with objects. (Like everything else, collections of objects are objects too). She doesn't know about classes and doesn't need them so she leaves them to the experts.

Figure 7: Ellen's IDE. PP-Ellen-DemoTool-8.png

Ellen first selected an object that represents the loudspeaker that has replaced her old alarm clock. She picks it up, moves into her project, 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 object with a script that tells it what she wants it to do for her:

wakeMe WAKERUPPER soundAlarm.15

She tests it, and it works. Next, she needs a weather service, finds it in her box of objects, drags it in, names it, connects it up, and tells it what she wants it to do for her:

checkWeather FORECASTER expectedRainfall = 0 ifTrue: [wakerupper wakeMe]16

15 This is Smalltalk syntax, chosen for being more accessible to the novice. The Java equivalent is void wakeMe() {WAKERUPPER.soundAlarm()}

http://folk.uio.no/trygver/themes/Personal/ezgif.com-optimize%20(3).gif


Finally, she selects a timer that will perform this program in the morning:

waitTillMorning TIMER waitUntil: '06:00'. FORECASTER checkWeather.17

That's it, the program is complete and Ellen sets her alarm clock by activating this first role script.18

I have chosen to give Ellen a menu driven input interface so that it only requires her to be able to read the code; making it part of her passive vocabulary. This preliminary solution is in the form of a 2-level menu of code templates (Figure 8). A balloon text helps Ellen when the mouse hovers over a menu item.

Figure 8: Ellen's Mental Model of computing PP-InsertMenu.png

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

B.2. DCI is Ellen's Mental Model of Computing You may have noticed that Ellen's programming is far from conventional. Ellen's IDE brings modern human-computer interaction technologies to programming and her IDE follows the MVC architectural pattern. The Model is invisible to Ellen; it consists of the fragments of code that, taken together, constitutes Ellen's program. Her three Views (Figure 9) help her build her mental model while she uses them to create her alarm clock. An invisible Controller ties the Views together to create a coherent tool.

16 The Java equivalent is void checkWeather() { if (FORECASTER.expectedRainfall = 0) { WAKERUPPER.wakeMe; } } 17 The Java equivalent is void waitTillMorning() { TIMER.waitUntil ("06:00"); forecaster.checkWeather() } 18 You can find a video of the process here.

http://folk.uio.no/trygver/themes/Personal/TrygveReenskaug-PersonalProgramming(AVCHD.H264.1440x1080p24).mp4


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

DCI gives Ellen 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.

• A Context is a structure of selected objects that play their roles to meet Ellen's goal (use case).

• An Interaction is the code within a context that augments the behavior of the participating object to make things happen.

There is also a projection of the program that presents it as a text. The text for Ellen's smart alarm clock is at http://folk.uio.no/trygver/assets/BBa11PPEllen/readableVersion.html.

A theatre analogy helps Ellen internalize the DCI programming paradigm: Data objects are like actors; they may be working or "resting". The DCI role is like the theatre's "function assumed or part played by a person or thing in a particular situation". The DCI Context is like a stage where actors perform their roles. The DCI Interaction is like the scripts for the actors' parts:

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 10). In DCI, the roll of paper is called a role script.19

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.

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

19 https://en.oxforddictionaries.com/definition/us/role

http://folk.uio.no/trygver/assets/BBa11PPEllen/readableVersion.html

https://en.oxforddictionaries.com/definition/us/role


B.2.1. Ellen's Data

In the Introduction, we argued for basing Ellen's mental model of computing on the notion of a Loke computer. Its most important ground rule was "Everything is represented by an object" which means that Ellen's Data are objects and nothing but objects.

Ellen's Data objects (Figure 9, right) are objects of her Loke computer; each object provides a self-explanatory message interface that she draws upon to compose her program. Some are general service objects; others represent familiar things in her smart home. Objects can also be instances of personal classes. She can write such classes when she becomes more proficient, or an expert can write them for her.

Ellen's program needs to answer three questions:

• What are the objects? • How are they interconnected? • What do they do?

The questions are open-ended and many professional programmers find it hard to answer them. (Wirfs-Brock & McKean, 2003) discuss 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. The point is that she perceived a need, poked around in her catalogue of 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 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.

B.2.2. Ellen's Context

Most personal programs involve more than one object that perform their roles within the DCI context. In the context diagram (Figure 11), an ellipse represents a role with its object. An arrow represents a link, i.e. a communication path for passing messages.

Figure 11: 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 can play the FORECASTER role in Ellen's program as long as it handles the expectedRainfall-message correctly.

Ellen's selected weather service plays a role in her smart alarm clock. This weather service can, in its turn, handle the expectedRainfall-operation in another Context within its information system. In general, any object can play a role in a Context. It follows that since a DCI Context is represented by an object, it can play a role in an outer Context recursively.

The DCI Contexts are recursive.


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

TIMER ^ResourceDictionary at: #clock FORECASTER ^ResourceDictionary at: #weather WAKERUPPER ^ResourceDictionary at: #speaker

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

B.2.3. Ellen's Interaction

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 realize the behavior of her clock. Her next task was to fill in the role scripts that made this happen. (Figure 12).

Figure 12: 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 the Squeak default language for scripting because it is conceptually and syntactically simple and is easy to read for the uninitiated.20 It is hard to read for most experienced programmers because it is different from what they are used to. The main stumbling block is the syntax for messaging. A typical mainstream syntax for a procedure call is:

receiver.selector (arg1, arg2, ...) e.g., fileDirectory.copy (london, paris);

The Squeak syntax for a message send is more informative:

receiver name1: arg1 name2: arg2. e.g., fileDirectory copyFrom: paris to: london.

I give priority to the uninitiated and hope experts reading this will have the patience to decode our simple examples. More about the Squeak language can be found in the Squeak home page21.

20You are free to define a different language for your BabyIDE role scripts if you know how to create a compiler for it. 21 http://wiki.squeak.org/squeak/1859

http://wiki.squeak.org/squeak/1859


Ellen creates and edits a role script in a text editor (left-bottom pane in Figure 7). This is a conventional "remember and type" kind of user interface; it requires that the language is part of Ellen's active vocabulary. For example, she must know the language to be able to type:

checkWeather FORECASTER expectedRainfall = 0 ifTrue: [WAKERUPPER wakeMe]

Figure 13: Coding by menu selection PP-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 textual syntax in her active vocabulary.

Ellen starts with a library of simple base objects. She adds new objects as needed from her Loke Computer. This extends the expressiveness of her language without changing her fundamental model of computing. We envisage that Ellen's mentors will make new objects with their message interfaces available to her as she needs them. When she gets more proficient, she may learn to create such objects herself.

B.3. A new way of programming The programming tool that I have shown here is BabyIDE/Novice, an experimental proof-of-concept implementation. I have shown Ellen's creation of a smart alarm clock to a farmer who has been using computers for many years but who has never written a program. We were brainstorming 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 self-contained source file, no discernible 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 meets her needs. Ellen's way of programming heralds a lifting of the universe of discourse from the hardware and the von Neumann machine to the human user and the universe of objects in Ellen's Loke computer.

This fundamental advance is the theme of the next Part of this article.


C. Loke: Ellen's Personal Object Computer

We are entering the connected society. Every thing, every person will be connected to a communication network. Some of these networks will be isolated, some will be connected through the Internet. An Internet of Things (IoT) is a network of physical devices, vehicles, home appliances, and other items embedded with electronics, software, sensors, actuators, and connectivity which enables these things to exchange messages 22. The Internet with its connected IoTs can be seen as a single, global machine consisting of a universe of communicating objects. It is an artifact created by hardware and software and has no physical or logical center. This single, global machine is still in its infancy. Nobody quite knows what it will ultimately look like or exactly what it will be used for. And nobody knows if it sooner or later will succumb under the increasing weight of its own complexity.

Smalltalk is a universe of objects that is always executing. It mimics the emerging single, global machine in that both are universes of communicating objects. The global machine is an open system in the sense that its objects have independent existence even when they are not connected to the Net. In contrast, the Smalltalk universe of objects is closed since its objects have no existence outside that universe. The Smalltalk universe is homogeneous and indivisible and so a copy can be filed out as a single image file.

Loke was introduced in section (A: Prologue) as a personal object computer that results from merging shared and personal objects as illustrated in (Figure 2).

• Loke is a universe of objects and nothing but objects. • The objects may have different representations, owners, and access restrictions. • An object has an immutable and globally unique identifier. • An object is characterized by its provided message interface. • The execution of a system operation in Loke is single threaded. • The conventional way of programming with its write code, compile, load, and run

is replaced by modify the objects of Loke. This means that there is no source code in the conventional, closed form

I have used the Squeak version of Smalltalk to create a laboratory model of Loke and use it for experimenting with the ideas described in this article. The implementation of my laboratory is described in (section D) and Smalltalk is described in detail in (Appendix 1: Smalltalk). BabyIDE is an experimental, Role-oriented development environment for Loke that is implemented in the laboratory as an extension of Squeak. New versions of BabyIDE are published in the form image files. Ellen filed in such an image and thereby became the owner of her personal and private Loke computer. Ellen is in the center of her personal machine and is empowered to mold its objects for her own purposes such as creating her smart alarm clock.

There are two keys to Loke's combination of personal and shared objects. First, Ellen needs uniform identifiers of objects be they local or remote. My experimental solution is a class, UUID, with different subclasses for the different kinds of objects and their protocols. An instance represents a particular object. Second, Ellen needs a uniform way of sending messages to all kinds of receiver objects. My experimental solution is to use a modified Squeak compiler and runtime that translates a simple message-send operation to invocation of a BabyIDE method that adapts the sending mechanism to the nature of the receiver. My experimental implementation of these two mechanisms is neither fast nor

22 https://en.wikipedia.org/wiki/Internet_of_things

https://en.wikipedia.org/wiki/Internet_of_things


elegant but it works. A production version of Loke may not rest on Squeak; but this option has not been investigated in the current project.

Ellen builds her understanding of her Loke computer as she uses it for new application areas. At the same time, she accumulates a fund of personal objects that cover her various domains of interest. It can be said that while a domain specific language specializes a computer for a certain domain, Ellen's use of her Loke computer specializes it for her own needs and preferences.

C.1. A new technology for sharing The raison d'être for Loke is to help human beings such as Ellen master their digital environment. Ellen lives in a community, and her Loke computer must not only support her in her private endeavors but also in her interaction with others. One example is that she wants to build on the work of her friends and share her results with them.

Programmers have always been sharing program parts. Three technologies are of interest here; the importance of the last increases with the advent of the single, global computer:

1. Subroutines (the von Neumann CPU abstraction) in the form of shared subroutine libraries. Example: POSIX application programming interface (API).

2. Subclasses (the class abstraction): Shared libraries of subclasses that can be used for instantiation and sub-classing. For languages such as Java, C#, and Ruby. Example: Java API 23.

3. Objects (role abstraction). Shared objects accessible across a computer network as services in a client/server architecture . Many useful services are offered on the Internet. Example: The Norwegian Meteorological Institute's Download services24 where information is available as structured documents. Considerable work is needed for filtering and converting these documents into objects with suitable interfaces for use in Loke.

The target group for BabyIDE comprises millions of potential personal programmers. Each will create capital in the form of a library of applications with their attendant contexts and role scripts. My experimental BabyIDE uses the full power of Squeak with its class library for role scripts and many of them may not survive transition to a new version of Squeak. This is intolerable. We cannot expect that millions of personal programmer have the motivation, time, and competence to convert all their old and new programs. Their capital lies in the value of their Data, i.e., their Contexts:

Users may tolerate an occasional program malfunction. They will never tolerate losing their data.

It is often a challenge to update applications when their foundations changes. An example is my BabyIDE implementation in Squeak version 3.10.2. The program only works in this version; a considerable effort will be needed for converting it to the current version 5.2-18225. An important motivation for the Personal Programming project was to find a way to protect user data such as contexts and role scripts from system changes. Native Squeak is monolithic; new versions apply to the whole universe of objects and a new release may or may not invalidate existing Ellen's personal objects.

Ellen can be protected against the calamities of a new Squeak release by making a certain functionality independently available from a server on the Net. Ellen's TIMER role can be

23 https://docs.oracle.com/javase/8/docs/api/ 24 https://www.met.no/en/free-meteorological-data/Download-services

https://docs.oracle.com/javase/8/docs/api/

https://www.met.no/en/free-meteorological-data/Download-services


taken as an example. In the Context of Ellen's smart alarm clock, EllenAlarmCtx, the timer role is bound to an instance of Delay, a Squeak library class. The binding could be modified to bind to a shared object with the same functionality, e.g. an instance of Delay installed on a stable object server. The TIMER role and any script referencing it would then be unaffected by any new Squeak release.

C.2. Prokon's Computer-Assisted Collaboration If Ellen becomes a manager in a work organization, she will want to use her Loke to support her collaboration with colleagues. An example could be decentralized planning while maintaining overall control. In the early 1970s, the Prokon project was part of a drive for participative work structures with decentralized command and control in business organizations (Emery & Thorsrud, 1976), (Reenskaug, 1973). The project's goal was to match the organization's distribution of responsibility and competence with the distributed architecture of its information system. The project introduced a vision of each manager owning a personal computer that they would use for their personal tasks and that was linked to other managers' computers in the organization. (Figure 14).

Figure 14: Enterprise communication25. 1973-08-ICCAS (1).jpg

A Manager would own their personal computer with their personal data: some of it private and some of it published for others to see. A manager could ask questions, request changes, or send reports to other managers. The receiver of a request or report could accept it automatically or let it wait for a manual check before accepting or rejecting it. One of a manager's tasks was to plan the activities of their department. Different departments have different responsibilities and use different technologies so they can use different programs for planning. It was felt essential that managers should understand the logic of their program and ideally write it themselves.

From time to time, managers would meet to synchronize their individual plans. Personal computers running below the table in Figure 15 communicate to support their owners who are negotiating above the table.

25 In Figure 14, thick, straight lines denote computer communication and thin lines denote human communication. The figure is copied from (Reenskaug, 1973).


Figure 15: Planning negotiations on two levels DistributedComputers-4.png

Prokon needed a new kind of programming that targets an ensemble of communicating computers in order to check the consistency of the overall plan. I first made a feeble attack on this problem before the Prokon project's money ran out and the project was terminated. (Reenskaug, 1977). It should be interesting to restart the project and build a new Prokon basing it on personal Lokes programmed by their owners.

C.3. Professional Programming with DCI We have moved from Ellen the novice through Ellen the friend to Ellen the manager. We now leave the non-experts and focus on a professional programmer, let's call him Anton. Anton serves many stakeholders: Individuals, groups, or organizations who have an interest in the outcome of his project. His solutions build on many different technologies that are outside the scope of this article. We mention three needs where DCI may prove helpful. The first is the need for simplicity, the second is the need to remove bugs as early as possible in the programming process, and the third is to be prepared for change.

C.3.1. The need for simplicity

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, 1981)

In his master thesis, Hector A. Valdecantos found that the DCI programming paradigm with its separation of concerns helps making code more comprehensible and thus appear simpler than Java to its readers. (Valdecantos, 2016). Other examples of using DCI to increase simplicity are (Bluemke Ilona, 2015) and a DCI-structured program for managing book loans in a library 26.

A deep challenge lies behind the following observation in the introduction to the Design Patterns book (Gamma, et al., 1994) p. 22:

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.. …, it's clear that code won't reveal everything about how a system will work.

The consequence of this chilling observation is that programmers are left with testing as the only viable road to removing bugs from their software. Dijkstra had something to say about this approach to software quality assurance:

26 A library program: https://github.com/ciscoheat/haxedci-example

https://github.com/ciscoheat/haxedci-example


Testing shows the presence, not the absence of bugs. E.D.W. Dijkstra27

There is hope: The DCI Interaction code does reveal how a system will work28.

C.3.2. Remove bugs early

Peer review is a well-known technique for finding bugs early. I first read about it in the Byte Magazine of about 1969. The article argued for code peer review as a very powerful method for removing deficiencies from a program while both code writers and reviewers learn from the experience. Later, Karl E. Wiegers cited inspections held on Motorola’s Iridium project that detected 80% of the defects present29.

At the time of the Byte article, my team was moving from procedure oriented programming with FORTRAN to object orientation. Simula didn’t fit our requirements so we wrote a front-end to the FORTRAN compiler that created a bizarre form of a recursive, object-based FORTRAN. The front-end and its design evolved through weekly progress meetings, ensuring that the whole team assimilated the current version of the database schema and program design. The unit for review was the subroutine: we designed it to be short and have a clear responsibility. Each subroutine was assigned to a team member who wrote the code and passed it through the compiler to remove syntax errors. The routine then went back to the progress meeting were it was assigned to another team member for review. It was tolerated and even expected that people make mistakes when coding. It was also expected that the reviewer should find all of them. Hence, the reviewer was solely responsible for the correctness of the code and the writer was free of responsibility and out of the picture. No deficiencies were found in 3 out of 4 subroutines in unit testing. The remaining subroutines had only minor bugs. No deficiencies were found during system testing or in the program's lifetime. To program with peer review was quite time-consuming with its weekly progress meetings, reviews, and unit tests. Many projects do not have the time and manpower for such elaborate development processes, but they do find time for lengthy testing and rework.

With object orientation, code review was no longer feasible because we could no longer identify chunks of code that were sufficiently isolated for independent review. Our only abstraction on objects was the class abstraction and the only available chunks were the class declarations. A class has dependencies in two dimensions: Up the class inheritance tree and across to the classes of objects that its instances collaborate with. There were no chunks that could be independently specified, written, reviewed, documented, and tested. According to Gamma, the problem still persists in mainstream programming.

Today, some 50 years after this experience, code review is again feasible. We now have two abstractions on objects to identify chunks of code for review. The class abstraction gives the definition of stand-alone objects as chunks for review. The role abstraction gives the DCI Contexts with their Interactions as orthogonal chunks. Peer review of DCI-structured code is feasible. Dijkstra put it this way:

If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with. (Dijkstra, 1972)

27 Dijkstra (1969) J.N. Buxton and B. Randell, eds, Software Engineering Techniques, April 1970, p. 16. Report on a conference sponsored by the NATO Science Committee, Rome, Italy, 27–31 October 1969. Possibly the earliest documented use of the famous quote. 28 More about DCI at fullOO.info 29 http://www.processimpact.com/articles/seven_truths.html

http://www.processimpact.com/articles/seven_truths.html


C.3.3. Prepare for change

There is more to programming than to coding, much more. Ensuring safety and privacy are two important ones. Last but not least, the programmer must work with end users and other stakeholders to create and revise requirements and system architecture. James Coplien (Cope) and Gertrud Bjørnvig discuss this part of the programmer's work in Lean Architecture for Agile Software Development (Coplien, 2010). This quote from the book is relevant to our discussion:

Much of Agile – and Scrum in particular –is based on a fact of life called emergent requirements. Grandpa Harry used to say that the best laid plans of mice and men often go astray. You can't master plan a project and expect to follow the plan. Agile folks know that. However, most Agile folks think that means only that we discover new problems along the way. It isn't just that we discover new problems: the act of design actually creates new problems. More to the point, the act of design sometimes changes the very nature of the problem we have set out to solve. We must revisit the problem definition to refresh it now and then.

There is more: Cope is thinking of a development process called Scrum where the project team at regular intervals extends the emerging product with usable and useful results. Domain experts gain experience with the extended product and are in a better position to revisit and refresh the problem definition. This can again lead to revised requirements for the code that the team implements using peer review to get it right. While coders are responsible for the bug-free implementation of given requirements, they are also heeding the last sentence in the Agile Manifesto30:

Responding to change over following a plan

C.3.4. An important remark:

This article assumes that we live in a perfect world where every object behaves according to its specification, where there are no communication or synchronization problems, no evil-doers, nobody running programs that conflicts with our own, etc. For example, two unrelated programs that happen to work with the same Thing at the same time can cause unexpected and hard to find errors. Such problems are shared with all distributed systems and their solutions belong elsewhere. See for example these references:

1. A new methodology for estimating hardware and software reliability given uncertain use conditions in Mudasir Ahmad: "Reliability Models for the Internet of Things: A Paradigm Shift" (Ahmad, 2014).

2. The top ten security issues with IoT devices and some suggested countermeasures in Ashwin Pal: "The Internet of Things (IoT) – Threats and Countermeasures"31.

3. Resolving inconsistent content in multiple models in Zinovy Diskin, et.al.: "Multiple Model Synchronization with Multiary Delta Lenses" (Ahmad, 2014)

Personal programs must be able to handle exceptions that can arise from various threats without confusing its owner when he or she is a novice. This challenge is for further work.

30 http://agilemanifesto.org/ 31 https://www.cso.com.au/article/575407/internet-things-iot-threats-countermeasures/

http://agilemanifesto.org/

https://www.cso.com.au/article/575407/internet-things-iot-threats-countermeasures/


D. The BabyIDE implementation

TBD

This section targets readers who have at least a superficial knowledge of Squeak or Smalltalk.

The BabyIDE that I describe here is part of my ongoing Personal Programming experiment and is implemented as a non-intrusive extension of Squeak 3.10.2.

Squeak is a universe of objects, and every object is an instance of a named class.

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

Ellen needs two kinds of information from her system.

D.1. The Data objects. Ellen needs an overview of all available objects and a short-list of the ones she mostly accesses.

D.2. The Context class: The topology of the execution graph

xxx

D.3. The Context instance: The execution environment

xxx

D.5. The Interaction.

xxx

D.1. The Data objects Figure 2 shows that there are two kinds of Data objects: public and private objects. They are available to Ellen locally or over a Net such as Internet. A BabyIDE requirement is that Ellen shall work with uniform objects independent of their actual implementation.

BabyIDE needs ways of identifying all objects and mechanisms for accessing them. The details of these mechanisms are outside the scope of this article. The current version of BabyIDE is not connected to the Net but includes facilities for a future connection. Two emerging standards are used as examples of future standards: The first is UUID32, a standard that is meant to provide a globally unique 128 bit identifier for each and every object in the world. The second is the idea of RESTful servers33 that provide them with self-descriptive interfaces that Ellen utilized when programming her role scripts (Figure 13). 32 https://en.wikipedia.org/wiki/Universally_unique_identifier 33 https://en.wikipedia.org/wiki/Representational_state_transfer

https://en.wikipedia.org/wiki/Representational_state_transfer


In the current version of BabyIDE, the Net is simulated by a global dictionary, ResourceDictionaryUUID, with keys that are Symbols and values that are instances of class UUID:

Object subclass: #UUID instanceVariableNames: 'uuid resource' "An instance of this class represents an object. " resource is a link to the object witch has UUID = resource. Subclasses specialize the class for different access mechanisms (To Be Done). They know how to trigger an operation in the resource pointed to by this UUID. Currently, resources are stored in ResourceDictionaryUUID (name -> aBB1UUID) UUIDs are here simple Strings."

ANONYMOUS MESSAGE PASSING resource only valid for Squeak objects!

Notice that instances of UUID are not wrappers but accessors: the identity of the networked objects retain their unique identity even when they are mapped to a role in the Context.

Figure 16: Ellen's active Data objects [1560]ResourceDictionaryUUID.4.gif

(Figure 16) is a Squeak Reverse Engineering (SRE) context browser that depicts an existing object structure. The root object is the ResourceDictionaryUUID. The symbols represent objects and lines represent named message paths. Notice that a Smalltalk class is represented by an object such as [664] Alarm. An advantage of this diagram form is that it distinguishes between different instances of the same class such as the 3 instances of class UUID. The text within the symbol is

<[OOP34]> <object name if any> <:> <object's class name>

For example, Ellen's WAKERUPER role is played by an instance of Alarm: a class object with oop = 664.

All BabyIDE objects act as servers in a client-server architecture and are represented by instances of UUID. Methods return meta-information used by BabyUML such as the menuList that is used to create the coding menu in (Figure 8):

UUID>>apiMenuList ^resource apiMenuList

34 ObjectOrientedPointer: Squeak's internal object identifier


Subclasses adapt to the actual protocol for getting the required information.

An example Data object from Ellen's smart alarm clock:

ResourceObject subclass: #Alarm instanceVariableNames: '' "instanceMethods: API" ResourceObject>>soundAlarm (AbstractSound majorScaleOn: PluckedSound default) play. "instanceMethods: accessing" ResourceObject>>apiMenuList | list | (list := OrderedCollection new) add: #('soundAlarm' 'Sound the alarm on owner''s bedside table.'). ^list

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

The returned entry is a UUID that understands

UUID>>send: selector withArgs: argCollection ^resource perform: selector withArguments: argCollection asArray

which will be handled correctly in the general message-sending method as shown below.

To the programmer of a role script, all message sends appear uniform and independent of the nature of the receiver. This illusion is maintained by a Context method that is responsible for all message sends on the Interaction level:

In pseudocode:

Context>>to: roleName send: selector withArgs: argCollection IF (there is a role script for the receiving role) execute it ELSE IF (the the receiver object is an instance of B1UUID "a Data object" send a message to it using the relevant protocol ELSE send message to local Sqeak object in the usual manner.

In Squeak:

BB1Context>>to: roleName send: selector withArgs: argCollection | receiver roleClass compiledMethod | receiver := roleMap at: roleName. roleClass := self class roleClassForRoleName: roleName. "repository class for scripts" (roleClass notNil and: [(compiledMethod := roleClass compiledMethodAt: selector) notNil]) ifTrue: [" role script exists, execute it.as an extension of the role player object " ^receiver withArgs: argCollection asArray executeMethod: compiledMethod] ifFalse: [ (receiver isKindOf: BB1UUID) ifTrue: "networked receiver, the UUID object will do the right thing" [^receiver send: selector withArgs: argCollection] ifFalse: "local receiver, send regular Squeak message"


[^receiver perform: selector withArguments: argCollection asArray]]

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

D.2. The Context class: The topology of the execution graph 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.

System behavior is described as a trace of the message flow during an execution. The trace forms a directed graph. The nodes of the graph are the roles, the edges are the links that connect them. The identity of the visited objects is likely to change from one execution to another while DCI requires that the topology of the trace stays the same. Note that classes do not enter into the description because it rests on the role abstraction of objects.

The class side of a Context is responsible for the trace topology. The programmer specifies this topology interactively in the graphically in an Interaction diagram such as the top-left pane in Figure 7. The programmer edits the diagram interactively and the resulting graph is represented in an automatically generated method that returns a Dictionary:

EllenAlarmCtx class>>roleStructure ^super roleStructure at: #WAKERUPPER put: #(); at: #TIMER put: #(#FORECASTER ); at: #FORECASTER put: #(#WAKERUPPER ); yourself.

and similar methods for the diagram geometry.

In BabyIDE, every Context is subclass of Context (actually BB1Context, but I omit the BB1 prefix for clarity) There is a subclass for each use case and an instance of this subclass for each execution. It has important logic both on its class and its instance sides.

Object subclass: #Context instanceVariableNames: 'roleMap'

The Context has one essential instance variable, roleMap: a dictionary that maps role names to Data objects at runtime: <role name> -> <a Data object>.

All roles are mapped together in one method for consistency:

Context>>remap " Map all roles to a Data object." self resetRoleMap. self class roleNames do: [:roleName | "All roles are mapped together." roleMap at: roleName put: (self perform: roleName ifNotUnderstood: [nil]) " Execute the mapping method." ]. self checkRoleMap

We see that the mapping of each role is done in a method that is named after the role name, e.g.:

EllenAlarmCtx>>WAKERUPPER


^ResourceDictionaryUUID at: #speaker ifAbsent: [nil]

This is the only case I have seen where I believe the graphical representation is superior to the textual form for experts as well as novices. The diagram is easy to read and edit and is grasped in parallel by the right part of the brain. In contrast, the textual form is grasped piecemeal by its left part. The diagram is also superior when it comes to selection by see and click against remember and type.

D.3. The Context instance: The execution environment 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 stack, and triggering the first role script:

EllenAlarmCtx>>start self triggerInteractionFrom: #TIMER with: #waitTillMorning.

The method sets up the Context instance before it invokes the first role script:

BB9Context>>triggerInteractionFrom: triggerRoleName with: selector andArgs: args selector numArgs = args size ifFalse: [^self error: 'Number of arguments mismatch']. " The context lives on the stack during the execution of a system operation: " self executeInContext: [self remap. ^(roleMap includesKey: triggerRoleName) ifTrue: [^self to: triggerRoleName send: selector withArgs: args] ifFalse: [self inform: 'Data object for role named ' , triggerRoleName , ' is undefined. Interaction not started.'. ^nil]]

We leave executing instance methods and enter executing role scripts when the above method sends to:send:withArgs: to the Context object. We need to digress into how we handle role scripts in BabyIDE before we continue describing the process.

D.4. The Role Scripts The definition of a class includes specification of its instance variables and methods. In Squeak, a method is a sequence of byte codes packaged in an instance of class CompiledMethod (Goldberg & Robson, 1983). The method is compiled by the class object where references to instance variables are transformed into appropriate byte codes. This means that different classes can have different languages for their methods.

Role scripts must be handled differently. We only know the names of the roles at compile time. They are late bound to objects at run time so there is no class available for compiling and storing role scripts in the same way we compile instance methods. Fortunately, a Squeak CompiledMethod does not know the class that compiled it. We can therefore compile a role script in a hidden class and execute it later when needed. These hidden classes can neither be instantiated nor subclassed. We give them a unique name by concatenating the <context name> with the <role name>, e.g.BB9FrontloadCtxACTIVITY. These classes are never seen by the BabyIDE programmer who edits and compiles Role Scripts in the IDE (Figure 26 pane 8). The hidden role script classes can be seen in the Squeak class browser (Figure 17).


Figure 17: Screenshot of the Squeak class browser (The Roles projection is only used as a repository for role scripts).

BabyIDE-organization-3.png

BabyIDE uses the Squeak SystemOrganization to organize DCI programs with their projections. The format of the category name is <appName>-<projection name>; they are visible in the regular Squeak class browser as shown in (Figure 17). Three applications are visible in this screenshot: BB8bMoveShape (a demo), BB9Planning (section G.5) and BBa10Pong (a game). The currently selected role script is the BB9Planning application, its Roles projection, and the role scripts for the ACTIVITY role in the BB9FrontloadCtx context. The Roles projection is only used as a repository for role scripts and is not visible to the BabyIDE user.

While it may be possible to program the planning application in the Squeak class browser, only specially interested programmers will ever consider to do so since it is both inconvenient and error-prone. The class browser and other Squeak tools are useful for debugging the BabyIDE program itself.

The role script compiler is slightly different from the default compiler for Squeak methods. Squeak methods are compiled in the context of a class so that references to instance variables can be translated into the appropriate byte codes. An invocation of a Squeak method puts an activation record on the stack (Figure 18).

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

Contrast with the role script activation record in (Figure 19) with accessible roles and no instance variables.


Figure 19: A role script activation record with associated objects. RuntimeDCIScriptScope.png

The BabyIDE Squeak compiler is extended so that it works as a pre-processor for role scriptsthat dereference references to roles into regular Squeak code. For example, the expression in the first line of code in (Figure 17),

maxPred := PREDECESSORS detectMax: [:pred | pred earlyFinish].

is expanded into

maxPred := (BB1ContextStack playerForRole: #cc) " the current Context object. " to: #PREDECESSORS send: #detectMax: withArgs: {[:act | act earlyFinish]}.

The source code for the role script is translated into regular Squeak code that is executed in the regular way. My experimental BabyIDE works, but it is cumbersome and very inefficient. A production version should be cleaner and more efficient but the underlying mechanism would be equivalent to the current version.

D.5. The Interaction We ended (section D.3) with sending a message to the first role in the Interaction. This message send marks the transition from one realm to another: from the domain of Squeak with its methods and objects to the domain of a DCI Context with its role scripts and players. (Figure 20) illustrates how the Context with its roles form a new level of abstraction above Squeak. Role scripts know other roles at compile time and can communicate with them. The role player (Data) objects are late bound to the roles at run time and do not know the roles that can play them. This restricted visibility is an important feature of the DCI strong separation of concerns that shields the programmer from the idiosyncrasies of the Squeak domain and the networked programming levels below it. The isolation cannot be broken without making the program error-prone and less readable.


Figure 20: The communicating roles in BabyIDE are on a new abstraction level. DCI-abstractionLayer-4.png

The world of IoT needs protocols for identifying all objects and mechanisms for accessing them. The details of these mechanisms are outside the scope of this article. The current version of BabyIDE is not connected to the Net but includes facilities for a future connection. Two emerging standards are used as examples of future standards: The first is UUID35, a standard that provides a globally unique 128 bit identifier for each and every object. The second is the idea of RESTful servers36 that provides the self-descriptive interfaces Ellen utilized when programming her role scripts (Figure 13).

In the current version of BabyIDE, the Net is simulated by a global dictionary, ResourceDictionaryUUID, with keys that are Symbols and values that are instances of class BB1UUID that represent global IDs. Subclasses specialize it for different access mechanisms with interfaces and explanations. Notice that the instances are not wrappers but accessors: the identity of the networked objects retain their unique identity even when they are mapped to a role in the Context. An example from Ellen's smart alarm clock:

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

The returned entry is a BB1UUID that understands

BB1UUID>>send: selector withArgs: argCollection ^resource perform: selector withArguments: argCollection asArray

which will be handled correctly in the general message-sending method as shown below.

To the programmer of a role script, all message sends appear uniform and independent of the nature of the receiver. This illusion is maintained by a Context method that is responsible for all message sends on the Interaction level:

In pseudocode:

BB1Context>>to: roleName send: selector withArgs: argCollection IF (there is a role script for the receiving role) execute it ELSE IF (the the receiver object is an instance of B1UUID "a Data object" send a message to it using the relevant protocol ELSE send message to local Sqeak object in the usual manner.

In Squeak:

BB1Context>>to: roleName send: selector withArgs: argCollection 35 https://en.wikipedia.org/wiki/Universally_unique_identifier 36 https://en.wikipedia.org/wiki/Representational_state_transfer

https://en.wikipedia.org/wiki/Representational_state_transfer


| receiver roleClass compiledMethod | receiver := roleMap at: roleName. roleClass := self class roleClassForRoleName: roleName. "repository class for scripts" (roleClass notNil and: [(compiledMethod := roleClass compiledMethodAt: selector) notNil]) ifTrue: [" role script exists, execute it.as an extension of the role player object " ^receiver withArgs: argCollection asArray executeMethod: compiledMethod] ifFalse: [ (receiver isKindOf: BB1UUID) ifTrue: "networked receiver, the UUID object will do the right thing" [^receiver send: selector withArgs: argCollection] ifFalse: "local receiver, send regular Squeak message" [^receiver perform: selector withArguments: argCollection asArray]]

All message sends in the Context abstraction are handled by this method. It marked the transfer to the Interaction domain at the end of (section D.2) and is also the method that is called for message sends in the compiler extension described at the end of (section D.3).

Finally, the personal programmer will need a way to find and organize objects. The proposed solution is to use a kind of internet browser combined with a search engine for finding objects like we do on the Internet. A better alternative could be to use some AI technology to help the IDE learn while the programmer navigates the around the Net.


E. Epilogue

TBD xxx

E.1. Further work Redo BB1ResourceLocator by using ResourceDictionaryUUID.

PP has been a one-man project since I started it in 2015. The advantage of being alone has been that it is easy drop one line of research at any time and start afresh. The disadvantage is that it is limited what a single person can do. I am an octogenarian and lack the necessary energy for bringing PP to fruition. The time is ripe to scale up the project with more people and better funding. 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.

Conclusion and further work. experimental. Establish IoT lab Test BabyIDE with real people Association of model builders. Sell communicating models. (trains, cars, Lego, ..) G-skala modelltog (4,5 cm skinne-bredde) https://www.hobbex.com/no/artiklar/radiostyrt/index.html https://www.elefun.no/rc/modelljernbane.aspx

E.1.1. IoT testbed for PP

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

E.1.2. Persistent objects

The value of a program materializes when an end user applies it to create valuable data; the hardware and software being merely means to an end. Personal Programmers may tolerate program errors and even crashes but they will never tolerate losing their personal data, including their personal programs.

From time to time, Pharo and Squeak issue a new version of their system that invalidates existing programs and data. At one stage, this made me reject both Squeak and Pharo as the foundation of PP. I have later learned that this volatility is an unavoidable side effect of living software, a side effect they share with most languages, applications, and operating systems. The consequence is that valuable user data must be stored in a in a stable form outside the programs.

An old Squeak program, OOram, is now in the Valhalla of obsolete and unreadable programs. This program recognized the fundamental difference between an executable


program and the static representation of information in a repository. In OOram, the encoding and decoding of information was delegated to the classes. Whenever the information in an object changed, its class encoded its information, tagged it with a type and a version number, and stored the record in the repository under its global identifier. The onus of ensuring backward compatibility was on the system developers; an object record was retrieved from the repository when needed; its type selected its new class and its version number selected the appropriate decoder.

E.1.3. Scratch programming interface

We have also looked at the visual programming environment in {Scratch is used in English kindergartens} 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 21). This idea could be carried over to Personal Programming where it, like in Etoys, would generate the role scripts.

Figure 21: Faked Etoys script for checkWeather PP-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.

E.1.4. 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 target stand-alone, von Neumann computers rather than networks of communicating computers such as the Web or IoT. All variants of Squeak work within a closed universe of communicating objects. PP retains the Squeak conceptual model but opens the universe of objects to the real universe of the Web and IoT. I strongly feel that any implementation of PP 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. Pharo37 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 needs of Ellen. She can start from a small core and add packages to learn more and do more as her needs arise until she ultimately becomes an expert. Pharo is our primary choice for the PP foundation with Squeak a close second.

37 https://pharo.org/

https://pharo.org/


E.1.4.1. Port original BabyIDE to current versions of Squeak and Pharo

Modify the compilers to handle DCI role scripts. Port BabyIDE user interface. (This port may be relatively simple since both Squeak and Pharo use the Morphic graphic system).

E.1.4.2. Reprogram BabyIDE according to the DCI paradigm

The current BabyIDE has grown organically as a laboratory experiment. It should be redesigned and implemented according to the DCI paradigm. The architecture of the Prokon/Plan example (section G.5) could inspire the architecture and implementation of the new version.

E.1.4.3. Create alpha version

The current version of PP is a Squeak implementation that is used for demonstration and experimentation. It shall be followed by an alpha version that shall be made available to anybody who has the courage and interest to be on the bleeding edge of the development.

For reasons of simplicity and security, PP alpha must isolate the PP programmer from the full capabilities of Squeak/Pharo. The isolation may take the form of splitting the PP system into several images that communicate through the Internet. Seaside 38 is a framework for developing sophisticated web applications in Squeak. This framework enables a Squeak/Pharo image connect to the Internet as a RESTful server and may also be used to link the PP images. The architecture of the PP alpha is of crucial importance to PP and it is important to get it right.

E.1.5. 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"39). It is a challenge to empower the Personal Programmer to make the most of these objects. In 2018, the World Wide Web contained nearly 50 million webpages40. This plethora of possibilities did not confuse this young and very modern man: "If I don't find it in five minutes, it doesn't exist". A Personal Programmer who aims to master their smart home faces a similar problem. There are widely varying estimates of the number of connected devices in the world by 2022, but all soothsayers agree on a very large number. Statista, who reports statistics and Studies from more than 22,500 sources, estimates that there will be 40 billion connected devices in 202241.

Once the IoT infrastructure and standards are in place, we can expect a plethora of innovative devices and new ways to use them. Ellen will mainly be interested in the devices in her own home that she may have bought herself and their object representations are known to her. She may find other objects using a search engine and organize them as desktop icons or as bookmarks. When she programmed her smart alarm clock, she was the client of the device objects that she used as servers and that provided self-explanatory message interfaces. Two standards, SOAP and REST, are two answers to the same question: how to access Web services. Ideally, BabyIDE should support both and our first choice must depend on the solution provided by our initial choice of test

38 http://www.seaside.st 39 https://en.wikipedia.org/wiki/Internet_of_things 40 http://www.worldwidewebsize.com/ 41 https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

http://www.seaside.st/

https://en.wikipedia.org/wiki/Internet_of_things

http://www.worldwidewebsize.com/

https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/


services.42 In Ellen's smart alarm clock demonstration, the access mechanisms will be hidden in the BB1UUID class and its subclasses.

E.1.6. Error handling

The more than 40 billion connected devices foreseen by Statista form a formidable security risk. 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. 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.

safety, security, privacy, reliability, availability , Resilience, error tolerance https://www.cso.com.au/article/575407/internet-things-iot-threats-countermeasures/

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 model is error-free and she her Interaction tells the truth, the whole truth, and noting but the truth. Her simple model could become prohibitively complex if it were to include general error handling. 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 to implement the decision? Whatever the solution, the key question must always be:

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

Around 1980, I asked a master student to establish 100%reliable communication network in our then new Ethernet. The poor guy 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:

There is, and never will be, a 100% secure and reliable system.

E.2. Other initiatives The DCI programming paradigm has been reified by James O.Coplien (Cope) in a research language he calls trygve:43.

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,

42 See Understanding SOAP and REST. Basics And Differences https://blog.smartbear.com/apis/understanding-soap-and-rest-basics/ 43 http://fulloo.info/Documents/trygve/trygve1.html

https://blog.smartbear.com/apis/understanding-soap-and-rest-basics/


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 elements44:

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 B.2. The trygve source code is a complete text that declares the program as a whole. This makes it possible to analyze the program automatically and support functionality such as its typing system. BabyIDE and PP are based on Squeak. 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. (Error! Reference source not found.).

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. 45

44 Example code in http://fulloo.info/Examples/TrygveExamples/ 45 http://fulloo.info/Examples/

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

http://fulloo.info/Examples/


Stephan Hermann's ObjectTeams 46have 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.47

----------------------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 network Imperative actors send an RPC destined for an actor with known interface, type, Relevant model for BabyIDE/IoT? https://www.infoq.com/articles/reactive-cloud-actors https://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.

E.3. Summary and Conclusion TBD

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]

If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with. {Dijkstra. The Humble Programmer (1972). 1972 Turing Award Lecture[1], Communications of the ACM 15 (10), October 1972: pp. 859–866. }

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

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

47 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://worrydream.com/refs/Hewitt-ActorModel.pdf

http://worrydream.com/refs/Hewitt-ActorModel.pdf

https://www.infoq.com/articles/reactive-cloud-actors

https://dzone.com/articles/distributed-systems-done-right-embracing-the-actor-model

https://en.wikipedia.org/wiki/Turing_Award

https://en.wikipedia.org/wiki/Turing_Award

http://www.cs.utexas.edu/%7EEWD/ewd03xx/EWD340.PDF

https://en.wikipedia.org/wiki/Communications_of_the_ACM

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

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


…, 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]

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

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 capabilities of her personal devices as well as the capabilities 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.48" 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 22). 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 Squeak. For security reasons, Ellen cannot be allowed to modify the Squeak 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 30

48 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.


Figure 22: Ellen's Loke Computer. ObjectComputer-1.png

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 23).


Figure 23: The three capabilities of computers threeCapabilities-2.gif

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

DCI adds data communication as 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 Squeak image. I claim that a further extension, which I have called Personal Programming, regains the children while retaining the Squeak 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 review. The Data objects are stand-alone in the sense that their classes are not concerned with peer-to-peer collaboration. Therefore, each Data class can be isolated for code review 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 reviewed and tested.

I 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.

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.

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.

E.4. Acknowledgements The 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 Squeak49. 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. 49 BabyIDE works under Squeak version 3.10.2. It is not easily converted to later, more complicated versions.


The concepts of Personal Programming and Ellen's Loke 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.

E.5. References Needs to be pruned.

Ahmad, M., 2014. Reliability Models for the Internet of Things: A Paradigm Shift. Naples, Italy, IEEE.

Alan Kay, A. G., 1977. Personal Dynamic Media. Computer, Issue March 1977, pp. 31-41.

Alaya, M. B., 2015. Towards interoperability, self-management, and scalability for machine-to-machine systems. Networking and Internet Architecture [cs, s.l.: Universite Toulouse III Paul Sabatier,.

ANSI, 1998. Programming Language Smalltalk. s.l.:InterNational Committee for Information Technology Standards (formerly NCITS), 01/01/1998.

Bluemke Ilona, S. A., 2015. Experiences with DCI Pattern. s.l., Springer, pp. 87-96.

Choi, J. K. & Kim, H. J., 2016. Analysis of Digital Data Technologies Toward Future Data Eco-Society, s.l.: International Telecommunication Union.

Coplien, J. O., 2010. Lean Architecture for Agile Software Development. Chisester, UK: John Wiley & Sons Ltd.

DCI-list, 2017. DCI - Data Context Interaction. [Internett] Available at: http://fulloo.info/

Dijkstra, E., 1972. The Humble Programmer (Turing Award Lecture). Communications of the ACM, October, pp. 859-866.

Dijkstra, E. W., 1969. I: J. Buxton & B. Randell, red. Report on a conference sponsored by the NATO Science Committee, Rome, Italy,. Rome, Italy: NATO Science Committee, p. 16.

Diskin Z., K. H. L. M., 2028. Multiple Model Synchronization with Multiary Delta Lenses. s.l., Springer, Cham, pp. 21-37.

Ducasse, S., 2005. Squeak: Learn Programming with Robots. s.l.:Apress.

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

ESUG, 1995. VisualWorks Advanced Tools, s.l.: European Smalltalk User Group (ESUG).

Galas, C. & Freudenberg, R., 2010. Learning with Squeak Etoys, s.l.: s.n.

Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1994. Design Patterns. Elements of Reusable Object-Oriented Software1994. s.l.:Addison-Wesley.


Goldberg, A. & Robson, D., 1983. Smalltalk-80, the language and its implementation. s.l.:Addison-Wesley.

Green, T., 1995. Noddy's Guide to Visual Programming. The British Computer Society • Human-Computer Interaction Group "Interfaces".

Hoare, C., 1981. The Emperor’s Old Clothes. Communications of the ACM, February, pp. 859-866.

ISO, 2009. ISO 80000-1: Quantities and units. Part 1: General (1st ed.)., Switzerland: ISO (the International Organization for Standardization.

Kay, A., 1972. A Personal Computer for Children of All Ages. ACM '72 Proceedings of the ACM annual conference - Volume 1, 1 August, p. Article No 1.

Kay, A., 1989. User Interface: A Personal View. [Internett] Available at: http://www.vpri.org/pdf/hc_user_interface.pdf

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

Kelly, K., 2008. The next 5,000 days of the web. [Internett] Available at: https://www.ted.com/talks/kevin_kelly_on_the_next_5_000_days_of_the_web#t-8111

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.

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

Reenskaug, T., 1978. MVC, XeroxX PARC 1978-79. [Internett] Available at: http://folk.uio.no/trygver/themes/mvc/mvc-index.html

Reenskaug, T., 1988. A Methodology for the Design and Description of Complex, Object-Oriented Systems, Oslo: Central Institute for Industrial Research, Oslo.

Reenskaug, T., 1996. Working With Objects. The OORAM Software Engineering Method.. Greenwich: Manning.

Reenskaug, T., 2006. Expert' voice: The BabyUML discipline of programming. Software and System Modeling, 5(1), pp. 3-12.

Reenskaug, T., 2007. Expert Commentary: The Case for Readable Code.. I: Computer Software Engineering Research. New York: Nova Science Publishers, pp. 3-8.

Roe, D., 2018. 7 Big Problems with the Internet of Things. [Internett] Available at: https://www.cmswire.com/cms/internet-of-things/7-big-problems-with-the-internet-of-things-024571.php [Funnet 06 05 2018].

Squeak, c., 2018. Monticello. [Internett] Available at: http://wiki.squeak.org/squeak/1287

Valdecantos, H. A., 2016. An empirical study on code comprehension: DCI compared to OO, s.l.: Rochester Institute of Technology.

Wiegers, K. E., 2002. Seven Truths About Peer Reviews. [Online] Available at: http://www.processimpact.com/articles/seven_truths.html


Wirfs-Brock, R. J. & Johnson, R. E., 1990. Surveying current research in object-oriented design.. Comm. ACM, 33(September 1990), p. 113.

Wirfs-Brock, R. & McKean, A., 2003. Object Design. Roles, Responsibilities, and Collaborations.. Boston, MA: Addison-Wesley.


F. Appendix 1: Smalltalk

The notion of Loke builds heavily on Smalltalk's universe of objects and there are many similar static and dynamic concepts. Smalltalk is often presented as a programming language, yet it lacks the concept of a program. We go deep into Smalltalk and find something that is more than the traditional third generation language (3GL) and that exists in an environment that is richer than the von Neumann machine.

Alan Kay and his group at Xerox PARC worked with his Dynabook vision: A Personal Computer for Children of All Ages (Kay, 1972). Kay's model of computing marked a complete break with the past. Part of his idea was to replace the lists in LISP with the objects of Simula (Kay, 1993). He called it object-orientation 50:

"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."

Smalltalk, with its derivative Squeak 51 , is object-oriented as defined above. Smalltalk is a universe of objects and nothing but objects. They are under the control of a virtual machine (VM) that is a combined interpreter and runtime system. Smalltalk objects provide functionality that is normally found in applications, IDEs, programming languages with their compilers, virtual machines, operating systems, etc. The universe of objects includes objects that represent a variety of things such as numbers, strings, dictionaries, text editors, classes, compilers, stack frames, methods, graphical elements, documents, planning activities, etc. A Smalltalk object has a unique and immutable identifier; its object-oriented pointer (oop). The object encapsulates state and behavior; state in its instance variables and behavior in its methods. Conceptually, the methods are encapsulated within the object.

A Smalltalk execution takes the form of messages flowing from object to object under the control of their methods. Conceptually, the execution started in the seventies and has never stopped. The execution may be paused and a snapshot of the state of the object universe saved in a Smalltalk image file. The image may later be loaded into any computer with a compatible virtual machine and the execution continues with the first operation after the snapshot primitive.

Smalltalk has no language for specifying the flow of messages; a programmer specifies individual classes so that their instances will "do the right thing". A programming language is usually thought of a language for specifying a program as a text. This text is automatically transformed into a binary form that can be loaded into and executed by a computer such as a von Neumann machine. Smalltalk and other Smalltalk dialects are sometimes called "programming languages" even if the term is then used in an unusual

50 The term "object orientation" has later lost its original meaning. 51 https://squeak.org/

https://squeak.org/


way. The target for the "language" is the Smalltalk universe of objects. New class objects and instances are created programmatically. There is an ANSI Smalltalk language standard that includes a textual language for specifying methods within existing classes together with a more or less arbitrary collection of utility classes.(ANSI, 1998) In Smalltalk-80 and Squeak, the compiler and thus the language for methods is delegated to the class so that different classes can specify different languages for their methods. This feature is used in Cincom Smalltalk, where the methods for some database classes are written in SQL.52

The notion of a program is missing from the standard and from most current implementations. The standard and most Smalltalk documentation also miss the power of the Smalltalk universe of objects and its self-describing nature with its powerful introspection capabilities. Some of these capabilities are essential to my implementation of DCI (Part D).

Most Smalltalk programmers work in the class abstraction and use the built-in class browser to edit the class objects in their inheritance substructure. There are many other interesting substructures in the universe of objects. The execution stack is a structure of activation record objects. Another structure is the structure of Data objects that play roles in a Context. The structure of display objects (Morphs) are particularly important in user interfaces.

Every object is an instance of a class. Since the class is represented by an object, this object must be an instance of a class and so on until there is a class that directly or indirectly is an instance of itself. BabySRE, Squeak Reverse Engineering, is a set of tools used to explore substructures of the universe of objects at a certain point in time53.

Figure 24: The Squeak superclass and instance-of object structures SRE context browser[2750][1222]a BBa11Alarm.2-Wakerupper.gif

<Rotate? Simplify symbols: remove class such as :BBa11Alarm>

(Figure 24) is an SRE Context Diagram that shows two orthogonal substructures growing out of the object with ID [1222], Ellen's WAKERUPPER object54. One structure is the instance-of hierarchy shown with horizontal arrows marked class in the diagram. This

52 http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DatabaseAppDevGuide.pdf 53 SRE user manual: http://folk.uio.no/trygver/themes/SRE/BabySRE.pdf 54 A box represents an object. The annotation is [oop], possibe instance name (role), : , class name.

http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DatabaseAppDevGuide.pdf

http://folk.uio.no/trygver/themes/SRE/BabySRE.pdf


structure is essential to the operation of Smalltalk since the behavior of an object is declared in its class. In contrast, the class inheritance hierarchy is shown as vertical arrows marked superclass. It has no runtime significance since the VM works as if all methods were specified together within the object's encapsulation55.

The inheritance hierarchy is thus in the nature of a comment created for the convenience of the programmer.

All this is of no interest to Ellen, our novice programmer. She may be far along the road towards becoming an expert programmer before she even hears about classes.

55 The hierarchy can always be refactored into a subclass of nil by judiciously copying and renaming its features.


G. Appendix 2: BabyIDE

BabyIDE is an non-intrusive extension of the Squeak universe of objects that supports the DCI separation of concerns. This separation is achieved by viewing the program in separate projections (Figure 4), 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 that is scaled down for the novice (Figure 7). Expert programmers use the full BabyIDE that is described in this section and exemplified in section G.5. Appendix 3: ProkonPlan; An Example.

BabyIDE has different browsers for different kinds of projections. The browsers are described in more detail below. We stress that a programmer may only use a selection of these browsers. Code in other projections is then generated automatically as we have seen in Ellen's IDE.

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.

• The Interaction browser is for 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 Context Class browser is for working with the class of the context objects. Its provided interface includes the system operations that are realized by the Context. This class also includes the essential methods that bind Roles to objects dynamically during the execution of a system operation.

• The Data Class browser is for working with personal Squeak classes.

I use Ellen's code as an example throughout.

G.1. The shared heading of all BabyIDE browsers The headings of all BabyIDE browsers are (Figure 25):

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 a textual projection of this application as a read-only HTML file.56

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).

56 Example in http://folk.uio.no/trygver/assets/BBa11PPEllen/readableVersion.html.

http://folk.uio.no/trygver/assets/BBa11PPEllen/readableVersion.html


Figure 25: BabyIDE heading BB11PP-Window-annotated.png

New projections are added as needed. Each projection is edited in an appropriate browser.

G.2. The Interaction Browser The Interaction browser (Figure 26) is where the programmer specifies 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. A role names an object and does not know the object's implementation, e.g. as an instance of a class. In BabyIDE/Novice, Ellen chooses the objects directly and the role binding methods are generated automatically. (Figure 27 pane 9).

• How are they interlinked? The programmer answers this question by defining a network of roles in the Interaction Diagram.

• What do they do? The browser answers this question by augmenting selected Roles with Role Scripts (Figure 26 pane 8). The BabyIDE runtime system creates the illusion that these scripts are parts of the roleplaying objects while they are needed at run-time. In reality, the objects are unchanged while the extra behavior is added by the runtime system.


Figure 26: The Interaction Browser. BB11PP-ContextInteraction-annotated.png

The panes of the Interaction Browser (Figure 26) are:

4. The projection is named Context. 5. A list of contexts, one for each system operation. EllenAlarmCtx is selected. A

button toggles between the Context class and Interaction browsers. 6. The Interaction diagram where the programmer works 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

B.2.2). (While a Squeak 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 30 shows a more complex example.

G.3. The Context Class browser A Context object forms the environment for the execution of role scripts. The properties of the Context are edited in a Context Class Browser. A swap to class/swap to Interaction button toggles between the two browsers.


Figure 27: The Context Class browser. BB11PP-ContextClass-annotated.gif

The panes of the Context class browser (Figure 27) are:

4. The projection is named Context. 5. A list of Contexts, EllenAlarmCtx is selected. A button toggles between the Context

class and Interaction browsers. 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, the selected superclasses and the selected method categories are shown. The role binding category is selected. By convention, the API category is reserved for the provided message interface of this Context, i.e., the system operations it implements.

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 for editing the source code of the selected method. This is a text pane, and it lets the programmer to write code in Squeak's default language for methods.

G.4. The Data Class browser Any object with a globally unique identity and with a known message interface can play a role in a Context. Available objects are found in a repository (Figure 7). This means that an instance of any Squeak class can play a role, including an instance of a Context class. The Data class browser is used to define some of these classes, other classes are defined elsewhere.

A role in a Context names an object with its identity and interface. The role does not know the object's implementation, e.g. as an instance of a class.

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


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

The panes in the Data class browser (Figure 28) are:

4. The selected projection is Data.

5. A class list showing the personal Data classes. BBa11MetOffice is selected. This a dummy that simulates an Internet service. Internet objects are not handled in this browser, but are handled in a separate repository.

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 editing the source code of the selected method.


H. Appendix 3: ProkonPlan; An Example

Anton's plans were in the form of activity networks where an activity represents a task that needs to be done. An activity 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. Different managers are responsible for different activities. Anton works with a personal fragment of the overall plan. His collaborators publish planning objects that Anton connects to and Anton publishes one or more planning objects that they can connect to.

Prokon/Plan is an activity network planning application that Anton can use for his personal fragment. Even if this is a centralized demo program without connection to other fragments, it illustrates the kind of program that Anton could use a distributed environment (Figure 14).

Figure 29: ProkonPlan user interface. Prokon-3-annotated.png

I used BabyIDE to program this application as an example of MVC/DCI programming. Its user interface has a number of panes as shown in Figure 29:

1. Identifies the program version and offers a menu for triggering various operations on the model (use cases).

2. Shows the properties of the selected activity, UI-Ctx, and allows them to be edited. (Notice that selections are synchronized; activity UI-Ctx is selected in all views).

3. Shows the activity dependency graph that connects predecessor and successor activities.

4. Shows the earliest and latest start and finish times that are computed from the project's start and finish times and activity duration and dependencies. The computation is invoked with a menu command in pane 1. The top, yellow bars show earliest and the bottom, green bars show the latest times (week numbers).

5. Shows the results of an automatic resource allocation.

This is a typical MVC application where the Model represents the user's mental model of the Plan and the Views are what the user works with. The M, V, and C parts are further separated into state and behavior by applying DCI to each of them, giving 6 projections in all:

• Model-Data projection. The user experiences the program's user interface as an extension of their mind. This "magic" of MVC (Figure 3) is achieved by faithfully


reflecting the user's mental model in the Model Data. The classes are DBase, Model, Activity, Dependency, Resource.

• Model-Context projection. This projection implements Model behavior, i.e., the operations on the Model itself. This projection realizes the user's mental model of the planning operations. The Contexts are FrontloadCtx, BackloadCtx, ResourceAllocationCtx.

• View-Data projection. The "magic" of MVC (Figure 3) is partially achieved by using well known graphic languages for the Views so that they are readily intuited by the user. The views thus bridge the gap between the human mind and the Model. The classes are DependencyView, ActivitySymbol, DependencyLine, ActivityTextView, BlurbView.

• View-Context projection. The behavior of a View is to retrieve data from the model and use the information to paint the View. There are many intricate coordinate calculations involved and it enhances readability to separate them out in their respective contexts: DependencyDisplayCtx, GanttDisplayCtx, and ResourceDisplayCtx. There are also Contexts for user input; AddActivityCtx and AddDependencyCtx, they trigger their respective Model-Context role scripts.

• Controller-Data projection. The Controller creates the ProkonPlan window with its Views and it is responsible for the selection mechanism. I only use DCI when it leads to simpler and more readable code. The Controller is here regular class oriented Squeak code because it seemed to be an overkill to separate state and behavior here. Consequently, there is no Controller-Context projection. There is one class; Controller.

A text projection of ProkonPlan has been printed on file57. It clearly illustrates how the MVC/DCI separation of concerns leads to almost independent projections where each projection can be separately written, reviewed, and tested. The exception is the selection mechanism that is implemented in class-oriented code.

The program was implemented using BabyIDE (Appendix 2: BabyIDE). The projection names are shown in the top line of the screen dump in (Figure 30). Model-Context is selected. The context diagram shows the participating objects and the source pane shows the role script for frontloading one activity at the time.

Figure 30: BabyIDE for ProkonPlan screen dump BB9Planning-BabyIDE.png

57 http://folk.uio.no/trygver/assets/BB9Planning/BB9Planning-listing/readableVersion.html http://folk.uio.no/trygver/assets/BB9Planning/BB9Planning-listing/printableVersion.html

http://folk.uio.no/trygver/assets/BB9Planning/BB9Planning-listing/readableVersion.html

http://folk.uio.no/trygver/assets/BB9Planning/BB9Planning-listing/printableVersion.html


The loop for traversing all the activities is in the PLAN role script

PLAN>>frontload PLAN allActivities do: [:act | act earlyStart: nil]. " set to unplanned " [ACTIVITY notNil] whileTrue: [ACTIVITY frontload. CURRENTCONTEXT remap. ].

The CURRENTCONTEXT object is responsible for mapping roles to objects making sure that it selects an activity that is ready for planning:

BB9FrontloadCtx>>remap ACTIVITY := model allActivities detect: [:act | act earlyStart isNil and: [(model predecessorsOf: act) noneSatisfy: [:pred | pred earlyFinish isNil]]] ifNone: [nil]. super remap "map remaining roles".

A final remark: In Figure 29, pane 5 we see that the UI-Ctx activity is to be performed by Joe in week 2 and 3 and finished by Ava in week 4. This is probably not the desired allocation but rather a side effect of the default ResourceAllocationCtx algorithm. While simple algorithms compute front- and back-loading, the optimal allocation of resources depends on local circumstances. I suggest that managers should personally code this particular algorithm to get an acceptable plan. This is feasible because the code is wholly contained within a single Context, the ResourceAllocationCtx.

<<In some cases, there is only one candidate Data object for playing a role. The mapping can be done at compile time. OK, but readability rules.>>


I. DUSTBIN

Deleted material. May be resurrected. Kay OO:

"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.

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

Two abstractions on objects

An object is an instance of a class. The class discloses the inner construction of the object. The instances of a class form an unordered set that hides the identity of its members. The object has no information about its environment, i.e. its context

The second abstraction is fully supported by the Squeak virtual machine, but is greatly underused by mainstream programmers, even programmers who are working in the Squeak environment.

An object is an entity with a immutable and globally unique identifier. The object hides its inner construction. The object provides a message interface that can be invoked by other objects. The object plays a role in its collaboration with other objects.

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

Java:

COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/L] [/A | /B ] source [/A | /B] [+ source [/A | /B] [+ ...]] [destination [/A | /B]] copy (eve, ellen)

Squeak:

copy: eve to: ellen.

Java:

void applyBrakes() { if (isMoving){ currentSpeed--; } }

Squeak:

applyBrakes isMoving ifTrue: [crrentSpeed := currentSpeed - 1]]


From fullO.info: The code may look unreadable to a reader more used to a mainstream language such as Java or C#. The main stumbling block is the syntax for message passing. The mainstream syntax is

receiver.selector (arg1, arg2, ...) e.g., fileDirectory.copy (file1, file2);

The Squeak (and Squeak) syntax is more informative

receiver arg1Name: arg1 arg2Name: arg2. e.g., fileDirectory copyFrom: file1 to: file2.

Internally, the Squeak compiler immediately transforms the above syntax to the mainstream form:

receiver arg1name:arg2Name (arg1, arg2). E.g., fileDirectory copyFrom:to: (file1, file2)

This works because the colon (:) is a legal character in a message selector. It follows that the number of colons in a selector equals the number of arguments.

More about the Squeak language can be found at http://wiki.squeak.org/squeak/1859.

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

We propose an axiom:

If you think about a problem long enough, you can always find a better solution”

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

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

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

How to create a distributed program that helps managers consolidate 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 annually afterwards. Role modeling was first described in (Wirfs-Brock & Johnson, 1990) and more fully in (Reenskaug, 1996)

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

My work with computers has always been highly oriented towards creating value for the users in the short and long term. I have measured my research results by their utility, not

http://wiki.squeak.org/squeak/1859


their academic acceptance. The focus is on comprehension, abstraction, design, and quality; the goal being to get it right the first time. ("Any method that prevents the programmer writing code, is a good method"). My most successful projects have been projects where the same people were system architects, designers, coders, trainers of users, system operators, trouble-shooters, maintainers, and salesmen.

My first major project, Autokon, resulted in a highly successful CAD/CAM product that went into production in 1963 and was used by shipyards all over the world for more than 30 years. It is worth noting that this project could probably not have happened today. The current fashion is to let end users dominate research projects. The nebulous Autokon project could not have survived a head on competition with real and urgent shipyard investment needs. Or it would have failed if academic research were permitted to dominate; there were many interesting problems that could have diverted the project from its strictly utilitarian goals. The project achieved a delicate balance between these two forces; the developers focused sharply on the needs of the users, but they took the users' concrete requirements as symptoms of a general classes of problems that needed general solutions

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

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

We 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 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.

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 in Part 0:

Appendix 1: Smalltalk: There is more to Smalltalk than is generally recognized.

Appendix 2: BabyIDE: A detailed description of BabyIDE with its tools and a comprehensive example with an architecture that combines MVC with DCI.


Novice Programming and the Professional Programmer in Part Error! Reference source not found.: Error! Reference source not found..

We are entering the connected society. Every thing, every person will be connected through a global communication network. Technically, the network with its connected devices can be regarded as a single, global machine. I choose to model this machine as a collection of communicating objects. My concern is to empower Personal Programmers to master it and shape their own parts. 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 31: The von Neumann model is a closed system..DUPLICATE vonNeumann-3.png

The von Neumann model is a closed system that can only interacts with its environment through its input/output channels (Figure 31). 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 of computing 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 32). 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 32: Enterprise communication58.59 DUPLICATE? 1973-08-ICCAS (1).jpg

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

Figure 33: Planning negotiations on two levels DUPLICATE? DistributedComputers-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 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

58 In Figure 32, thick, straight lines denote computer communication and thin, wiggly lines denote human communication. The figure 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 information flow. 3. Choose human or computer communication technology for each path.

59 Figure 32 suggests a logical process for creating enterprise communication architecture: 4. Identify participants with their competence, their responsibilities, and the services

they shall provide. 5. Identify communication paths and information flow. 6. Choose human or computer communication technology for each path.


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 that he called 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 32). Smalltalk's programming environment is class based, i.e., it describes one object at the time. It does not support the programming of collaborations that Prokon need. We therefore postponed the collaboration problem until we have now solved it with DCI. At PARC, we focused on another problem: 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).

There has been many versions of Smalltalk developed through the years. Smalltalk-80 was the first version to be publically available (Goldberg & Robson, 1983). Our current work has been based on Squeak60; one of the descendants of Smalltalk-80. More specifically, our experiments have been implemented in Squeak 3.10.2. This version is compatible with neither earlier nor later versions of Squeak. In the rest of this article, we will use "Squeak" to cover Smalltalk in general and this particular version in particular.

Our models of computing is based on Squeak. (Figure 34) 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 34: 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

60 https://squeak.org/

https://squeak.org/


programming with BabyIDE will be demonstrated with a video example (section XXX)???

The DCI programming paradigm serves as the Personal Programmer's mental model of programming. Det DCI home page contains documentation, examples, etc.61. 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.

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

Figure 35: 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 Error! Reference source not found.: Error! Reference source not found. is a motivation for writing readable code and formal peer reviews.

Section B.1: 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 Error! Reference source not found.: Error! Reference source not found. describes the beginner's simple mental model.

Section Error! Reference source not found.: Error! Reference source not found. describes how BabyIDE is utilizes the GUI style of interaction to provide the programmer with a direct manipulation interface.

Section Error! Reference source not found.: Error! Reference source not found. illustrates how an expert may use BabyIDE to realize a program with relatively complex system architecture.

Section Error! Reference source not found.: : Ellen's mental model of a computer is a configuration of objects that are mustered to rfealize a certain functionality of use case.

61 http://fullOO.info

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

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

http://fulloo.info/


Section Error! Reference source not found.: Error! Reference source not found.

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 E.1: Further work: suggests important questions that remain to be answered.

Section E.2: Other initiatives: briefly describes some other approaches personal programming.

Section E.2: Other initiatives

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

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 elements:


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 B.2. The trygve source code is a complete text that declares the program as a whole. This makes it possible to analyze the program automatically and support functionality such as its typing system. BabyIDE and PP are based on Squeak. 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. (Error! Reference source not found.).

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.

Stephan Hermann's ObjectTeams have 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.

----------------------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 network Imperative actors send an RPC destined for an actor with known interface, type, Relevant model for BabyIDE/IoT? https://www.infoq.com/articles/reactive-cloud-actors https://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.

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


Section E.4: Acknowledgements


Section Error! Reference source not found.: Error! Reference source not found. Generated automatically from Ellen's program.



I.1. The abstraction hierarchy of the BabyIDE implementation

To be deleted after essence moved elsewhere.

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 35 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 31).

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.

I.2. Abstraction Level 0: hardware. An Intel chip can have millions of transistors 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 realize our computer's microprogramming instruction repertoire.

People share VLSI integrated circuits at this level.

I.2.1. Abstraction Level 1: Microprogramming

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. 62(Wikipedia)

Microinstructions are combined into microprograms. Some of these programs reify the instruction repertoire of our computer's CPU. 62 https://en.wikipedia.org/wiki/Microcode

https://en.wikipedia.org/wiki/Microcode


There is no public sharing at this level.

I.2.2. Abstraction Level 2 platform: CPU Instructions

We here find instructions for storing data, transforming data, and for communication with entities in our computer's environment. This is where we find most computer programs such as applications and operating systems.

A computer program is a sequence of instructions[1] for performing a task designed to solve specific problems. 63

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 virtual computers with a different instruction repertoire. For example, a FORTRAN runtime system sustains the illusion of running a FORTRAN program. Similarly, a Squeak runtime system sustains the illusion of working in a Squeak environment.

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

I.2.3. Abstraction Level 3: The Squeak Environment.

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.

I.2.3.1. Squeak 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

I.2.3.2. Programming with Squeak 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

63 https://en.wikipedia.org/wiki/Computer_program

https://en.wikipedia.org/wiki/Computer_program


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:

What are the objects? How are they interlinked? 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 Error! Reference source not found.).

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.

I.2.4. Abstraction Level 5: DCI Context machine

Level 3 programs reify (section Error! Reference source not found.: Error! Reference source not found.) 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.

I.2.4.1. Object (DCI) 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 context64 of the execution of a DCI role script while an isolated class is the context of the execution of an ST instance method.

From Wikipedia:

A computer program is a collection of instructions for performing a specific task that is designed to solve a specific class of problems. The instructions of a program are designed to be executed by a computer and it is required that a computer is able to execute programs in order for it to function.

The instructions of a computer program are often specified by a computer programmer. A computer programmer does this by means of the application of a programming language. From the program in its human-readable form of source code, a compiler can derive machine code, which are computer program instructions that—as a result of being specified in a language that a computer can understand—are able to be directly executed by the computer they have been provided to. Alternatively, a computer program may be executed with the aid of an interpreter.65

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

“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:

If you think about a problem long enough, you can always find a better solution”

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.

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 class of an object is isolated from the object's environment. A method is triggered when an instance receives a message, but the class neither knows the identity of the sender nor the reason for sending it. The class similarly specifies the sending of 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 class declaration. This deficiency is behind the following observation in the introduction to the Design Patterns book:

64 Note lower case c! 65 https://en.wikipedia.org/wiki/Computer_program#Early_programmable_computers

https://en.wikipedia.org/wiki/Computer_program%23Early_programmable_computers


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:

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

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

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.

{NOTE: MVC should have its own section.}

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 annually afterwards. Role modeling was first described in (Wirfs-Brock & Johnson, 1990) and more fully in (Reenskaug, 1996)

---------------------history of Smalltalk:-------------------------

Programming languages can be categorized in a number of ways: imperative, applicative, logic-based, problem-oriented, etc. But they all seem to be either an "agglutination of features" or a "crystallization of style." COBOL, PL/1, Ada, etc., belong to the first kind; LISP, APL-- and Smalltalk--are the second kind. It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person.

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 [Plato].

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 anew 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.

------------history of Smalltalk:-------------------

Again, the whole point of OOP is not to have to worry about what is inside an object. Objects made on different machines and with different languages should be able to talk to each other–and will have-to in the future. Late-binding here involves trapping incmpatibilities into recompatibility methods–a good discussion of some of the issues is found in [Popek 1984].

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

RM-ODP - View, Viewport

Personal vs professional programmer

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

I.3. Appendix: Squeak reverse engineering This part describes tools that are, or will be, programmed as a package for installation in a Squeak image. SRE (Squeak Reverse Engineering) consists of three tools making existing Squeak objects visible and tangible:

The SRE Execution Tracer dumps a snapshot of the stack on the Transcript. The SRE Object Inspector gives me a snapshot of a single object with its identity, state, and behavior. I can edit its state as in a Squeak Inspector and its behavior as in a class Browser. The class hierarchy is flattened so that I see the object as it appears at runtime. The SRE Context Browser lets me diagram the instantaneous structure of selected objects. With this tool, I find that I can master larger and more complex systems than I could without it

Taken together, these tools puts the user in close contact with the objects as they exist in the system, thereby giving him or her a better understanding of the system as it is.


I.4. SRE Introduction "Conceptual abstractions may be formed by filtering the information content of a concept or an observable phenomenon, selecting only the aspects which are relevant for a particular subjectively valued purpose"66. In Squeak, everything of interest is represented by an object; there is nothing but objects in Squeak. Two abstractions support programmers' mental models:

The Class abstraction. An object is an instance of a class. This abstraction stresses the inner construction of an object; its instance variables and methods. It hides the object's identity and its place among objects in its environment.

The Role abstraction. An object is an entity with an immutable and globally unique identity that collaborates with other objects to achieve a goal. An object can play many roles and a role can be played by many objects at different times. An object exhibits its state and behavior through its provided message interface that hides its inner construction.

Squeak's many browsers gives excellent support for thinking and programming with the class abstraction. SRE, Squeak Reverse Engineering, complements this by providing three tools for working with runtime structures of collaborating objects in the role abstraction:

SRE Execution Tracer. Object>>traceRM:levels: is like Transcript>>show: with the addition of the oop of the writing object and a dump of the stack to a specified depth.

SRE Object Inspector. A class is a partial description of its instances. Partial, because the description is fragmented between its superclasses and also because the class does not disclose the state or identity of its instances. The SRE Object Inspector shows the state and behavior of an object. The state is shown as the instantaneous value of all its instance variables. The behavior is shown as all its methods in its flattened class hierarchy.

SRE Context Browser. The essence of object orientation is that objects collaborate to achieve a goal. The Context Browser is used to plot an instantaneous context; a substructure of collaborating objects.

I first revisit Smalltalk/Squeak and see that it is a universe of objects with a VM that continuously executes its CompiledMethod objects. I next describe the three SRE tools illustrated by examples. I frequently find I use the tools when I wander into uncharted parts of a system. It is much easier to read the code when I understand the important objects and the relationships between them.

Every object is an instance of a class. Since the class is represented by an object, this object must be an instance of a class, and so on until there is a class that directly or indirectly is an instance of itself. This is illustrated by the class (i.e., instance-of) links in this SRE context diagram67:

66 https://en.wikipedia.org/wiki/Abstraction 67 A box represents an object. The annotation is [oop], possibe instance name, : , class name.


The instance-of hierarchy is shown as arrows marked class in the diagram. It is essential to the operation of Smalltalk since the behavior of an object is declared in its class. In contrast, the class inheritance hierarchy has no runtime significance since the VM works as if all methods were specified in the object itself68. The inheritance hierarchy is thus in the nature of a comment created for the convenience of the programmer.

I.5. The Demo Program For the purposes of this Part, I have created a class for a colored ellipse that cycles through a sequence of different colors:

EllipseMorph subclass: #DemoEllipseSRE instanceVariableNames: 'colorIndex' ..... EllipseMorph >>step | colors | colors := {Color red. Color green. Color blue. Color magenta. Color yellow}. colorIndex ifNil: [colorIndex := 1]. colorIndex := colorIndex + 1 \\ colors size + 1. self color: (colors at: colorIndex).

I start the demo by executing DemoEllipseSRE new openInWorld. and observe a small ellipse in top-left corner of the screen that regularly changes its color.

I.6. SRE Execution Tracer. The SRE trace operation, Object>>traceRM: anObject, is a sophisticated Transcript operation. It works as a regular Transcript show: with the addition of information about the sending object and method and the current stack. There are 3 variants:

Object>>traceRM: anObject, Object>>traceRM: anObject levels: levCount, Object>>traceRM: anObject levels: levCount withContext: aContext

anObject is the object to be printed. The default is anObject printString. aContext is a stack frame. The default is thisContext sender. levCount is the number of stack levels to show. The default value is 1.

Examples of its use are shown in section H.8.3 Projection 3: The Stepping Collaboration.

I.7. SRE Object Inspector for investigating a Single Object The Squeak inspector is a powerful tool for investigating the current state of an object in the class abstraction. It is easy to open new inspectors on its instance variables and thereby build a picture of the system. The downside is that the screen (and my brain) quickly gets cluttered with inspectors. Also, I might

68 The hierarchy can always be refactored into a subclass of nil by judiciously copying and renaming its features.


get confused if I have open inspectors for different instances of the same class because the instances all look the same:An ElllipseMorphSRE. This last problem has been remedied by adding identity information in Object>>printOn:, for example [3072]: DemoEllipseSRE. (Note: The problem of many inspectors is partially solved by the Squeak explorer).

The properties (state and behavior)of an object are given by its class and the superclasses of that class. The relevant objects are shown in the diagram on the left. [3819]DemoEllipseSRE is a subclass of [633]EllipseMorph etc. It is interesting to note that the objects shown in this diagram taken as a whole exactly describe the DemoEllipseSRE that is flashing different colors somewhere on the screen. It may also be interesting to note that the defining classes in all probability belong to several packages.

The SRE Object Inspector inspects a runtime object as a whole with its identity, state and behavior as declared in a flattened class hierarchy. The Object Inspector shifts the focus from the class to the object, very illuminating.

Developer note: Sometimes, it is useful to extend the name of the object with the name of the class. At other times, this can be confusing as illustrated in this diagram. May be the default should be that the class name should only be shown for anonymous objects without a name on their own.

The top-left of this browser is a filtered list of the object’s instance variables. The top-right is the value of the selected one (as in the Squeak Inspector, but filtered). The second row is a filtered list of the object’s methods together with the code of the selected one. The third row shows two filters as multiple select lists; a superclass list and a list of method categories. Both filter what is shown in the instance variable and method lists. More examples of its use is in section Projection 4: The Instantiation Hierarchy.

I.8. SRE Context Browser for Displaying an Object Substructure.

The essence of object orientation is that networks of collaborating objects work together to achieve a common goal. The Squeak universe of objects is large and has a structure that is so complex that it can't be grasped by the human mind. The SRE Context Browser lets me build a model of an interesting substructure and project it onto an SRE Context diagram. I find that this tool helps me master larger systems than I could master without it. A diagram shows a substructure, or projection, of the universe of objects. A box identifies an object and represents the role that the object plays in the context of its peers. Its yellow menu command are:

SRE object inspector. Open an SRE object inspector on the selected object.


Squeak inspect object. Open a normal Squeak Inspector on the selected object. Squeak inspect symbol. A debug operation that opens a Squeak inspector on the symbol object. Squeak browse class. Open a normal Squeak Browser on the class of the selected object. add link for variable... Select an attribute object, create link to the this object, create new role if needed. add link for DCI collaborator... DCI experiment, not working. add context object... DCI experiment, not working. add role playing object... DCI experiment, not working. add role for all pointers to this object... Create a collection of all objects that point to this object, create a new role for this collection. add role from expression... Type an expression. Evaluate it in the context of the selected object. Add a role on the resulting object. rename role... Rename the selected role. The selected object is unchanged. delete role. Remove the selected role from the diagram. The selected object is unchanged.

Four projections illustrate its use. Each highlights some aspects of the same universe of objects while hiding all the rest.69 You may, as I do, find it boring reading. But they illustrate what you can expect if you install the SRE tools in your own image. I find I frequently use them when I wander into uncharted parts of a system. It is so much easier to read the code when I understand the nature of the objects and the relationships between them.

Projection 1: Domain Collaboration. The Morphic objects that collaborate to run the DemoEllipseSRE program. Projection 2: Instantiation and Inheritance hierarchies. The instantiation and inheritance hierarchies are often confused, yet they bear no relationship to each other. Projection 3: The Stepping Collaboration. An investigation into the Squeak stepping mechanism. How does it work? Projection 4: The Instantiation Hierarchy. Every class can file out an .st-file. Where is the method that does it?

I.8.1. Projection 1: Domain Collaboration

The focus of attention is the DemoEllipseSRE I created when I executed

DemoEllipseSRE new openInWorld.

To create the diagram, I pointed to the ellipse, opened the halo, selected the debug command SRE Context Browser, opened a new diagram, and placed the new [3072]: DemoEllispeSRE box.70

This is an example of the simplest kind of morph. It is owned by [999] world, a morph that controls the whole Squeak screen and has all the visible elements as submorphs. (world is an instance of PasteUpMorph. Its Balloon help says that it is a morph whose submorphs comprise a paste-up of rectangular subparts which "show through").

I see that world has a link named extension holding a SimpleBorder. The diagram doesn't indicate the meaning of this value, but it does warn us of its existence.

69 The snapshot of the universe of objects while it executes the Demo Program contains 490,055 objects. 70 More details in Error! Reference source not found.


The world also has a link named worldState to [3514] :WorldState that has a link to [907] :FormCanvas, a reference to the screen. [3514] :WorldState also has a collection hands, one of them is [689] :HandMorph, which is the global variable ActiveHand. (The hand's submorphs hold anything being carried by dragging).

In the diagram, an objects is identified with a String: [<oop>]<object name, if any> : <class name>

The relationship between [999]world and [3577]project is not so easy to find. A Project has an instance variable, world, which indicates that there is at most one world in a project. But why doesn't world have an instance variable for its project? [999]world finds [3577]project programmatically with its project method; I use the add role from expression command with self project to create the link.

PasteUpMorph>>project

"Find the project that owns me. Not efficient to call this."

^ Project ofWorld: self

Project class>>ofWorld: aPasteUpMorph

"Find the project of a world."

"Usually it is the current project"

CurrentProject world == aPasteUpMorph ifTrue: [^ CurrentProject].

"Inefficient enumeration if it is not..."

^ self allProjects detect: [:pr |

pr world isInMemory

ifTrue: [pr world == aPasteUpMorph]

ifFalse: [false]]


ifNone: [nil]

This smells like a scheme for swapping worlds in a virtual memory, but I will not investigate this further.

I.8.2. Projection 2: Instantiation and Inheritance hierarchies

Every object is an instance of a class. A class object is likewise the instance of a class. (Classes whose instances are classes are often called metaclasses). The metaclass is also an instance of a class -- does it ever stop? 71 Subclassing and instantiation are independent mechanisms and are shown orthogonally in the diagram. The superclass links are shown vertically and the instance-of horizontally. (The latter links are marked class since an object is an instance of a class).

The properties of the flashing [3072]:DemoEllipseSRE are specified by its class [2944] with superclasses, i.e., one right and 5 up in the diagram. Similarly, the properties of any other object are specified by its class object. E.g., [108]Metaclass is an instance of [1186]Metaclass class which in its turn is an instance of [108]Metaclass and the recursion is closed.

The squeak-dev mailing list sometimes shows questions arising from a confusion of a class with its metaclass. I am speculating that the metaclass object could be described as a regular object in the system design (sometimes called a factory object). May be we don’t need one for every class; several classes could share a common factory object.

I.8.3. Projection 3: The Stepping Collaboration

The demo example gave me the inspiration to find out how and from where the step method was called. I augmented the step method with traceRM: self levels: 10 and made sure to execute it only once to avoid an overflowing the Transcript :

DemoEllipseSRE>>step

" Version for stepping experiements. "

71 The Smalltalk architecture is given in some complex diagrams in the (Goldberg & Robson, 1983) on pages 270-272 in my copy.


| colors |

self doOnlyOnce: [self traceRM: self levels: 10].

colors := {Color red. Color green. Color blue. Color magenta. Color yellow.}.

colorIndex ifNil: [colorIndex := 1].

colorIndex := colorIndex + 1 \\ colors size + 1.

self color: (colors at: colorIndex).

The result was the following trace in the Transcript:

1 [3072] : DemoEllipseSRE >> step {[3072]a DemoEllipseSRE}

2 [3072] : DemoEllipseSRE >> doOnlyOnce:

3 [3072] : DemoEllipseSRE >> step

4 [3072] : DemoEllipseSRE >> stepAt:

5 [1927] : StepMessage >> value:

6 [3514] : WorldState >> runLocalStepMethodsIn:

7 [3514] : WorldState >> runStepMethodsIn:

8 [999] : PasteUpMorph >> runStepMethods

9 [3514] : WorldState >> doOneCycleNowFor:

10 [3514] : WorldState >> doOneCycleFor:

I see that the invocation of the step method originates in [3514]WorldState via [999]world and back to [3514]WorldState>>runLocalStepMethodsIn: to [1927]StepMessage. It transpires that this StepMessage is one of many in [1042:Heap]. This Heap changes very rapidly and the addLinkForVariable-command didn't work properly. I removed the Heap from the diagram, selected the WorldState, and used addRoleFromExpredssion to find the appropriate StepMessage:

stepList detect: [:step | step receiver asOop = 3072]

which added [441]:stepMessage to the diagam and its link to receiver completed it.


An interesting part of the trace was

6 [3514] : WorldState >> runLocalStepMethodsIn:

and I inspect the WordState 0bject to look at it. (I could of course have used the regular class browser if I hadn't been stubborn).


I.8.4. Projection 4: The Instantiation Hierarchy

I spent some time locating the fileOut method that create *.st-files. I started with the regular class browser and selected the DemoEllipseSRE class. No fileout selector in the instance or the class. The hierarchy and protocol browsers were the same; no fileout. I look at various fileOut methods and find that the real work is done in

Metaclass>>fileOutOn: aFileStream moveSource: moveSource toFile: fileIndex initializing: aBool

The methods of an object are listed in the methodDict of its class; here [108]Metaclass. I start with the demo object and follow its instance-of-links72 until I find a class object that has my method in its methodDict:

72 The instance-of link is shown as a dashed line in the diagram. It is named class since an

object is an instance-of a class.


I check my thinking by inspecting the relevant objects. First the class, [2944]:DemoEllipseSRE. The methodDict is named in superclass Behavior, so I the filter for this superclass. The methodDict has the expected entries for the DemoElipseSRE; drawOn:, step, and the experimental xxstep.

Note that this methodDict is a variable in the [2944]DemoEllipseSRE object even if it is declared in class Behavior. Similarly, [3045]DemoEllipseSRE class does understand fileOutOn:moveSource:toFile:initializing: and its methodDict should be a variable in [108]Metaclass:Metaqclass class, which it is:


I see what confused me. The class browser works with the object's methods in the methodDict of its class. When I browse the instance side of DemoEllipseSRE, I edit the methods of the methodDict in its class, DemoEllipseSRE class; [2944]DemoEllipseSRE :DemoEllipseSRE class.

When I browse the class side, I move one step up and edit the methodDict of [3045]DemoEllipseSRE class :Metaclass.

But the fileout messages are understood by this class object and its methodDict is in [108]Metaclass :Metaclass class. My mental model was one off in the instantiation hierarchy.

You may find this complex and it is. I don't know how I should have grasped these relationships without using the Context Browser. But this is where Smalltalk finds much of its power. It is up to the system programmers to build on Smalltalk's leverage to create powerful tools that protect the programmer from this complexity.

This example illustrates that the instantiation hierarchy is fixed and essential for the semantics of Squeak programs. The class inheritance hierarchy is different. We can rearrange it in any way we like without changing the program's semantics. It is called refactoring and the class hierarchy is in the nature of a comment.

Never confuse instantiation with subclassing. The first is essential, the second is in the nature of a comment. Both structures coexist in the universe of objects.

I.9. SRE Conclusion The object diagrams and stack dumps shown here are all created with the help of the BabySRE tools. They augment the traditional class browsers and inspectors with object browsers and inspectors. Where most Squeak programming tools apply to compile-time classes, the SRI tools apply to the run-time objects.

The SRI tools are useful when we need to understand and document an existing system. The SRE focus on the run time is reflected in objects no longer being anonymous but named with their unique oop and no longer being stand-alone but being nodes in a structure of collaborating objects. The examples given here illustrate the value of understanding on what actually happens at runtime. I have on many occasions found that the BabySRE tools help me better understand programs written by myself and by others.


The SRE Object Inspector can also be used to modify the system; its user can change the values of instance variables and define methods in the object’s immediate class. (Modifications of the superclasses have been blocked because a local change can have system-wide repercussions). The development of the SRE tools is part of the DCI project where I look for higher level constructs for object oriented programming (as opposed to class oriented programming) .

It is tempting to take SRE a step further. SRE Context diagrams resemble DCI Context diagrams and it is tempting to explore if they could be merged so that SRE becomes a tool for both reverse and forward engineering. This idea points to a merger of the SRI tools and the DCI programming tools. Comment to Hannes: This para should be changed to reflect your thoughts,

Dynabook, Kay77. Design of everyday things, Norman88

I.10. SRE Acknowledgements Many thanks to Ned Konz for the Connectors package. Also for his permission to copy/rename the classes I use from this package so that the evolution of BabySRE becomes independent of the evolution of the Connectors package.

Sincere thanks to Milan Zimmermann and Chris Muller for excellent and very useful suggestions that have been realized in the second version of BabySRE.

I.11. Old, unused References Google: object identity https://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.

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

Alan Kay defined the semantics of object orientation as "a bit like having thousands and thousands of computer all hooked together by a very fast network", i.e., a universe of communicating objects as illustrated in Figure 36. Like computers, the objects are encapsulated so that there is a clear separation between their insides and their outsides. An inner observer can see how the object is constructed, e.g. as an instance of a class or as an application written in some programming language. An outer observer can see the

http://en.wikipedia.org/wiki/Data%2C_Context%2C_and_Interaction


messages that flow between the objects where each object is characterized by its identity and by the message interface it provides. This dichotomy ties in with the two abstractions on objects defined in the introduction. An inner observer in a universe of objects works with the class abstraction while an outer observer works with the role abstraction. (Figure 36)

The DCI Data are stand-alone objects; each object is specified by an inner observer. The DCI Context is specified by an outer observer who musters the objects and organize them in a bespoke structure according to the role they play when they interact to achieve a goal (use case).

To sum up: Mainstream languages are used to program stand-alone objects. Programming collaborating objects is out of scope for these languages and therefore rejected as the basis of object computing and this article.

levels of abstraction

The levels are:

1. Hardware (HW). Rests of HW gates etc. Builds HW components, recursively.

2. Microcode Rests on HW components, builds CPU instructions.

3. CPU Assembly Rests on CPU instructions. Builds programs, e.g., an application program. e.g. the Squeak VM.

4. Squeak Rests on the Squeak VM. Builds stand-alone objects as instances of classes. e.g. application objects. e.g. a DCI Context.

5. Interaction Rests on a DCI Context. Builds structures of interacting objects represented by the roles they play in the Interaction. e.g. The behavior of Ellen's smart alarm clock.

Figure 36: An object-oriented system with a Context of interacting roleplaying objects. DCI-Foundation-5.png

The aim of the BabyUML project is first to identify the core concepts I need to regain control of my systems. Second, I want to create a run time environment supporting these concepts. Third, I want to define


the languages and interactive development environments that lets me experiment with the new concepts and facilities.

I.12. Levels of abstraction 6. Hardware (HW).

Rests of HW gates etc. Builds HW components, recursively. 7. Microcode

Rests on HW components, builds CPU instructions. 8. CPU Assembly

Rests on CPU instructions. Builds programs, e.g., an application program. e.g. the Squeak VM.

9. Squeak Rests on the Squeak VM. Builds stand-alone objects as instances of classes. e.g. application objects. e.g. a DCI Context.

10. Interaction Rests on a DCI Context. Builds structures of interacting objects represented by the roles they play in the Interaction. e.g. The behavior of Ellen's smart alarm clock.

Appendix 4: A Short History Modern computer programming celebrated its platinum jubilee on the 21st of June, 2018. Exactly 70 years earlier, 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 at the Victoria University of Manchester, England. The solitary computer, affectionately known as 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 (GUIs) that empower each and every one of us to augment our 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. We are no longer running a computer but work to achieve our immediate needs.

I wrote my first programs I 1958, 10 years after the Baby. My programming techniques were, to put it mildly, primitive: Get a vague idea, write some code, debug it, refine the problem, debug the code, etc., etc. In 1960, a real problem materialized; the computer-aided design of ships.

My colleague Kjell Kveim invented a digital control unit for flame cutters. T task was to write a program that produced the control tapes for cutting the steel parts of a ship. The parts would later be welded together to form the ship. (Error! Reference source not found.)


Figure 37: Part of ship's bottom ESSI-trapar.jpg Copyright?

The year was 1960, and I had a real problem and a new and bigger computer to work with. My first programs had taught me a lesson: My brain was too small to master my programs. My happy-go-lucky programing style was useless. I had two options: Improve my brain or improve my style. I didn't know how to do the first so it had to do the second.

My first idea was to have a test-driven process. I sketched out the code for some loops within loops and estimated the time it would take to test all possible executions. The answer was some millions of years. I immediately rejected programming through testing as a viable method. Testing was relegated to its rightful place which is to confirm the quality of the code after design, writing, and inspection.

My second idea was to simplify the program design so that it could fit my brain. That meant separation of concerns into manageable parts. The first level separation was into data and behavior; information and algorithms. This materialized as the data-centric architecture in Error! Reference source not found..

The central database was surrounded by application programs that retrieved data from the database, created and stored new data into it. Each application was further subdivided into subroutines; each designed and documented on a flowchart no larger than A4 before coding.

Figure 38: Database-centric Arcitecture DataCentricArchitecture-2.png

Research funding was granted in August, 1960, and I could build a team for creating tools for the different design offices. The tools were developed in close cooperation with their users. The applications were further subdivided into subroutines, each subroutine being designed and documented on an A4-sized flowchart. The hierarchy of our separation of concerns was:


Database Applications Subroutine call structure Flowcharts Code

Each office retrieves the data they need from the database, do its work aided by their application program, and stores the results in the database. In this way, a digital model of the ship emerged in the database as the different offices added their contributions.

One application extracted the data needed and produced the control tapes for Kjell Kveim's flame cutter; making our CAD/CAM system complete.

The Autokon software was initially written in assembly and later ported to FORTRAN. Its first version was deployed in 1963. It then consisted of some 50 kLOC assembly instructions. There were relatively few bugs in the released program. I believe the reason for this was that we designed the subroutines before we coded and tested them. Our slogan was:

Any methods that prevents a programmer from writing code, is a good method.

Autokon was maintained and marketed by a commercial company, SRS Shipping Research Services, and was a highly successful software product that was deployed by almost all major shipyards around the world.

Our original development team polished its methods and continued extending the system. A particularly traumatic event was caused by Edsger Dijkstra's letter to the editor of the CACM: "The GOTO considered harmful" REF. We already had structured design with our subroutine hierarchies, but the subroutines themselves tended towards spaghetti code with their unstructured GOTOs. The transition to structured thinking took me half a year of hard work when suddenly my brain clicked and changed from not understanding how I could suddenly work without the GOTO one day and not missing it the next. Simultaneously, my code changed from unreadable to readable.

Implementation My style of research is experimental. I start with identifying one or more persons who have some general need. I then build an intuition about how to satisfy this need and make the proposed solution concrete with a running program. Concrete examples then helps me hone the program and increase my understanding of the problem and its solution. I identify both expert and novice programmers as a target group needing readable code. (Remember Hoare's "One way is to make it (a software design) so simple that there are obviously no deficiencies" and "The first method is far more difficult.". We can't give the programmers better brains, but we can give them better tools:

Readable code is the key to correct and maintainable programs. Pure class oriented programming does not scale and tends to lead to code that is hard to read. Extensive subclassing can be an effective obfuscator. A strategy of divide and conquer can be achieved with suitably structured components. (Reenskaug, 2007)

After several unsuccessful attempts, BabyUML was an attempt at making UML models executable (Reenskaug, 2006). The BabyUML programmer achieved separation of concerns by encapsulating ensembles of objects within components that are characterized by their required and provided interfaces. The goal was to bring discipline to the universe of interlinked objects. My Squeak system contained some 300,000 objects and I needed some kind of modularization in order to divide and conquer the system. UML 2.xx


defines the Component metaclass as a kind of Class. It specifies a model element that owns and encapsulates a number of member elements and is characterized by its required and provided interfaces as illustrated in Figure 39 (modified from figure 3 in the article). I believed I could organize several hundred thousand objects recursively in a structure of BabyUML components so that I could deal with a manageable number in each component.

Figure 39: A Component is an object that encapsulates other objects SoSyM.components-03prob.png

Further experiments uncovered a serious flaw: While a particular component structure worked well for some use cases, it obfuscated other cases. For example, in resource allocation every activity is linked to the resources that shall perform it. These links are shown as dashed lines in the figure and clearly break the component boundaries.

The problem was resolved with BabyIDE. The static component structure of Figure 39 was replaced by a dynamic object structure that is tailored for each use case in DCI Contexts (Figure 30). BabyIDE was first released for others to play in 2008. First James Coplien and later others on the object composition mailing list73 helped identify and hone the DCI concepts and experiment with implementation examples in various mainstream languages74.

In 2015, I sharpened my focus to concentrate on the programming of IoT systems by non-expert programmers. I have called them Personal Programmers and their tool is an extended version of babyIDE.

Alan Kay and his team performed successful experiments with teaching children to program with Smalltalk-72. I spent a year as a visiting scientist at Xerox Palo Alto Research Center (PARC) in 1978/79. I worked with Smalltalk-76 and my impression was that while this version scaled to full-size problems, it lost the children. The children have moved further and further out of sight in later variants such as Smalltalk-80, VisualWorks, Squeak, and Pharo. As far as I know, the needs of Kay's children of all ages and Personal Programmers of all ages have not been addressed by any version of Smalltalk after Smalltalk-72 .

73 [email protected] 74 http://fulloo.info/

http://fulloo.info/