Visualisation : Must reads

The following links are must reads for people interested in visualisation.

• Why looking isn't always seeing: readership skills and graphical programming
• Software Visualisation (Book by MIT Press)

Does a visualisation system help, if the system has lot of moving parts?

All the real world systems have many moving parts. Some examples include web servers, transaction processing systems etc. The typical architecture of such systems would be some processing on the input data by various components which work in a specific fashion.

Program/code visualisation of such systems offer little help because they break the logical continuity of the processing. To visualise such systems we need to use views. Views in NPL UI are special layout of our code which enables easy understanding. Though the special layout helps us, it still is easier to grep the log to trace the execution of a single request through out the system.

This is the condition where we need to use some data tagging. Data tagging is a mechanism in which we mark a particular data as data of interest. Once the data is tagged the visualiser can visualise only the processing related to that peice of data.

The combination of Views and Data tagging can enable better tools for debugging and maintainance of large systems with too many moving parts.

What Pain points does NPL (intend to) address?

This is another way of asking "what problems does NPL intend to solve?".

or

"Why NPL?"

NPL intends to address the following problems of software development.

• Debugging
  • Debugging is a major problem in software projects because all the time you are asking the question why/how did this happen. NPL intends to solve this issue by visualising code with its history intact. Since visulalisation is visualisation of code, the programmer know what peice of code has done something and the history helps him identify the precise steps or states that led him to that specific failure. This is something regular debuggers are very bad at. This history keeping is similar to bi-directional debuggers or reversible interpretters. COP also makes it easy to capture precise high level info needed for visualisation, which is not the case otherwise.
• Testing
  • We usually test software by writing/setting up test cases. In NPL we can interactively test software by just changing editing the value on a signal. This way we can test most of the software without actually writing any test cases. Moreover, interactive testing helps peers to test your software more easily, because that does not involve writing any new test cases.
• Software Maintainance
  • One of the major problems of software today is software maintainance. Maintaining a large system is a pain because (i) the system is huge and (ii) the people who have designed the system usually are not the maintainers.
  • Visualisation helps in maintaining software because it provides a higher level interactive view of the source code, which will aid maintaining existing software even for newbies.
• Manage Complexity
  • Complexity of software is a major problem in software industry. Though writing programs in NPL does not help you reduce the complexity, viewing a visualisation of code will aid in understanding the complex relationships that underly the code.
• Enable team communication.
  • Communication among software teams is a problem because, we cannot precisely transfer the model in our head to the other persons head. The errors accumulate to create something entirely different from what was originally intended.
  • Visualisation helps communication between software teams because,when code is visualised we can much more precisely inform the other person of what is heppening.
  • This visualisation will not provide solutions in all the scenarios, but if people are smart enough you can always use the visualisation to communicate.

• Easy to learn
  • Programming languages are difficult to learn because they mostly model a real world concept in the language of the machine, which may hae its own idiosynchrasies. For everything we learn about a language we have an abstract model in our head.
  • But visualisation of code makes learning a language easy because, we can see how a peice of code works in a visualisation. This enhances the understanding of the language while reducing the time it takes to learn a language. If the language is taught in an incremental fashion with good visualisation , an average programmer can start programming in the new language in 2-3 days.

OOPSLA Submission Declined

The paper titled "A Brief introduction to NPL" I submitted at OOPSLA Onward 2006 has been rejected. Here's the email that i got just now. The reviews are pretty good (I guess, demo videos did their job well).

————————————————————————————-

Dear Suman,

I am sorry to inform you that your submission:

"An Introduction to NPL"

has been declined for inclusion in the Onward stream at the OOPSLA 2006 conference. (Out of 22 submissions, we were able to accept 10.)

Below you should find the text of reviews from members of the program committee that reviewed your paper.

You may wish to consider submitting your work for consideration in poster track. Posters provide an excellent forum for authors to present their work in an informal and interactive setting, and you will get additional visibility and feedback by presenting your work in poster form. Details on poster submission can be found at: http://www.oopsla.org/2006/posters.html

Yours faithfully,
Robert Biddle
OOPSLA 2006 Onward Program Chair

*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*

First reviewer's review:

>>> Summary of the submission <<<

The paper presents NPL, a language that affords visualization of the semantics
of a procedural program.

>>> Evaluation <<<

My main hesitation with this paper is that NPL doesn't actually seem that straightforward to read! I can see that it allows visualization of code, but is that visualization really helpful? Certainly, in the case of "hello world", the visualization provided is not actually helpful. Perhaps a larger example is needed to fully illustrate the efficacy of the technique.

I do like the idea of constructing a programming language for the sake of visualization, but because the arguments presenting NPL's visualization are uncompelling, it seems like perhaps a different approach from COP might be appropriate.

The related work seems lacking, even though it might not be. This is perhaps because the differences between the techniques are not made explicit enough. Reiterating the contributions of NPL and how they differ from each of the related pieces of work would greatly help the reader recontextualize this approach.

Not being familiar with the "Actor" model, means that it's very difficult to understand the comparison between the two approaches. More description of that model is needed so as not to confuse the reader.

