Archive for September 27, 2019

Task Specific Programming vs Coding: Designing programming like we design other user interfaces (Precalculus TSP Part 3 of 5)

In the last two posts, I described a prototype task-specific programming tool for building image filters from matrix manipulations, and for building textures out of wave functions.

So, let’s tackle the big question here: Is this programming?

These are both programs. Both of them are specification of process. Both of them allow for an arbitrary number of operations. In the image filter example (second example), the order of operations can matter (e.g., if you change the red matrix through scalar multiplication, then add or subtract it with another matrix, versus the reverse order). The image filter is also defining a process which can be applied to an arbitrary input (picture).

Wil Doane pointed out that this is not coding. No program code is written — not text, not blocks, and not even by spreadsheet formula. This is programming by layering transformations which are selected through radio buttons, pull-down menus, and text areas. It’s really applying HCI techniques to constructing a program.

Probably the big sticking point here is just how limited the programming language is here. Notice that I’m using the term task-specific programming and not task-specific programming language in this series. The programming language is important here as a notation: What transformations am I using here, and what’s the order of execution? If you didn’t get the effect you wanted, the language is important for figuring out which card you want to change. I’m working on more prototypes where the language plays a similar role: A notation for explanation and rationalization. Amy Ko has a paper I like where she asks, “What is a programming language, really?” (See link here.) I’m not sure that the use of programming language here fits into her scheme. Overall, the focus in these two prototypes is on the programming not the programming language.

I spent several months in Spring and Summer reading in the programming language literature — some research papers, but more books like the Little series (e.g., The Little Prover), Shriram Krishnamurthi’s Programming Languages: Application and Interpretation, and Beautiful Racket. I started a Pharo MOOC because it covered how to build domain-specific programming languages. I plan to return to more programming languages research, techniques, and tools in the future. I have a lot to learn about what is possible in programming, about notations for programming, and about alternative models of programming. I need better tools, too, because I’m certainly going to need more horsepower than LiveCode.

But as I started designing the prototypes, I realized that my focus was on the user interface, not the language. Of course, text and blocks are user interfaces, but they use few user interface mechanisms. Even what I’m doing here is a far cry from what’s possible in user interfaces. I am using common UI widgets like buttons, menus, and text areas in order to specify a program. I realized that I didn’t need programming language techniques for these prototypes. By any measure of programming language quality, these are poorly-designed languages. My real focus is on the design process. This approach worked for getting prototypes built so that I could start running participatory design sessions with teachers.

The goal of task-specific programming: Usability for Integration

Here’s the goal I set out for myself:

I want to provide a programming experience that can be used in five minutes which can be integrated into a precalculus class.

In the small sessions I’ve had with 1 or 2 people, yeah, I think it worked.

  • I believe that this user interface is easier to learn and use than the comparable user interface (to do the same tasks) in text-based languages or even a block-based programming language like Snap! or GP.
  • I’d even bet that the language itself (seen in the above screenshots) would be less usable if it wasn’t embedded in the environment, e.g., those two examples above are not that understandable outside of the two prototypes. The environment (e.g., visualizations, UI elements, matrix displays, etc.) are providing more information than the language is.

There are some interesting usability experiments to explore in the future with task-specific programming.  The empirical evidence we have so far on task-specific programming is pretty impressive, as I described in my June 2019 Blog@CACM post (see link here) and which has been published in the September CACM on the topic of “designing away Computational Thinking” (see link here), which is what I was trying to do. Sara Chasins’ published work showed that she had people solving real programming problems in less than 10 minutes. Vega-Lite is amazing, and we’re finding social studies teachers building visualizations in it in less than 20 minutes.  I’m curious to explore other directions in improving usability through these tiny, task-specific languages. For example, it is very easy here to represent the language in something other than English words. Perhaps we might use task-specific programming to make programming more accessible to non-English speakers by targeting languages other than English as the notation.

There’s a cost to that ease of use. There’s a commensurate loss in generalizability. This is laser-focused on TASK-SPECIFIC programming. My prototypes are not Turing-complete. There are no loops, conditionals, or variables. There is decomposition (e.g., which matrix transformations and wave equations do I need for my desired goal), but no abstraction.

I’m inspired by Amy Ko’s blog post: Programming languages are the least usable, but most powerful human-computer interfaces ever invented (see post here).

  • Most attempts to improve on the usability problem are about making programming languages more usable, e.g., less complicated text languages or shifting modality to block-based languages. In general, though, the languages are just as powerful — and are still harder to understand than most students and teachers are willing to bear.
  • There have been attempts to embed programming languages within applications, e.g., VBA in Office applications or JavaScript to script Photoshop. Again, these languages tend to be just as powerful, and not much more usable.
  • I’m explicitly starting from an application (e.g., an image filter) and adding a programming language that only provides a notation for the facilities. It’s less powerful. I hope it’s more usable. I’m designing to be more like Excel and less like C.

Here’s the big idea here: We should design programming languages as we design other user interfaces. We should involve the users. We should aim to achieve the users’ goals. We should empower users. We should reduce their cognitive load.

Task-specific languages certainly can include more programming languages features.  For example, including variables with types makes sense for data science tasks (as in Bootstrap:Data Science). Those are part of data science tasks, and can help students avoid errors.  The critical part is including the components that help the learners with their tasks. My use of task-specific programming is really about learner-centered design of programming languages.

I have submitted two NSF proposals about building task-specific programming for precalculus and for social studies, both rejected. I spoke to both program officers. One told me it was impractical to propose a new programming language, and especially multiple languages. The officer pointed out that a language is hard and requires all kinds of infrastructure around it, like a community and a literature. I built these prototypes to explain what I meant by a “programming language.” It doesn’t have to be big. It can be little, be easy to learn and use, and fit into a one hour lesson in a precalculus class.

Alan Kay has argued for using the “real thing” as much as possible, because students might imprint on the “toy” thing and use it for everything. The concern is that it’s then hard to move on to better notations. I hope to avoid that fate by providing a notation that is so task-specific that it can’t be used for anything else. There is no support for abstraction here, alternative decompositions, or any kind of system design at all. It’s at the very lowest end of the Rich et al. learning trajectories.

Talking about trajectories is the segue to the next post.

I welcome your comments. Do you buy task-specific programming as a kind of programming?

September 27, 2019 at 7:00 am 6 comments

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,058 other followers


Recent Posts

Blog Stats

  • 2,038,394 hits
September 2019

CS Teaching Tips