GSoC 2020: The Science
Published 5/17/20
In this post I'm going to talk about some of the research papers I've been reading related to visual programming, but first:
Progress
This week was mostly about discussing my design document. I got feedback from my mentors, as well as Mr. Evan (who is the lead developer on App Inventor). They all seem to mostly be on board with the design. The two contentious points are (1) Shadow blocks vs real blocks and (2) how to define dropdowns via Java.
I know I have a bit of a blind spot at the moment, because I don't understand the arguments against the proposed design. Luckily, I have a meeting with Mr. Lyn scheduled for Wednesday so that we can discuss the project! My goal is to be an active listener and to try and understand my mentors' point of view. I know they have lots of experience that I don't have, so I want to be able to utilize that, rather than fight against it. We'll see how well I can do! hehe
I also managed to get the design document posted Friday, which was awesome! Sadly, it hasn't gotten as much activity as I would have liked. I think the problem is that I posted it at a bad time. I wanted people to be able to look at the design document over the weekend, but it seems that it has gotten buried under all of the weekend help requests. My plan is to bump the post on Monday so that hopefully more people see it. But it could just be that it's not very interesting, so not many people are responding.
The last thing I did this week was put up a pull request into Blockly core. The pull request adds the ability to set shadow blocks programmatically. I probably won't need this, because it seems like the dev team is leaning towards using solid blocks over shadows. But it seemed productive and helpful so I wanted to put up the PR anyway. Hopefully it'll get accepted!
Reading
My reading this week made me realize how shallowly I had been thinking about visual programming. I had never thought about the process of designing a good language, or even what makes a language good or bad. I'd been floating around these ideas without consciously examining them.
I'm starting to feel like designing a visual language has to do with two questions:
- What do we want learners to understand?
- How do we get them to understand it quickly?
This is influenced by a quote from an Art of Research blog post I was reading:
Teaching students to actually understand things is politically nonviable... It seems as if the only way out is to find a way to let students build conceptual understanding fast enough that it makes a difference to measurable outcomes within a year, and performs better than [memorization-focused teaching] (Source)
It's not impossible to teach understanding, but it's really hard to teach it fast. I think that visual programming (and similar techniques) may be the solution.
What do we want learners to understand?
As with all things, the "field of computer science" is an infinite fractal of interest radiating in all directions. As such there are an infinite number of things we could want to teach. For example:
- Control flow and interpretation
- Object oriented design and design patterns
- Or just how to configure a store page
I think that a goal of "teaching people programming" may be too vague to be actionable. If you try to teach everything, you end up teaching nothing.
Grasp
Luckily, when Mr. Lyn designed Grasp he did not fall into this trap. Grasp is a language focused on modeling control flow, first-class procedures, and procedure activations.
The controller figure models what the computer is doing, traversing over the code. As they walk they instantiate machines (procedure activations) based on blueprints (first-class procedures).
I think this is a super cool system! Other visual languages have methods for examining control flow (for example being able to "step through" each block in a block-based language). But this is the first language I've seen where the control flow is explicitly modeled, in this case by arrows leading from one procedure activation to another.
Sadly Mr. Lyn never got a chance to try Grasp out with learners. But from my perspective it seems highly intuitive, and like it would be a great tool for teaching how a computer interprets code.
How can we get them to understand it quickly?
I think that my favorite article from this week was "The Psychology of How Novices Learn Computer Programming". It examined two different methods for teaching learners understanding, which I call "Scaffolding" and "Weaving".
Scaffolding gives the learner a mental framework which they can attach new information to. This usually came in the form of a visual metaphor/analogy for the computer.
Weaving forces the learner to actually contemplate the new information they have been given, weaving it into their existing mental models. This was usually done by having the learner explain a concept in their own words.
Both of these strategies were found to have a positive effect on how much the learner understood, which that made me really excited! I'm not sure how much visual programming languages can support the weaving part of learning, but they can certainly provide scaffolding. It can be built right into the structure of the language!
I think that the Grasp language above is a great example of this. The structure of the language provides a mental model of the computer in which it is a controller traversing your code, telling machines to do operations on data.
And (to tie it back in to education) the great thing about this is that having the language itself provide a model builds understanding quickly. You have to invest time up-front to build the language, but after that a teacher can teach programming in the same way they would with a text based language. They get the benefits of providing a model to their students, without having to take the time to explain the model.
References
Mayer, Richard E. "The Psychology of How Novices Learn Computer Programing." Computing Surveys 1981 booksc.xyz/book/36929621/c73a1ca
du Boulay et al. "The Black Box Inside the Glass Box: Presenting Computing Concepts to Novices." Computing Skills and the User Interface 1981 booksc.xyz/book/4158950/abb37b
Zhang, Lei and Oney, Steve "Styding the Benefits and Challenges of Immersive Dataflow Programming"
Smith, D.A "Croquet - a collaboration system architecture" 2003 booksc.xyz/book/31864418/abc201
Hart, Vi "Computation for Hands, Systems for Humans" theartofresearch.org 2019 theartofresearch.org/computation-for-hands-systems-for-humans/