Why I say task-specific programming languages instead of domain-specific programming languages
May 27, 2019 at 7:00 am 6 comments
I’ve written several posts about task-specific programming languages over the last few weeks (here’s the first one), culminating in my new understanding of computational thinking (see that blog post).
The programming languages community talks about “domain-specific programming languages.” That makes a lot of sense, as a contrast with “general purpose programming languages.” Why am I using a different term?
It’s inspired from my interaction with social studies teachers. They talk about “the language used in math class” and about “what language should we use in history?” History and mathematics are domains. If we talk about a programming language for all of history, that’s too big. It will be difficult to design languages to be easily learned and used. There are lots of tasks in history that are amenable to using computing to improve learning, including data visualization and testing the rigor of arguments.
“Task-specific programming language” makes clear that we’re talking about a task, not a whole domain. I don’t want teachers rejecting a language because “I can’t use it for everything.” I want teachers to accept a language because it helps their students learn something. I want it to be so easy to learn and use, that (a) it’s not adding much additional load and (b) it’s obvious that it would help.
I like “task-specific programming language,” too, because the name suggests how we might design them. Human-computer interface researchers and designers have been developing methods to analyze tasks and design interfaces for those tasks for decades. The purpose of that analysis is to create interfaces for users to achieve those tasks easily and with minimal up-front learning. For 25 years (Soloway, Guzdial, and Hay, 1994) , we have been trying to extend those techniques to design for learners, so that users achieve the tasks and learn in the process.
Task-specific programming languages are domain-specific programming languages (from the PL community) that are designed using learner-centered design methods (HCI). It’s about integrating between two communities to create something that enables integration of computing across the curriculum.
Entry filed under: Uncategorized. Tags: computing across curriculum, HCI, programming languages, task-specific programming.
6 Comments Add your own
Leave a comment
Trackback this post | Subscribe to the comments via RSS Feed
Computing Ed Research - Guzdial's Take 
1.
Raul Miller | May 28, 2019 at 11:09 am
My experience, here, is that when working with a rich programming language, only a small fraction of the language and environment gets used in the contest of a task. (I like the offerings of jsoftware.com, but have also had some good experiences with racket-lang.org and have some fondness for offerings like colorforth.github.io and a few others — but this also applies to mainstream mammoths like javascript).
With that in mind, I would like to propose “task specific dialect” or maybe even “task specific idioms”. One point being that mastering the language as a whole is not task specific. Another being that a task focus isn’t really a language focus (though issues of popularity and fads can tend to suggest otherwise).
That said: in many contexts, it’s not the language that’s the issue, except by coincidence. In many contexts, it’s the resources which can be reached with that language. For example, javascript can give good access to both graphic and audio resources, but files can be a struggle. (Actually, with how much it drifts over time, almost anything can be a struggle. There are many reasons for this.) But if you want to wire something to your computer, you might be better off with a “low powered” arduino setup…
2.
Raul Miller | August 26, 2019 at 12:02 pm
That matches my experience also.
My programming language might have a few dozen primitives. And maybe half-dozen or a dozen of them might cover most of what’s needed for a specific task. And, then, we might expand on that with a library of a few hundred routines which address common exercises.
[Or, for a popular language, iterate on this repeatedly, with the boundaries between library and language getting blurred, resulting in more “primitives”, more “libraries”, etc. And, as a result, all the numbers get bigger …]
Anyways, once we’ve got our basic system in place, we start hitting limits of human organizations. Learning more takes time, for each learner, people get frustrated with remaining issues, but most of the activity relates to bringing people up to speed on what’s already working, or some core of that.
3.
Raul Miller | August 26, 2019 at 12:04 pm
wait, I just replied to myself?
I really need to pay more attention…
But I should not be surprised that my experience matches my own.
How embarrassing…
4.
Iterative and interdisciplinary participatory design sessions: Seeking advice on a research method | Computing Education Research Blog | July 2, 2019 at 11:43 am
[…] We are not satisfied with this combined approach, because we’re going to be iterating on our designs over time. Most participatory design approaches are iterative, but I haven’t seen a way of tracking changes (in embodiment or mediating practices) over time. Right now, we’re working with Vega-Lite and JavaScript. In our next iterations, we’ll likely do different examples with Vega-Lite. Over time, we want to be building prototypes of data visualization languages designed explicitly for social studies educators (task-specific programming languages). […]
5.
Precalculus Task-Specific Programming for Building Image Filters from Matrix Operations (Precalculus TSP Part 1 of 5) | Computing Education Research Blog | September 20, 2019 at 3:01 am
[…] “What Mark Did This Summer.” I wrote several blog posts in the Spring (last in May, linked here) about “task-specific programming languages.” I’ve been thinking a lot about them over the […]
6.
Paradigm shifts in education and educational technology: Influencing the students here and now | Computing Education Research Blog | July 6, 2020 at 7:00 am
[…] proposal is about inventing a dynamic medium for thought — but in a particular set of classes, in a task-specific form. I still would love to have a general dynamic medium for thought (as Alan suggests), but I believe […]