Posts tagged ‘computing across curriculum’

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

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.

 

May 27, 2019 at 7:00 am 6 comments

What we want kids to learn through coding: Requirements for task-specific programming languages for learning

Marina Umaschi Bers has an essay from last year that I’ve been thinking about more since the discussion about task-specific programming languages (see previous post here). Her essay is: What Kids Can Learn Through Coding.

In creating her ScratchJr kitten, Liana practiced some of the most powerful ideas of computer sciences:

  • She learned that a programing language has a set of rules in which symbols represent actions.
  • She understood that her choices had an impact on what was happening on the screen.
  • She was able to create a sequence of programming blocks to represent a complex behavior (such as appearing and disappearing).
  • She used logic to correctly order the blocks in a sequence.
  • She practiced and applied the concept of patterns, which she had learned earlier during math time in class.

ScratchJr is just what the name suggests — a programming language like Scratch, but made even simpler and aimed at young children.  See a description of activities with ScratchJr here.

What I particularly like about Marina’s list is how it connects to the learning trajectories work that I’ve been talking about here and highlighted in my 2019 SIGCSE Keynote (as described in Ann Leftwich’s tweet). Ideas like “Precision and completeness are important when instructions in advance” are hard to learn. Knowing that the computer requires precision and isn’t trying to understand you like a human is really the first step to getting past Roy Pea’s “Superbug.” These are important ideas to learn. I’ll bet that most students don’t have that insight (even when they get to undergraduate education). That would be an interesting research question — what percentage of University students know ideas like the importance of precision and completeness in computer instructions?

I have a hypothesis that these fundamental ideas (what Marina is pointing out, what Katie Rich et al. are noting in their learning trajectories) even transfer. These aren’t higher-order thinking skills. This isn’t about learning a programming language to be used across the curriculum. Rather, these concepts are about recognizing, “The nature of programming.” I bet that students will learn these and remember them in new contexts, because it’s about what the computer and programming is. Once you learn that computer instructions require precision and completeness, I predict that you always remember that programming has that requirement.

What else do we want students to get from coding?

Please note that I’m not talking about “computational thinking.” I’m setting aside the possibility of more general “mindset” benefits.  Right now, I’m thinking in pragmatic and measurable terms.  We can measure students learning the concepts in the trajectories.  We can measure if those concepts are retained and applied later.

This is why task-specific programming languages are interesting to me. The goal isn’t “learning programming” (and I’ll argue in a few weeks that that isn’t a thing). The goal is using code to improve learning about something other than programming skills. Notice the term that Marina uses in her essay: “the most powerful ideas of computer sciences.” She’s not teaching students how to program. She is teaching them what programming is.

A task-specific programming language used in an educational context should improve learning in that context. It should provide some leverage that wasn’t there previously (i.e., without the computer).

  • For the social studies educators with whom I am working, programming allowed them to build visualizations to highlight the features that they wanted to highlight, from large data sets. They found it easier to get the visualization they wanted via code than via Excel (or so they told us). The programming managed scale (e.g., if you had three data points, you could graph them by hand pretty easily).
  • The programming language can find mistakes that the student might not notice, and provide feedback. That’s how I’m trying to use programming in a history class. A program can represent an argument. A computer can find gaps and weaknesses in an argument that a student might not see.
  • The Bootstrap folks argue for the value of rigor. I think they’re referring to the specificity that a program requires. Writing a program requires students to specify a problem and a solution in detail, and can lead to greater insight.
  • A program can make something “real.” Bootstrap: Algebra works, in part, because the students’ algebra makes a video game. It breathes life into the mathematics. That a program executes is a powerful motivator.

I think what Alan was telling me in the comments to an earlier blog post about task-specific programming and again in the blog post on multiple languages in schools is that it should also lead to generativity. If I teach you a programming language that solves your task and doesn’t connect to more powerful ideas and languages, then I have taught you a dead-end solution. I might achieve the goals I’ve identified earlier, but I’m not helping you to solve the next problems or the problems you’re going to face next year or next class. I’m not sure right now how to achieve that goal, but I recognize the value of it.

What are other requirements for the use of task-specific languages for learners?

April 22, 2019 at 7:00 am 3 comments

A Task-Specific Programming Language for Web Scraping in which learners are successful very quickly

One of the papers that has most influenced my thinking about task-specific programming languages is Rousillon: Scraping Distributed Hierarchical Web Data by Sarah Chasins, Maria Mueller, and Rastislav Bodik.

Rousillon is a programming by demonstration system that generates a program in Helena, a task-specific programming language for Web scraping (grabbing data out of Web pages). Below is a flow diagram describing how Rousillon generates a program in Helena.

Check out the Helena program at the far right of that diagram. Yeah, it’s a block-based programming language — for adults. The choice of blocks was made explicitly to avoid syntax errors. If the user wants to modify the synthesized code, she is guided to what can be changed — change a slot in a block, or delete or move a block.  It’s a purposeful choice to improve the user experience of programming with Helena.

Helena doesn’t do statistics. It doesn’t do visualizations. It does one thing extremely well.  Maybe it’s competition for R, because people do use R for Web scraping.  But it’s far easier to do web-scraping in Helena.

The below graph is the one that blew me away. They ran a study comparing Rousillon and Selenium, a comparable Web data scraping system. Everybody using Rousillon completed both tasks in a few minutes. Most people using Selenium couldn’t finish the tasks (if the bar goes all the way up to the top, people ran out of time before completing).

But here’s the part that is just astonishing. Notice the black border on some of the Selenium bars in that graph? Those are the people who knew Selenium already. NONE of the Rousillon users knew the language before hand. That time for the Rousillon users includes training — and they still beat out the Selenium users.  A task that a trained Selenium user can solve in 25 minutes, a complete novice can solve with Rousillon and Helena in 10 minutes.

