CS 584 - Aligning development tools with the way programmers think about code changes
Upcoming SlideShare
Loading in...5
×
 

CS 584 - Aligning development tools with the way programmers think about code changes

on

  • 426 views

Paper review presentation for the CS584 "Human Aspects of Programming Languages" class presented on Oct 15th 2013. Presentation time: 25 min

Paper review presentation for the CS584 "Human Aspects of Programming Languages" class presented on Oct 15th 2013. Presentation time: 25 min

Statistics

Views

Total Views
426
Views on SlideShare
426
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

CS 584 - Aligning development tools with the way programmers think about code changes CS 584 - Aligning development tools with the way programmers think about code changes Presentation Transcript

  • 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
  • MOTIVATION Developers need to perform many similar source code editing operations that could be grouped and executed at once 2
  • MOTIVATION But there is no suitable tool that would allow to do that in an intuitive, consistent and error-free manner 3
  • 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
  • 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
  • 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
  • EXAMPLE. STEP 1 7
  • EXAMPLE. STEP 2 8
  • EXAMPLE. STEP 3 9
  • EXAMPLE. STEP 4 10
  • EXAMPLE. STEP 5 11
  • 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
  • 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
  • SHORT DEMO 14
  • 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
  • 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
  • QUESTION GROUPS Evaluation Regular expressions End-user mindset Experts vs nonexperienced programmers Real source maintenance concerns Other 17
  • 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
  • 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
  • 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
  • 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
  • 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