*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*

Second reviewer's review:

>>> Summary of the submission <<<

The paper in introduces NLP as the first programming language specificallydesigned to be visualised. It describes elements of the language and of the Connection Oriented Paradigm (COP) which informs the approach. It makes the claim that such visualisation, which deliberately exposes the workings of the NLP code, rather than hide the implementation details as with 'traditional' visualisations, makes the code more readable for developers (provided they understand COP)

>>> Evaluation <<<

The paper describes a novel approach to visualisation, but I missed evidence for its raison d'etre – that it makes code easier to read for the developers. In my experience most developers 'problem solve' in terms of the language they are most familiar with. It is therefore unclear why they should prefer visualisations in the first place, paricularly as it is NOT claimed that higher levels of abstraction are being presented.

There is also an issue concerning the generality of the approach. In more than one place the paper claims that languages should be redesigned to be visualised, but in another it suggests that such redesigned languages would not be as effective as NLP.

There is good work here, but it needs to be more strongly focussed, and for ONWARD would need to demonstrate its potential for generalisation. Perhaps a paper reporting the results of the elements described under the 'Future Work' sectin is the one to look forward to.

————————————————————————————–

Though i feel sad about the rejection, this was something i had expected.

Also, most of it is the same feedback that i got from my trip to bangalore where i presented it at various places including the barcamp. My comments on this review are here.

My Comments on OOPSLA Review

Here are my comments on the review i recieved from OOPSLA. Though the comments are specific to the review, the criticism was the same at every place i presented this work. This post should also be useful to people who have watched the videos and have their doubts.

Note: I very well understand that its my failure to communicate well/ being unexplicit about these things that have lead to this review.

————————————————————————————-

First reviewer's review:

>>> Summary of the submission <<<

The paper presents NPL, a language that affords visualization of the semantics
of a procedural program.

The reviewer has understood my goals. But the paper was about the semantics of NPL and how it would aid visualisation, rather than the visualisation per se.

>>> Evaluation <<<

My main hesitation with this paper is that NPL doesn't actually seem that straightforward to read! I can see that it allows visualization of code, but is that visualization really helpful? Certainly, in the case of "hello world", the visualization provided is not actually helpful. Perhaps a larger example is needed to fully illustrate the efficacy of the technique.

As i have noted on page 1, the paper is not about the intuitiveness of visualisation generated. May be the abstract was misleading, but that was not the cited in the major contributions. If intuitive visualisation was the goal of the paper, the reviewers comments are very valid.

Also the term "intuitive" is relative. This relative part can be mitigated (i) by training, (ii) standardisation and (iii) by providing various highlevel views, like various modes in Eclipse.

I do like the idea of constructing a programming language for the sake of visualization, but because the arguments presenting NPL's visualization are uncompelling, it seems like perhaps a different approach from COP might be appropriate.

The reviewer on the whole liked the idea, so i am thinking in the right direction. But the reviewer comments that COP may not be right way to do it. I disagree with this argument for 2 reasons. (i) The claim that COP is bad because visualisation is bad, which is equivalent to saying that the application is wrong because the UI is unintuitive. (ii) There is no justification or an alternative technique cited to show that COP is the culprit for bad visualisation.

Though the "hello world" program can be considered a use case, i was trying to show the semantics of the program rather than intuitive visualisation. Moreover, COP is just a model for modelling the everything that happens inside a program. It gives me enough data to construct an intuitive visualisation, which is how it aids visualisation. I do not mean that it is the thing that is being visualised. An example how COP helps the visualiser to generate higher level views (other than the addition example in page 2) would have explained the concept in a better way.

The related work seems lacking, even though it might not be. This is perhaps because the differences between the techniques are not made explicit enough. Reiterating the contributions of NPL and how they differ from each of the related pieces of work would greatly help the reader recontextualize this approach.

This is a very good suggestion and i am working on that. The posts i make here are intended to compare my approach with other approaches. There is very little/no related work because, NPL is the first language to visualise code. There are no other similar approaches. The comparisions with other techniques will be rather subjective because, they are not general purpose as COP is.

Not being familiar with the "Actor" model, means that it's very difficult to understand the comparison between the two approaches. More description of that model is needed so as not to confuse the reader.

Another very good suggestion.

*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*

Second reviewer's review:

>>> Summary of the submission <<<

The paper in introduces NLP as the first programming language specificallydesigned to be visualised. It describes elements of the language and of the Connection Oriented Paradigm (COP) which informs the approach. It makes the claim that such visualisation, which deliberately exposes the workings of the NLP code, rather than hide the implementation details as with 'traditional' visualisations, makes the code more readable for developers (provided they understand COP)

Making code easier to read is my ultimate aim. The paper only presents the framework based on which i can reach that target.

>>> Evaluation <<<

The paper describes a novel approach to visualisation, but I missed evidence for its raison d'etre – that it makes code easier to read for the developers.

It "will" make it easy to read code for developer, but not at the moment.

