Throats for a slot that are so narrow, you can’t tell them apart from where the two halves of the casing are glued together. They should be wide, funnel shaped to guide your card into the slot.~ Roedy (born:1948-02-04 age:69)
Imagine having an accountant as a client who insisted on maintaining his general ledgers using a word processor. You would do you best to persuade him that his data should be structured. He needs validation with cross field checks. You would persuade him he could do so much more with that data when stored in a database, including controlled simultaneous update.
Imagine taking on a software developer as a client. He insists on maintaining all his data (source code) with a text editor. He is not yet even exploiting the word processor’s colour, type size or fonts.
Think of what might happen if we started storing source code as structured data. We could view the same source code in many alternate ways, e.g. as Java, as NextRex, as a decision table, as a flow chart, as a loop structure skeleton (with the detail stripped off), as Java with various levels of detail or comments removed, as Java with highlights on the variables and method invocations of current interest, or as Java with generated comments about argument names and/or types. We could display complex arithmetic expressions in 2D, the way TeX and mathematicians do. You could see code with additional or fewer parentheses, ( depending on how comfortable you feel with the precedence rules ). Parenthesis nests could use varying size and colour to help matching by eye. With changes as transparent overlay sets that you can optionally remove or apply, you could watch in real time as other programmers on your team, working in a different country, modified code in classes that you were working on too.
You could use the full colour abilities of the modern screen to give subliminal clues, e.g. by automatically assigning a portion of the spectrum to each package/class using a pastel shades as the backgrounds to any references to methods or variables of that class. You could bold face the definition of any identifier to make it stand out.
You could ask what methods/constructors will produce an object of type X? What methods will accept an object of type X as a parameter? What variables are accessible in this point in the code? By clicking on a method invocation or variable reference, you could see its definition, helping sort out which version of a given method will actually be invoked. You could ask to globally visit all references to a given method or variable, and tick them off once each was dealt with. You could do quite a bit of code writing by point and click.
Some of these ideas would not pan out. But the best way to find out which would be valuable in practice is to try them. Once we had the basic tool, we could experiment with hundreds of similar ideas to make life easier for the maintenance programmer.
I discuss this further in the SCID (Source Code In Database) student project.
An early version of this article appeared in Java Developers’ Journal (volume 2 issue 6). I also spoke on this topic in 1997-11 at the Colorado Summit Conference. It has been gradually growing ever since. I have had quite a few requests for permission to build links here. You are welcome to create links, but please don’t repost the essay since the original changes frequently.
If you enjoyed this essay you might like this one on how to write like a newbie. There is a ton of stuff on this site quite unlike anything else on the web. Have a quick look at my home page or my Java Glossary which is a central place to find out everything you ever wanted to know about Java or perhaps my Gay & Black Glossary. If you want a bird’s eye view of all the things I’m involved in, see the home page.
You might also enjoy the famous essays Worse Is Better and The Rise of Worse Is Better on doing the right thing.
This page is posted
Optional Replicator mirror
Your face IP:[18.104.22.168]
You are visitor number|