This presentation reviews a proposed visual tool for generating source code transformations based on the edit-by-example principle. The tool aims to address limitations of existing approaches like regular expressions, IDE search/replace, and AST-based tools by allowing programmers to intuitively create custom transformations through direct manipulation of code representations. An initial prototype was implemented and evaluated via a user study, which provided insights for future iterations. The tool combines textual and graphical elements to naturally fit programmers' mental models of code structure.

1. ALIGNING DEVELOPMENT
TOOLS WITH THE WAY
PROGRAMMERS THINK
ABOUT CODE CHANGES
Presentation type: paper review
Class: CS 584 – Human Aspects of Programming Languages
Presenter: Sergii Shmarkatiuk
Date: 10/15/2013

2. MOTIVATION
Developers need to perform many similar
source code editing operations that could
be grouped and executed at once
2

3. MOTIVATION
But there is no suitable tool that would
allow to do that in an intuitive, consistent
and error-free manner
3

4. EXISTING APPROACHES
 Text-based


Regular expressions
SED + AWK
 IDE


tools
based tools
Standard ‘search and replace’ functionality
Refactoring features
 Structure-based
source code manipulation
tools (abstract syntax tree visualization)



A*
TAWK
Stratego/XT
4

5. DISADVANTAGES OF EXISTING
APPROACHES
Regular expressions Difficult to read and
understand
Powerful, but even more
 SED + AWK
difficult to read and understand




IDE-based
refactoring
Does not allow to create custom
transformations
IDE-based ‘search
and replace’
Treats source code as a flat,
structureless text
AST-based tools
Difficult to understand
5

6. PROPOSED SOLUTION
Design and implementation of visual tool
based on following principles:
Combination of textual and graphical elements
 From-example construction and iterative
refinement approach (based on edit-by-example
principle)
 Intuitive representation, which naturally fits into
the programmers’ perception of the source code
 Assisting developers with creating and
manipulating transformations
 Early errors detection and correction

6

7. EXAMPLE. STEP 1
7

8. EXAMPLE. STEP 2
8

9. EXAMPLE. STEP 3
9

10. EXAMPLE. STEP 4
10

11. EXAMPLE. STEP 5
11

12. METHODOLOGY
Clear definition of goal (source code transformations
generation) and target audience (experienced Javadevelopers)
 Prototype implementation
 3 iterations of prototype verification based on
compliance with Cognitive Dimensions
 Empirical study with few target audience
representatives






Pre-study interview
Training session
Code-editing task
Post-study interview based on Cognitive Dimensions
questionnaire optimized for users
Evaluation of study results using Cognitive Dimensions
framework
12

13. COMPARISON WITH ANOTHER
EXISTING SOLUTION
RegExp-based ‘search and replace’ in IDEs and
popular text editors
Advantages
Works by default in
Eclipse, IntelliJ IDEA,
NetBeans, Visual
Studio, Notepad++,
SciTE, UltraEdit, …
 Language-agnostic
approach
 Powerful and flexible
 Possibility of rollback

Disadvantages
Regular expressions
are difficult to read
and understand
 Special syntax for
matches reference
 Different
implementations in
different tools

13

14. SHORT DEMO
14

15. INSIGHT/IDEA
Two approaches could be integrated
1. Apply edit-by-example principle to generate
RegExp
var1 & var2
to regexp
(w*) & (w*)
2. Add functionality for handling RegExp block
references
firstMatch
secondMatch
(w*) & (w*)
transformation
firstMatch secondMatch
~(~1 | ~2)
15

16. INSIGHTS/IDEAS
FOR MY PROJECT
 Application
of similar methodology
 Combination of textual, graphic and UI
elements
 Study of target users’ perception/intuition
 Application of Cognitive Dimensions
framework
 Extension of edit-by-example approach
16

17. QUESTION GROUPS
Evaluation
Regular
expressions
End-user
mindset
Experts vs nonexperienced
programmers
Real source
maintenance
concerns
Other
17

18. QUESTIONS:
EVALUATION
Zhang, Chaoqiang: I am a little bit surprised that the
evaluation part of this part only has treatment group and
no control group. In my mind, if they could have another
group to use sed utility(maybe give them a little bit
training) and see if they could finish the task better, and
the comparison of these two groups maybe make the
evaluation more convincing
Mihai Codoban: The evaluation does not compare how
much better iXj is in comparison to existing techniques
(refactorings, “errors as todos”, etc). Does this disqualify
the authors’ statements that iXj is easier, faster and more
intuitive than current approaches? Is it just a fancy
language aware regular expression editor?
18

19. QUESTIONS: REGULAR EXPRESSIONS


Zhang, Chaoqiang: I am sort of concerned
about this language's expressive power. Can it
generally express any regular expression? If it is
not, maybe expert programmers (the target users
of this language) would prefer polishing their
regular expression skill to learning this tool?
Michael Mendes: Do you think future versions
of this tool should be IDE-independent, and why?
19

20. QUESTIONS:


END-USER MINDSET
Jun Xie: In the paper, there is one statement: This
design allows programmers to perform directmanipulation of a representation that aligns well
with their mental model of source code. What is the
programmers' mental model of source code?
Michael Slater: I looked through this paper and
couldn't find any listing of the programmers' mental
models that were used to compare to the
representations of the tool. I could see the basic Java
code structure in the paper, but that was it. Is this
paper claiming that programmers think of their
software only in terms of the structures Java offers?
Can we legitimately claim anything regarding
programmers' mental models when the programmers
didn't know the source code used in the study?
20

21. QUESTIONS:
EXPERTS VS NON-
EXPERTS



Catharina Vijay: How could iXj help people less
experienced at code maintenance?
Wojtek Rajski: I understand that iXj has experts in
mind. But novice programmers will sometimes realize
during the build process that they have to change
how a fundamental part of the code works. How
would the requirements for CDs change for
intermediate level programmers?
Krishna Pratik: I believe expert programmers would
not be good participants as they might
unintentionally portray using the tool as being too
simple to use for code transformations. To better test
the utility of the application, shouldn't the study be
conducted by novice-middle experienced
programmers?
21

22. QUESTIONS:
OTHER
William Jernigan: What can we do as study
designers to avoid situations where participants
may diverge from the expected behavior like
Boshernitsan et al experience, cited in the
Metrics section where the authors say: “two
participants decided to perform several
transformations that were not on the list,
because they ‘seemed appropriate.” ?
 William Jernigan: In the beginning stages of
the design process, Boshernitsan et al studied
development/change logs for TEX, XEmacs, and a
transcript from Martin and Koss. How specific
are these change logs to the design they wanted
to achieve? How do we determine what to review
and study when creating a design besides the
specific user for whom we are designing?

22