Here’s a goal for task-specific programming languages for adult end-users: It should be easily learned. End-users want to be able to succeed at simple tasks nearly immediately. They want to achieve their task, and any time spent learning is time away from completing the task. It’s about reducing the costs of integrating programming into the adult’s context.

The goal isn’t exactly the same when we’re talking about learners in non-CS classes. I think it’s about balancing two challenges:

  • If the learning is generative and will be used again, then some additional learning is valuable. For example, learning about vectors in MATLAB and lists in Racket make sense — you’ll use them whenever you will use either language. It’s a concept that can be applied whenever you use those languages. (I have a blog post that talks about generativity and other goals for task-specific programming languages next week.)
  • But we don’t want to turn algebra, history, or economics classes into CS classes. We don’t want to make mathematics or social studies teachers feel like like they’re now teaching CS. When is it too much CS that you’re teaching?  Perhaps a rule of thumb is when the teacher is teaching more than they could learn in a single professional development session. That’s just a guess.

April 15, 2019 at 7:00 am 3 comments

Why we should explore more than one programming language across the curriculum

Ben duBoulay and I wrote the history chapter for the new Cambridge University Press Handbook of Computing Education Research (mentioned here).  A common theme has been the search for the “best language” to learn programming.  We see that from the 1960’s on up.

One of the criteria for “best language” is one that could be used across the curriculum, in different classes and for different problems.  I was reminded of that when we recently ran a participatory design session with social science teachers.  We heard the message that they want the same language to use in history, English, mathematics, and science. The closest we ever got was Logo.

But now, I’m not sure that that’s the right goal, for two reasons:

  1. We have no evidence currently that language-specific programming knowledge will transfer, nor how to achieve it.  If you use one language to learn algebra (e.g., Bootstrap Algebra), do students use or even reference the language when they get to (say) science class?  Maybe we could design a language with algebra-specific representations and biology-specific representations and history-specific representations and so on, but it might make the language unnecessarily complex and abstract to make it cover a range of domain constructs.  My bet is that the fundamental computational ideas do transfer.  If you learn that the order of language elements matters and the specificity of those language elements matter (two early learning goals as described in the learning trajectories work), I’ll bet that you’ll use those later. Those aren’t about the programming language. Those are about programming and the nature of programs.
  2. School is so much more diverse and heterogeneous than adult life. I’ll bet that most of you reading took physics and biology at some point in our lives.  I don’t know about you, but I rarely use F=ma or the difference between mitosis and meiosis in daily life.  On a daily basis, we tend to solve problems within a small range of domains. But our students do take science and math and history and English all in the same day.  In adult life, there are different programming languages for different kinds of problems and different domains (as Philip Guo has been talking about in his talks recently). Why shouldn’t that be true for K-12, too?

The key is to make the languages simple enough that there’s little overhead in learning them. As one of the teachers in our study put it, “one step up from Excel.” Scratch fits that goal in terms of usability, but I don’t think it’s a one-size-fits-all solution to computing across the curriculum.  It doesn’t meet the needs of all tasks and domains in the school curriculum. Rather, we should explore some multi-lingual solutions, with some task-specific programming languages, and think hard about creating transfer between them.

The single language solution makes sense if the language is hard to learn. You don’t want to pay that effort more than once. But if the language fits the domain and task, learning time can be minimal — and if well-designed, the part that you have to learn transfers to other languages.

 

April 8, 2019 at 7:00 am 21 comments

Integrating CS into other fields, so that other fields don’t feel threatened: Interview with Jane Prey

I really enjoyed the interview in the last SIGCSE Bulletin with Jane Prey.  Her reason for doing more to integrate CS into other disciplines, at the undergraduate level, is fascinating — one I hadn’t heard before.

Other fields are nervous because they think we’re taking so many students from them, and universities are nervous because they’re afraid of losing us to industry. I would hate to lose any other faculty position to add a CS professor. I really believe it’s important for computing professionals to be well-rounded, to be able to appreciate what they learned in history, biology, and anthropology classes. We need to do a better job of integrating more of a student’s educational experiences. For example, how do we do more work together with the education schools? We just aren’t there. We have to work cross-disciplines to develop a path forward, even though it’s really hard.

June 1, 2018 at 7:00 am Leave a comment

In Finland, Teaching Computer Science across the Curriculum

I am excited to get quoted (and correctly!) in an article about the Finnish approach to using programming to teach across the curriculum.  The article gets the idea a little wrong — it’s not really about teaching CS without computers, as the title suggests.  The key idea is that “Finnish children are taught to think of coding and programming more as tools to be explored and utilized across multiple subjects

Liukas pushes back at the idea that children are already tech-savvy simply because they seem to be able to navigate an iPhone intuitively. She’s particularly fond of this quote from the American computing professor Mark Guzdial:

We want students to understand what a computer can do, what a human can do, and why that’s different. To understand computing is to have a robust mental model of a notional machine.

In other words, knowing how to use something isn’t the same as understanding how it works. And because programming can be taught in so many ways, Liukas said, it can be an opportunity for kids to learn lots of related skills, such as how to collaborate, how to tell a story, and how to think creatively.

“This demands a lot from the teachers, obviously,” Liukas said during a presentation at the embassy event. This is true in the sense that incorporating coding and programming lessons across disciplines requires all kinds of educators, from the science teacher to the art teacher, to understand the basics.

Source: In Finland, Teaching Computer Science Without Computers – The Atlantic

March 6, 2017 at 7:00 am Leave a comment


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

Join 9,005 other followers

Feeds

Recent Posts

Blog Stats

  • 1,878,933 hits
October 2021
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

CS Teaching Tips