Discussion questions from CS 7390 lecture

Date: 1/24/96

Presented by: Nicole

Topic: Program Visualization I

• Programming Environment-like fields looks interesting. They seem to have gone beyond the prototype stage (working on real life applications) and have a rich variety of tools. According to the author, its effiency exists but really depends on which tool is used. Why doesn't everyone use it? What would be required in performance, interface, type of tool, etc. to have people using it more?
• PROVIDE is presented as a prototype, working on concepts. Even if ideas behind it look good, is it a right choice to try to store all state changes? How can it be applied to a large pgm (which is where this kind of tool would be more useful)? Isn't is a dead concept before starting to use it? How does it deal with the scaling up problem?
• PROVIDE seemed to be a fairly limited system. The paper often dwelled on its shortcomings, but there were 2 concepts I found interesting: ability to select a state frame using boolean expressions and the ability to roll back to a previous point in the program. The latter requires a huge amount of memory (orders of magnitude above the data itself). Is this feature worth the overhead? Do others see themselves using a feature like this? How does PROVIDE deal with infinite (or even large) loops in a program? Does it stop when it detects them? Not save state? etc...
• FIELD's tools are slick and probably very useful to most programmers (especially "make"). What will it take for programmers to start using it? How do we "sell" them to "printf" debuggers who don't know what they are missing?
• In FIELD and other visualization systems, is it better to use color encoding or icons to distinguish different objects? Color has the advantage to stand out but it has little semantic meaning. Icons tend to be more meaningful. Perhaps, we should use both at the same time.
• The FIELD paper introduced a visual interface to several integrated tools. A goal of these tools was to promote program understanding and I think they do a good job for this intention. My only question is why aren't there more systems like this? I know I'ld use it for program analysis.
• A system for algorithm/data structure display for the purpose of debugging should be relatively easy to use, but should also be somewhat easy to learn. With the multiple windows and displays involved with even a simple example, does PROVIDE satisfy these requirements?
• PROVIDE supports only a subset of the C language, presumable in order to provide complete visualizations without confusion. How does PROVIDE excell in the information or processes it is able to display as opposed to a system which supports full language such as GDBX?
• In the FIELD paper, is the method effective for dealing with large data sets? It seems to be missing a good way to get an overview of data structures (i.e. a far away view). None of the three solutions presented on pgs 10/11 let you do this.
• PROVIDE is an experimental system, granted. But reading the paper has me questioning whether some of the stuff they provide could be done with a real system: for example, while reverse execution seems very useful, I am not convinced that a real language (like C) would be something in which this is possible. If one could predict or test out of all the states a program could arrive in, it would be a wonderful and useful solution though difficult.
• PROVIDE: Is frame gather feasible? Wouldn't I/O have to be part of state? How is this intercepted? For a 100Mhz RISC cpu 100 instructions/ state change (conservative) at least 8 bytes per state gives 8MB data/second. Alot of space with little debugging time.
• Temporal variable scope: What about recursive functions - does the scope end each call? This would be annoying. What are the semantics and scope of search expressions?
• FIELD: "Understanding of dynamic behavior", how is this supported? They have a heap view, what else? Is node selection via regular expressions useful? How are names identified?
• Provide seems to suppoter a good number of debugging characteristics that other systems do not support. It makes strong claims about its modification capabilities such as automatically rerunning its program history when users change program variables, why is this unique or important?
• FIELD claims it is a learning and development environment. However, its visualizations are of things like directory structures and make dependencies. Although these are important and may lead to a high level view of a programming environment, how do these visualizations aid in learning or development?
• Would the FIELD system be more useful if it porvided direct manipulation of process state representation, like the PROVIDE system?
• Can PROVIDE perform 'what if' analysis on the code efficiently via its use of storing all information in a temporal database?