Network


Latest external collaboration on country level. Dive into details by clicking on the dots.

Hotspot


Dive into the research topics where Christopher Fry is active.

Publication


Featured researches published by Christopher Fry.


ACM Transactions on Information Systems | 1995

Experiments with Oval: a radically tailorable tool for cooperative work

Thomas W. Malone; Kum-Yew Lai; Christopher Fry

This article describes a series of tests of the generality of a “radically tailorable” tool for cooperative work. Users of this system can create applications by combining and modifying four kinds of building blocks: objects, views, agents, and links. We found that user-level tailoring of these primitives can provide most of the functionality found in well-known cooperative work systems such as gIBIS, Coordinator, Lotus Notes, and Information Lens. These primitives, therefore, appear to provide an elementary “tailoring language” out of which a wide variety of integrated information management and collaboration applications can be constructed by end users.


Communications of The ACM | 2001

Exploring the Web with reconnaissance agents

Henry Lieberman; Christopher Fry; Louis M. Weitzman

C A R EN R O SE N B LA TT Every click on a link is a leap of faith. When you click on the blue underlined text or on a picture on a Web page, there is always a (sometimes much too long) moment of suspense when you are waiting for the page to load. Until you actually see what is behind the link, you don’t know whether it will lead to the reward of another interesting page, to the disappointment of a junk page, or worse, to a “404 Not Found” error message. But what if you had an assistant always looking ahead for you—clicking on the Web links and Why surf alone? New agent technology can scout out the online terrain and recommend the best paths for you to follow.


Communications of The ACM | 1997

Debugging and the experience of immediacy

David M. Ungar; Henry Lieberman; Christopher Fry

face-to-face with whatever is being manipulated and experienced. For example, the steering system in a sports car, especially one with a mid-engine layout, lets you feel the road surface so you can tell when the road is slippery just by the feel of the steering. A good tool, like a high-quality wrench, becomes part of your hand, so you feel your hand is turning the bolt directly. The machinery disappears, and you feel connected to the object in question. A programming environment can also convey the A experience of immediacy, drawing the programmer closer to the program. When that happens, debug-ging is easier. The principle of immediacy can serve as a guide, keeping builders of programming environments on the path to productive environments. Like your favorite pizza, a programming environment can be described as a layered yet synergistic stack of ingredients: • Language semantics define how the user specifies a computation. • Affordances define how the user examines, changes, and runs programs. • A user interface brings the affordances into the users sphere of perception and action. The principle of immediacy can be brought to bear on each of these layers. For example, in the user interface, it helps if each chunk of information (e.g., each procedure) shows up as a visually distinguished and clearly legible unit. At the low level of visual perception, designers frequently employ cues that Debugging and the Experience o


international symposium on end-user development | 2013

Decision-Making Should Be More Like Programming

Christopher Fry; Henry Lieberman

Justify is an interactive “end-user development environment” for deliberation. Justify organizes discussions in a hierarchy of points, each expressing a single idea. Points have a rich ontology of types, such as pro or con, mathematical, or aesthetic arguments. “Programs” in this environment use inference rules to provide assessments that summarize groups of points. Interactive browsing modes serve as visualizers or debuggers for arguments.


ACM Sigplan Lisp Pointers | 1988

Common EVAL

Henry Lieberman; Christopher Fry

We propose that the Common Lisp standard be extended by adding to the language specification a short program, itself written in Common Lisp, to implement the EVAL function. We call this Common EVAL. The interpreters for every correct implementation of Common Lisp would be required to match the semantics of Common EVAL on valid Common Lisp expressions. It should treat other expressions as errors or as implementation dependent extensions. There are three cogent reasons for including a Common EVAL in the standard: First, since EVAL definitively specifies the behavior of Lisp programs, Common EVAL would insure uniformity of program semantics across implementations. Second, it would aid validation efforts, since the behavior of a particular implementation could always be compared to the behavior of Common EVAL. Third, it would facilitate the creation of debuggers and other program-manipulating programs that could be ported across Common Lisp implementations.


