In May, my students and I published a paper in Communications of the ACM, "Putting a Teaspoon of Programming into Other Subjects" (see link here) about our work with teaspoon languages. It's a short Viewpoint, but we were able to squeeze into our 1800 word limit description of a couple of teaspoon languages, a definition of them, a description of our participatory design process for them, and some of the research questions we're exploring with them, like what drives teacher adoption of teaspoon languages, use multilingual keywords to engage emerging bilingual students, and identifying challenges to even our simplified notions of programming.
My students helped me to be consistent with our language in this piece, which was so helpful. I've been talking about teaspoon languages for awhile, and my language has likely changed over that time. They're challenging me to be more exact about what I mean.
For example, we use the phrase "teaspoon languages" and not "teaspoon programming languages." The term "teaspoon" comes from the shorthand "TSP" for "Task-Specific Programming." So, the "programming" bit is already in there. But in particular, I don't want to generate the reaction, "But, hey, that doesn't look like a real programming language..."
Programming languages are used to create software -- preferably, software that is reliable, robust, safe, and secure. The programming languages research community works to make programming more effective for people who are using those languages to create software. Programming as an activity can also be used to solve problems and explore domains. We're building languages for that latter purpose. Much of the programming that scientists and others do to solve problems and explore domains happens to be in programming languages that can also be used to create software (e.g., Python, R, Mathematica, MATLAB). Teaspoon languages (so far) can't really be used to create software for someone else to execute. They're not general. I don't think any of the teaspoon languages that we have created are Turing complete. But teaspoon languages are used to define the behavior of a computational agent. It's still programming.
Another question we hear quite a bit is "Isn't this just a domain-specific language?" We tried to answer that in the piece. Yes, teaspoon languages are a kind of domain-specific language, but for a very small domain -- a single task. The most critical part of teaspoon languages is "They can be used by students for a task that is useful to a teacher." DSLs are so much bigger than teaspoon languages. Maybe we can use DSL tools one day to make teaspoon languages, but so-far, we've built unique user interfaces and unique languages for each one. The focus is on meeting the need now, and we'll see if we ever get to generalizability and tools later.
The issues we study in our research with teaspoon languages don't have much overlap with the programming languages research community. I don't have good answers to questions like, "How do you support type safety?" or "Why can't I define a lambda in Pixel Equations?" So, we'll just call them "teaspoon languages" -- and let the "programming" word be silent in there.
No comments:
Post a Comment