Sponsored Link •
James Gosling talks with Bill Venners about visualizing software designs and understanding large-scale distributed systems.
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.
this!, Gosling describes the ways in which Jackpot can help programmers analyze, visualize, and refactor their programs.
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.