human factors in computing systems | 1995

Programming as driving: unsafe at any speed?

Christopher Fry; Henry Lieberman

Programming is dangerous. As programmers, we are still driving the equivalent of a ’57 Chevy: the chrome plated bumpers on our programming environment might look good while it’s cruising down the road, but it’s not very efficient with [mental] fuel, and it’s all too likely to crumple in a crash. No seat belts, no anti-lock brakes, and the rear view mirror is obstructed by the fuzzy dice. ZStep 94 is a reversible, WYSIWYG, animated, source code debugger that brings programming into the safety conscious ‘90s. It provides safety and efficiency options not found on the used car dealer’s lot. SAFETY EQUIPMENT All programs are accident-prone. It took lawsuits and bad publicity from such debacles as the Corvair and Pinto to wake up the car industry to designing cars to expect the possibility of crashes and protect the driver. Most current programming environments are like the old Corvair; when an error occurs, the programmer is left staring at nothing but the flaming wreckage of an error message and perhaps a core dump. Every program crash totals the vehicle, and nothing can be learned from the experience except to buy a new car and start over. A basic piece of safety equipment missing from most programming environments is the rear-view mirror. Since many traffic hazards sneak up on you from behind, the ability to see where you’ve just been is essential. ZStep 94 keeps a complete history of the computation, and can run the program both forward and backward. There is fine CHI’ Companion 95, Denver, Colorado, USA @ 1995 ACM 0-89791 -755-3!95/0005...


human factors in computing systems | 1995

Bridging the gulf between code and behavior in programming

Henry Lieberman; Christopher Fry

