An Early Realization

 
 
http://melconway.com/patent/resources/email_me.html

The example shown here illustrates something even more important than the concrete flow model of the program and the drag-and-drop construction method. That is the artisan-friendly incremental development process with instant feedback the invention naturally makes possible, in which:

  1. both the tool and the program being built are running simultaneously, and

  2. as each component is dragged into the workspace and wired up, the effect of that component on the running application shows up immediately

This simultaneity of the tool and the artifact demonstrates this “hand-eye” tool as having some characteristics of a hammer rather than a compiler. The paper walks through the development process:

  1. The artisan starts by building an empty two-component application in Figures A-1 and A-2. This is the dataflow equivalent of a “hello world” program.

  2. Now notice in Figure A-3 when the Go button (the traffic light) is clicked, the application starts, opening the empty, untitled window. This is the user interface of the application being built piece by piece. We will track this window as components are added.

  3. Next, the artisan puts the name in the title bar. He does this by dragging out a “Text Source” component that squirts out a text object, typing the name “Fred” into the component, and wiring the send connector of the Text Source component to the Title Bar receive connector of the Resizable Window component. Figure A-4 shows the immediate result, in which the text is “projected” onto the title bar of the application’s window.

  4. Next, the artisan wires up two menus into the Menu Bar receive connector of the window component. He enters the text “File” and “Edit” onto the two menu components with the result shown in Figure A-7. (The two menu flow object are fed into a Collection component that builds a two-menu collection that is then fed into the Menu Bar receive connector of the window component.)

  5. At this point the artisan decides to test the menu structure he has built before proceeding with the text editing. He does this by temporarily wiring up a “Beep” component that puts out a Command flow object (see the discussion on page 19) that is projected into the menu. The function of the Beep component is to make the computer beep when the command flow object is picked (i.e., clicked) at the user interface. The command flow object is given the name “Ding.” When the application’s user clicks the “Ding” command (see Figure A-8) the computer beeps.

  6. Now the artisan adds the Text Editor component. This component has two send connectors. The top connector sources a collection of commands typical of the commands in an Edit menu: Undo, Cut, Copy, Paste, and Select All. The bottom connector sources an editable text string that the Window component projects. When the user of the application types or mouses in the text part of the window the Text Editor component receives events and it processes the text string appropriately, and the revised text string is re-projected by the Window component. Similarly, picking any of the commands of the Edit menu causes the Text Editor component to modify its text string, which the Window component then re-projects. All this behavior is implicit in the protocols inherited by every component; these protocols embody much of the essence of the invention.

  7. Finally, in Figure A-9, the artisan feeds some text into the receive connector of the Text Editor component and it is projected onto the window of the application.

  8. The rest of the appendix shows the artisan encapsulating part of the wiring diagram for reuse, testing this new user-defined component, adding a file open capability (Figure A-13), and reading in a prepared file containing a Shakespeare sonnet. He then tests the copy and paste commands (Figures A-14 and A-15).

  9. Finally, in Figure A-16, the artisan adds an exit capability that ends the application.

The remainder of the appendix discusses other aspects of the inherited protocols that give the tool and its artifacts the unique behaviors experienced by the artisan.

Build a Text Editor

Many of the figures in the patent were screen shots from an early-1990s vintage prototype development tool used as a proof-of-concept platform. After the patent issued I wrote a white paper to which this paper was an appendix. This appendix describes, step by step, how a rudimentary text editor would be built using the new technology.

Open
the Paperhttp://melconway.com/patent/resources/text_editor.pdfhttp://melconway.com/patent/resources/text_editor.pdfhttp://melconway.com/patent/resources_patent/text_editor.pdfshapeimage_3_link_0shapeimage_3_link_1