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.
