sam aaron live coding music

An evening at VL/HCC: Sam Aaron live coding music to duet with St. Catharine College’s organ scholar in the chapel.


VL/HCC 2016: Connecting New Opportunities to Broader Populations

The IEEE Visual Languages and Human-Centric Computing (VL/HCC) occurred last week. After the conference and a few days of wandering around Cambridge, London, Shakespeare’s hometown, and a village founded in the year 689, I’m on a 12 hour flight back to the west coast. My trip report will largely be in the context of MIT App Inventor.

First, a few comments about the conference itself. This was my first time at VL/HCC, and I was impressed by the organization of  diverse talks and topics into sessions with common themes. The social events provided an excellent opportunity to meet with people from all over the world (a conference in Europe really attracts an international crowd). The collaboration with the PPIG (Psychology of Programming Interest Group) conference was a nice addition, although I did not stay for PPIG. I did feel the conference was missing opportunities for open discussion (very tight schedule) and I look forward to seeing more socratic opportunities in future VL/HCCs!

On MIT App Inventor & Blocks Programming

I attended the conference to present work I had done relate to MIT App Inventor, a web environment that enables users to create mobile applications with a drag and drop interface and visual, blocks programming language (Blockly). VL/HCC takeaways that are relevant to App Inventor:

Tutorials and puzzles go together.

App Inventor has always utilized step-by-step tutorials to introduce coding and concepts to novice programmers. There has been growing momentum for coding puzzles as a teaching resource. Kyle Harms (Washington University of St. Louis)  presented a qualitative study that directly compared motives and decisions middle school children make when choosing between tutorials and puzzles to learn to program. When given the choice to use tutorials and/or puzzles, the study found that most students used both tutorials and puzzles. More students enjoyed completing puzzles over tutorials, often because of the challenge. If the challenge became too great, students often switched to tutorials.

This work suggests that App Inventor should consider introducing puzzles to their learning resources to challenge learners, while maintaining tutorials to guide learners.

It’s not just blocks vs text languages.

A big sticking point to teaching programming with a blocks language is the transition from blocks to text programming languages. Pencil Code has always been a big favorite of mine as its environment enables programming both a blocks and text language; there is still the challenge of syntax errors made in the text representation that results in oddly formed blocks. Two alternatives presented at the conference were Agentsheets and Stride.

  • Michael Kolling (creator of BlueJ, Greenfoot) gave a keynote on Stride. Stride takes the benefits of a blocks language (modularity to avoid syntax errors, seeing available commands instead of having to recall them) and puts them into a text language that is Java-like. He calls this frame-based editing. In brief, frames replace Java’s brackets so code at different levels of indentation can be dragged around as a unit (see figure below).
  • Alexander Repenning (creator of AgentSheets) presented on computational thinking tools, defining computational thinking as an iterative process of problem formulation (abstraction), solution expression (automation), and solution execution & evaluation (analysis). Programming brings a complexity to learning computational thinking that is not desirable to courses where coding is not the focus. He proposes AgentCubes, a natural programming environment that provides simplicity in a scoped environment.
Stride: Frame-based editting (

Stride: Frame-based editing that mixes blocks and text languages.

Code smells matter in blocks languages

Code smells are deficiencies or anti-patterns in code, the result of poor programming habits (because working code may not be “good” code). Felienne Hermans (Delft University) is actively researching code smells in mediums such as excel and most recently blocks languages. Felienne looked at code smells in Microsoft Kodu and Mindstorms EV3, educational programming languages. Some of the most common “smells” she found between the environments include duplicate code, dead code, and unused fields (e.g. variables or parameters). I connected her up with Dr.(!) Sayamindu Dasgupta of Scratch and she plans to extend this research to Scratch.

App Inventor users are also guilty of code smells. I have seen too many procedures named procedure, procedure2, procedure3, chained if statements when if/else-if statements are more appropriate, and duplicated code when a procedure was needed. This sort of analysis would be perfect for a thesis and the implications for identifying good coding practices to teach with App Inventor is evident.

Coding isn’t just for the kids.

App Inventor has found popularity among end-user programmers (EUP): Professionals who learn to program to supplement there profession. We have even see some businesses use App Inventor as a mobile solution! A fair share of the papers focused on research towards end-user programmers. Of particular interest was a talk given by Chris Scaffidi (Oregon State) on the financial motivations of EUPs. He found that even when controlled for occupation, end-user programmers make more money, validating a widely held assumption that learning to program was profitable.

Although App Inventor’s primary focus in teaching programming and computational thinking to young people, research into how end-user programmers leverage App Inventor would be interesting.

My talk, Skill Progression in MIT App Inventor

I had the opportunity to give a short talk I wrote with my advisor to Hal Abelson on how people develop skills that generalize to other programming domains (computational concepts) as they created apps in App Inventor.

The talk described my work on quantitatively modeling the progression of skills of long-term users (20 apps created). In brief, I found that users tend to learn new blocks in their earlier projects, then use previously learned blocks to create more intricate apps later on. I also found that although users only use a fraction of blocks related to computational concepts (procedures, variables, lists, loops, boolean, conditionals), they typically get exposure to all the concepts.

From the feedback I received, people saw promise in this work to move towards understanding programming patterns at scale. I was counting individual blocks in projects and not considering how the blocks were connected. Considering how blocks are connected to identify common patterns would enable further research into how people learn to program with App Inventor. Questions that come to mind relate to code smells (see above) and comparing common patterns of novice users with patterns of advanced users, of people who learn App Inventor in a classroom setting with those who learn independently.

I have included links to a pre-print of this paper and an annotated version of slides I used. I have also include a link to my Master’s Thesis titled Progression of Computational Thinking Skills Demonstrated by App Inventor Users. My thesis work extends the work I did in my VL/HCC paper.

Finally, I have included a link to a short piece Hal Abelson wrote to the App Inventor community regarding the passing of Seymour Papert. Papert mentored Hal when Hal began researching at MIT. Hal’s essay gives a personal account of Papert’s influence on Hal and to App Inventor. I’ll close with a quote that I feel embodies what Papert stood for:

If mobile computing is so transformative, even dangerous—as in today’s concerns about security and privacy—perhaps the way to realize the best in mobile computing is to put the 11-year-olds in charge. As Seymour might have said, “When kids control mobile computing, mobile computing will be safe enough for kids to control.” -Hal Abelson on Seymour Papert


Leave a Reply

Your email address will not be published. Required fields are marked *