3.50 control over the level of detail, essential in those tight parallel parking situations. In conventional environments, even if some rear view is provided by stack inspection, the view is obscured by fuzzy dice and tree-shaped air fresheners such as the loss of intermediate values in the computation and the warning that objects in the mirror may be closer than they appear. ZStep 94 tries to assure that the view of past states resembles as closely as possible the original state. ZStep 94 installs airbags for the programming environment. An error is “fail-soft”, and doesn’t throw the programmer out of the programming environment, or into a special breakpoint loop. The recorded history of the computation, including partial results, is still available for inspection, and the program can be run forward or backward from any point before the error occurred. Even if the car is damaged, you can still examine the undamaged portions or the site of impact. The driver can walk away from the scene of the accident without a scratch. Further, the history keeping acts like an airplane’s “black box”, providing the information necessary for post-accident analysis and providing the basis for improving safety measures in the future. A video camera pointed out the side window recording the history is useful to understand those unfortunate side effects that you sometimes observe during the trip, just as the motorist who taped the Rodney King incident. Permission to copy without fee all or part of this ma%nal is granted provided that the copies are not made or distribulecf for direct commercial advantage, the ACM copyright notice and tile title of the publication and its date appear, and notice is given that copying is by permission of ACM. To copy o;herwise, or to rerwblish. reauires a fee and/or specific permwon. 3 I Demonstrations I May 7-11 1995 ■ CHI ’95 MOSAIC OF CREATIVITY unfortunate side effects that you sometimes observe during the trip, just as the motorist whcl taped the Rodney King incident. ZStep 94 keeps a first aid kit in the glove compartment for easy access to code repair tools. There is a convenient cigarette lighter interface to a data inspector. NAVIGATION TOOLS The goal of driving isn’t just to make the car go; it’s to get where you’re going. ZStep 94 replaces the ’57 Chevy door map pocket with a modern GPS satellite positioning system that displays a dynamic “you are here” cursor. When a bug happens, the programmer is usually placed in the role of an ambulance driver racing to the scene of an accident. S/he’s asleep at the wheel in the hospital garage when the car radio blurts out “lCar 54, where are you? There’s been a crash in the city. Victim last seen heading down Main (); Street”. The poor driver of the ’57 Chevy wagon ambulance has a map of the city, a full tank of Jolt, and flames painted on hood indicating a long history of being burned. The first problem is to find the scene of the accident. In fact, that’s the problem. The static representation of the code, the map, doesn’t help a whole lot because the dynamic execution goes the wrong way down one way streets, finds blind alleys that are too small to see on the map and discovers traffic jams that can’t be represented on static media. The task of the ambulance driver might not be much easier even if the driver happens to be the city planner, the same person who laid out the streets in the first place. For programming, the navigation :problem is understanding the relationship between the statl.c code and the dynamic process of execution. ZStep 94 displays the static code in the user’s editor buffer, exactly as it was typed, including ccomments and formatting. Expressions to be evaluated and the stepper’s state are highlighted, and a floating window follows the focus of execution and displays the current value. This is like a car with transparent floorboards enabling you to see the source cclde painted on the street. Street signs at every corner display the value of the executed source code that you just drove over. SPEED CONTROL We replace the ’57 Chevy 3-speed manual gearbox with a 4speed manual and automatic transmission, in both forward and reverse, permitting a variety of execution speeds. The fine control helps you find that one empty parking space in the Haystacks-Calhoun parking garage, yet lets you zoom out so you don’t miss the Forrest Ave. exit on the Trees Interstate Highway. Optional equipment includes cruise control for programmers too busy necking to click the mouse. FUEL EFFICIENCY The mental energy of the programmer is the fuel that runs programming environments. ZStep 94 features aerodynamic styling that conserves programmer energy. Care is taken to make sure that relevant information appears on the screen when and where it is needed and in the appropriate static and dynamic context. ZStep 94 provides one-click access from expressions in the code to their values and graphical output, and one-click access from graphical objects to the code that drew them. This reduces air drag caused by the programmer moving the mouse to another part of the screen, and air turbulence caused by the programmer turning his or her head to see information displayed in separate windows. This allc)ws ZStep 94 to get more mileage* out a very expensive resource hacker power. For a more academic treatment of ZStep 94, read and attend [4]. For a less academic treatment, come to the demo! REFERENCES [1] Ron Baecker, Two Systems Which Produce Animated Representations of the Execution of Computer Programs, SigCSE Bulletin, February 1975. [2] Marc Eisenstadt and Mike Brayshaw, The Transparent Prolog Machine: An Execution Model and Graphical Debugger for Logic Programming, Journal of Logic Programming 5(4), p.1-66, 1988. [3] Henry Lieberman, Steps Toward Better Debugging Tools for Lisp, ACM Symposium on Lisp and Functional Programming, Austin, Texas, August 1984 [4] Henry Lieberman and Christopher Fry, Bridging the Gulf Between Code and Behavior in Programming, CHI ’95. [5] Stewart Watt, Froglet: A Source-Level Stepper for Lisp, Human Cognition Research Laboratory, Open University, Milton Keynes, England, 1994. * Estimated Mileage: 33.3 expressions/hour for city hacking, 45 explhr on the Information Superhighway. However, your mileage may vary.


software visualization | 1997

ZStep 95: A Reversible, Animated Source Code Stepper

Henry Lieberman; Christopher Fry


Communications of The ACM | 1997

Programming on an already full brain

Christopher Fry


human factors in computing systems | 1997

On your marks, get set, browse!

Kevin Mullet; Christopher Fry; Diane J. Schiano

Collaboration


Dive into the Christopher Fry's collaboration.

Top Co-Authors

Avatar

Henry Lieberman

Massachusetts Institute of Technology

View shared research outputs
Top Co-Authors

Avatar

Diane J. Schiano

Interval Research Corporation

View shared research outputs
Top Co-Authors

Avatar
Top Co-Authors

Avatar
Top Co-Authors

Avatar

Hanna Adeyema

Massachusetts Institute of Technology

View shared research outputs
Top Co-Authors

Avatar

Jamie C. Macbeth

Massachusetts Institute of Technology

View shared research outputs
Top Co-Authors

Avatar

Kum-Yew Lai

Massachusetts Institute of Technology

View shared research outputs
Top Co-Authors

Avatar

Thomas W. Malone

Massachusetts Institute of Technology

View shared research outputs
Researchain Logo
Decentralizing Knowledge