Discussion of Programming on an Already Full Brain by Christopher Fry

1. Discussion of Programming on an Already Full Brainby Christopher Fry Dean L. Zeller CS79995 Program Comprehension Dr. Jonathan Maletic Department of Computer Science Kent State University

2. About the Paper • Informal writing style, first person • Easy to read – no technical concepts required • Promotes author’s work, Emacs Menus • Uses Lisp as language for examples • No empirical proof of effectiveness – just claims and supporting logic • Goal: to help programmers make better use of their biological memory by providing a tool that helps to remember and organize the pertinent information for the task at hand.

3. About the Author Bio: In High School, Fry was mediocre in French. As an undergrad only fair at Spanish and later became a C programmer who couldn't debug his own code. Then he discovered Lisp at the MIT AI Lab and realized the problem was not so much his brain but the convoluted conventions of languages designed for inhuman machines. The rest of his life has been spent working on tools that make programming easier. Fry is a founder of Clear Methods and the first guy to work on the Water language.

4. Work History • In 1997, he was chief technical officer of PowerScout Corp, a Boston developer of agent-based browsers for the web. • Founded Clear Methods company with Mike Plusch in 2001. • Co-inventor of Water and ConciseXML • Past work experience: Bowstreet software, MIT, PowerScout, Harlequin, Coral Software, BBN, IBM, Symbolics

5. Similar Publications by Fry • Thomas Malone (MIT), Kum-Yew Lai (MIT), and Christopher Fry (MIT). Experiments with OVAL: A radically tailorable tool for cooperative work. Proceedings of the ACM Conference on Computer-Supported Cooperative Work, 1995. • Henry Lieberman (MIT) and Christopher Fry (PowerScout). Zstep95, a reversible, animated source code stepper. Software Visualization: Programming as a Multimedia Experience, 1997. • Christpher Fry (PowerScout). Programming on an Already Full Brain. Communications of the ACM, April 1997. • David Ungar (Sun), Henry Lieberman (MIT), and Christopher Fry (PowerScout). Debugging and the Experience of Immediacy. Communications of the ACM, April 1997. • Henry Lieberman (MIT), Christopher Fry (Bow Street Software), and Louis Weitzman (IBM). Why Surve Alone?: Exploring the Web with Reconnaissance Agents, Communications of the ACM, August 2001.

6. Digital Memory vs. Biological Memory • Digital memory • computer memory, available for searching, storing, calculating, and other low-level tasks. • Biological memory • human memory, available for problem solving, programming strategies. • Conflict: programmers are forced use biological memory for tasks better suited for digital memory. digital memory biological memory

7. Momentum and Roadblocks • Momentum: working on and developing an idea uninterrupted. • Roadblock: an interruption in the programming progress • A programmer is going along with a great idea, and suddenly BAM! A roadblock stops the momentum. • Progress stops until the solution to the roadblock is found, no matter how simple the answer. • Even after solving the roadblock, the programmer has to start all over to build up the momentum again. • When a programmer hits a roadblock, what next? • Guess • Look it up • Seek help from others

8. Principle of Immediacy • Programmers need to see the immediate usefulness of new learning: the skills, knowledge, or attitudes they are working to acquire. • Some languages have a TON of commands and keywords. • Lisp has over a thousand • Use of software libraries add to the complexity. • How to look up unknown information quickly?

9. Limits of Biological Memory • Programming is a demanding task on the brain. • Humans can store/retrieve only so much at a given time. • Humans are good at abstract and higher-level knowledge. • Computers are good at storing and searching large amounts of data quickly.

10. Text Editors • “The nonsolution” • Easy to use, available anywhere • Can type in anything, legal or illegal • Compiler must catch syntax errors • Violates principle of immediacy

11. Forms-Based Languages • “The bureaucratic solution” • Form permits programmer to enter text into named slots • Advantages: • Reduces possibility of syntactic error. • Takes advantage of static knowledge of language • Disadvantages: • Loses the flexibility of text editor. • A dynamic context would also be useful. • Severe space inefficiencies – designer cannot predict the optimal size for an argument.

12. Iconic Languages • “The straightjacket solution” • Programmers use palettes of functions • Advantages: • Educational uses • Spelling is not a problem • Syntactically incorrect code cannot be entered • Disadvantages: • For large programs, iconic code is a disaster! • Programmer must remember meanings for a large set of icons.

13. Fry’s Solution: Emacs Menus • Emacs – famous editor • My first editor, KayPro 2400 • Holding down mouse button brings up a pop-up menu. • Analyzes surrounding code to display the choices that make sense at the point of insertion.

14. Just In Time Help • Pop-up menu • Emacs Menus Common Lisp database • Analyzes code to provide options that make sense at the point of insertion • Type-checking errors • Useful for a weakly-typed language, such as Lisp

15. Inside-Out Parsing • User clicks on code, parse of underlying text is started • Context specific menu of information • Starts at point of insertion, and parses outward

16. Coding via Mouse • Catch errors sooner • Spares the programmer from having to type code • Eliminates risk of making a mistake that forces programmers to go through a compile-debug-edit cycle • Displays typical values • Balanced delimiters (a big deal in Lisp)

17. Inserting Variables and Functions • All variables available in current scope • Users type variable names only once (to declare) • Prevent inconsistent spellings • No undeclared variable errors

18. 4D Menus • Lisp has over 1000 functions. How does one organize them on a 12801024 pixel window? • Linear menus are limited to 20-30 items. Hierarchal menus increase this to a couple hundred. • Pages: jiggling the mouse to the left or right flips between pages • 50 item pages, stacked five levels deep, gives 250 items without scrolling. • With hierarchical submenus, it can go to several thousand items.

19. Menu Item Ordering • Alphabetical • Return type • Chapter titles in textbook • Common vs. uncommon

20. Paper Conclusions • The right software developer tool can reduce errors and increase productivity. • 4D menus provide thousands of operations without requiring the biological memory that would otherwise be filled with thousands of words. • Emacs Menus provides this kind of programmer support. • Would benefit greatly from user studies.

21. My Conclusions • Fry makes an excellent case for providing programmer support. • Addresses issues of great concern to many programmers. • Does not provide empirical results measuring the reduction of errors and increased productivity. • Focused on Lisp – would have liked examples in other languages

22. Appendix – Emacs Menus Figures • Figure 2 – Top-level menu • Figure 3 – Context Information Menu • showing information about the second argument to + • Figure 4 – Typical Values menu • for an argument to + • Figure 5 – Delimiters menu • Figure 6 – Top-level Insert Function Call menu • Figure 7 – Type organization menu • Figure 8 – Debug Tools menu • Figure 9 – Find Symbols dialog

23. Top-Level menu

24. Context Information Menu

25. Typical Values menu

26. Delimiters menu

27. Insert Function Call menu

28. Insert Function Call menu (organized by return type)

29. Debug Tools menu

30. Find Symbols dialog