In my experience most developers 'problem solve' in terms of the language they are most familiar with. It is therefore unclear why they should prefer visualisations in the first place, paricularly as it is NOT claimed that higher levels of abstraction are being presented.

Visualisation is good because, when you solve the problems using the abstractions provided by the language, the visualiser shows what the interpreter is thinking about the code rather than what you think about it (atleast at the lower level). Visualisation is important because the visualiser shows the code with its semantics intact, which amplifies your thinking process depending on how intuitive the visualisation is. At the moment, the visualisation makes it very easy to learn the language, so there is atleast one use of it.

Higher level abstractions are not yet implemented, but visualisation will be useful once they are inplace. Infact, its exactly the higher level abstractions that benefit from COP. The lower level abstractions will be repalced with rich source code as in ZStep95.

There is also an issue concerning the generality of the approach. In more than one place the paper claims that languages should be redesigned to be visualised, but in another it suggests that such redesigned languages would not be as effective as NLP.

The NPL language is made up of three components, (i) A interpreter based on COP, (ii) a language designed to suit the interpreter and (iii) A visualiser which understands the interpreter and the language and visualises code intuitively. These 3 compoenets are designed carefully so as to fit nicely with each other and give a productive programming experience. In all future versions, the 3 componenets will be modified without disturbing this mutual dependency. For example, a language feature may not be added if it can't be intuitively visualised.

But when you are visualising existing languages, one of the components "the language" is already defined. You cannot change it. Here we are trying to retro fit the interpreter and the visualiser to a "text centric" language which was designed without visualisation in mind. This aspect makes visualisation of NPL better than other languages.

The concepts are general in the sense that they can be applied. But all i am claiming is that their effectiveness is less and doing so will be a complex task (another case where i should have been more explicit). I also feel that such visualisation for existing languages is still better than what we have today. For example, a major difference in the quality of visualisation araises when concurrent process execution is considered (Something i am working on right now) .

A nice analogy would the difference between the smalltalk IDE and Eclipse. Since parts of the language were designed with IDE in mind, working in smalltalk environment is much more productive. OTOH, Java IDE's are not as powerful because, the language designers do/did/will not care about them. The same techniques are still applicable to Java IDE's , its just that they are not as easy and powerful to use.

There is good work here, but it needs to be more strongly focussed, and for ONWARD would need to demonstrate its potential for generalisation. Perhaps a paper reporting the results of the elements described under the 'Future Work' sectin is the one to look forward to.

A very good suggestion. However, I wonder why Onward is looking for useful ideas at this point rather than interesting ideas. I thought useful ideas should go to the regular track and wrote the paper in that mindset.

————————————————————————————–

Moral of the Story: Work on the intuitive UI. The rest of the theory part or the foundational part can come later. Moreover, be explicit in what you are trying to say. Dont leave it to the user to get the deductions, no matter how simple they are.

What’s Unique about NPL

[NPL Firsts]

• NPL is the first visualisable programming language.
• NPL is the first programming language to get the best of both worlds of text and graphics in a single language.
• NPL also has the simplest design for an interpreter, that actually corresponds to the actual working of an interpreter. Hence, it is a good model to teach students about it.
• All the pure languages i have seen have homogenous as in “Everything is a(n) X” where X can be an object/list/function. In NPL, everything is either a signal or a connect. There are two components instead of 1, that everything is made up of, which i think is unique to NPL.

There are some more minor things, but lets not add them to this list .

Note: Please feel free to prove me wrong on any of these claims. I am only talking from what i have heard and read.

A 2 Minute NPL Sales Pitch

This is the 2 minute sales pitch i use to answer questions like "What is NPL?" and "Why use NPL?"

" Reading a Novel is difficult, but watching a movie based on it is easy. Similarly, reading (source) code is difficult, but viewing a visualisation is easy."

Site Comments

Please leave the comments for improvement of the site here.

What does NPL mean?

NPL is an recursive acronym for "NPL Programming Language" (ala GNU or PHP).

Initially NPL was meant to be New Programming Language, but as time passed i felt that it was not that different from existing languages. Moreover the word "New Programming Language" was not sexy and geeky. So i decided to chose a recursive acronym NPL which made it geeky and sexy enough along the lines of APL.

Visualisation as an AST tree

A program can be visualised as a tree. Because a program is basically a tree. But there are 2 problems with visualising programs as a tree:

1. Many programmers think that program can be visualised as a tree because, the program we write is an AST (abstract syntax tree) We understand the execution of code, by visualising the execution of abstract syntax tree. For most part executing AST works well. But it fails when you have side-effects. The expression a=5 is an example. Though it can visualise (=,a,5), it cannot show how the values are stored in the symbol table. Though the ramifications of this in a procedural language might be less, they would be glaring once the language acquires name spaces and OO.
2. Though we visualise code as an executing AST, an AST is pretty much static. Though it can be visualised, it is no better than a call grah. It can only tell you what has happened, but not why and how it has happened.

These arguments apply equally well to pure functional languages because, though they do not have side-effects, they do have closures, which should be visualised in a similar fashion.

Some links to projects which visualise AST.

1. HOPS