Why I say task-specific programming languages instead of domain-specific programming languages

May 27, 2019 at 7:00 am 2 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: , , , .

Learning to code is really learning to code something: One doesn’t just “learn programming” nor “learn tracing” Come hang out with Wil and me to talk about new research ideas! ACM ICER 2019 Work in Progress Workshop

2 Comments Add your own

  • 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…

    Reply
  • […] 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). […]

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


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

Join 6,273 other followers

Feeds

Recent Posts

Blog Stats

  • 1,664,033 hits
May 2019
M T W T F S S
« Apr   Jun »
 12345
6789101112
13141516171819
20212223242526
2728293031  

CS Teaching Tips


%d bloggers like this: