For the past several years, Java's creator James Gosling has been working at Sun Labs, researching ways to
analyze and manipulate programs represented as annotated parse trees, a project called Jackpot.
Compilers have long built parse trees when they translate source code into binary. But traditionally,
programmers have worked with source code primarily by manipulating text with editors. The goal of the Jackpot
project is to investigate the value of treating the parse tree as the program at development
time, not just at compile time.

In this interview, which is being published in multiple installments, James Gosling talks about many aspects
of programming.

In Part I: Analyze this!, Gosling describes the ways in which Jackpot
can help programmers analyze, visualize, and refactor their programs.

In Part II: Failure and Exceptions, Gosling talks about how to build solid apps, organize your catch clauses,
scale checked exceptions, and deal with failure.

In this final installment, Gosling talks about visualizing software designs and
understanding large-scale distributed systems.

Visualizing Software Designs

Bill Venners: One thing I think could help people design software is
being better able to visualize what they're designing. If you design a chair, you can see it.
You can sit in it and get the feel of it. But when you design an object, you can only see
what's on the screen, which is often just code.

You have said about your Jackpot research project that if the notion of truth in a program
is the abstract syntax tree, not text, you can display the program in a lot of interesting
ways. I would imagine that if the abstract syntax tree is stored persistently, then the code
is just one view. In fact, you could have many different code views. If someone doesn't
like curly braces, for example, they wouldn't have to look at curly braces. I could also
imagine that programs could be viewed at more abstract levels that would help people see
problems with their design. Is that kind of visualization what you're thinking about in
your research?

James Gosling: Yes. Historically, people have used all kinds of ways
to try and visualize their programs. Some are simplistic and kind of obvious, others are
not. The mathematics world, for example, has a notation for expressing mathematical
formulas that is much richer and more evocative than plus, minus, star, slash,
parentheses, and variable names. People are pretty good at looking at a page of
mathematics that has square root signs and exponents. So if you've got a piece of code
full of gnarly math, it's probably a lot more comprehensible to the people who understand
gnarly math if you actually display it in something that looks like conventional
mathematics. That's one of the things our system will do. There have also been a
number of attempts of come up with notations for visualizing control flow that is
different than just code. For example, Nassi-Shneiderman diagrams are pretty good for
representing decision trees.

In our research, we've been working to build a framework into which you can plug in
various kinds of visualization techniques. The extent to which these visualization
techniques are helpful is often context dependent. If you are writing a ray tracer, for
example, the ability to do mathematical layout of code probably helps a lot. If you are
writing a banking application, on the other hand, mathematical layout probably doesn't
help at all. But in a banking application, specialized visualizations for state diagrams,
database modeling, and database access might help. If you crack open database
textbooks, you'll see diagrams of what databases look like. Maybe your program ought to
look like that. Maybe your program would be a lot more comprehensible if it looked like
that.