Posts tagged ‘computing education research’

Blocks and Beyond 2019 and SnapCon19 Call for Papers

#SnapCon19, the first Snap Conference, will be held September 22-25, 2019, in Heidelberg, Germany.  Register by June 24 at this website.


Blocks and Beyond 2019: Beyond Blocks 

VL/HCC workshop in Memphis, TN, USAFri Oct 18, 2019
http://cs.wellesley.edu/blocks-and-beyond

Scope and Goals

Blocks programming has become increasingly popular in programming environments targeted at beginner programmers, end users, and casual programmers. Capitalizing on the energy and enthusiasm from the first two Blocks and Beyond workshops, we are pleased to announce the 2019 Blocks and Beyond workshop.

Since blocks are only a small step towards leveraging visual languages and notations for specifying and understanding computation, the emphasis of the 2019 workshop is on the Beyond aspect of Blocks & Beyond: what kinds of visual notations and programming environment scaffolding facilitate: Understanding program semantics? Learning computational concepts? Developing computational identity and fostering computational participation and computational action?

The goal of this workshop is to bring together language designers, educators, researchers, and members of the broader VL/HCC community to answer these questions. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, human factors, the learning sciences, and learning analytics.

This workshop will engage participants to (1) discuss the state of the art of visual languages targeted at beginners, end users, and casual programmers; (2) assess the usability and effectiveness of these languages and their associated pedagogies; and (3) brainstorm about future directions for these languages.

Suggested Topics for Discussion

  • In what ways have blocks languages succeeded or failed at fulfilling the promise of visual languages to enhance the ability of humans to express computation?
  • How can visual languages and environments better support dynamic semantics and pragmatics, particularly with features for liveness, debugging, and understanding the dynamic execution of programs?
  • How usable and effective are visual environments for teaching computational thinking and programming? For democratizing programming and enabling computational participation and computational action? How do we know?
  • In what ways does visual programming help or hinder those who use them as a stepping stone to traditional text-based languages? What are good ways to support the transition between visual languages and text-based languages? How important is this?
  • How does the two-dimensional nature of visual language workspaces affect the way people create, modify, navigate, and search through their code?
  • What tools are there for creating new visual languages, especially domain-specific ones?
  • What are effective mechanisms for multiple people to collaborate on a visual programming when they (1) are co-located or (2) are working together remotely?
  • What are effective pedagogical strategies to use with visual languages, both in traditional classroom settings and in informal and open-ended learning environments?
  • What are the most effective ways to provide help to visual programmers, especially in settings outside the classroom?
  • How can visual environments and associated curricular materials be made more accessible to everyone, especially those with visual and motor impairments and underrepresented populations in computing?
  • What lessons from the visual programming community are worth sharing with other language designers? Are there features of visual languages that should be incorporated into IDEs for traditional programming environments? What features of modern IDEs are lacking in visual languages?
  • How can online communities associated with these environments be leveraged to support users? Are these online communities inclusive and how can they be more inclusive?
  • For these environments, what data can be collected, and how can that data be analyzed to determine answers to questions like those above? How can we use such data to answer larger scale questions about early experiences with programming?

Submission

We invite three kinds of paper submissions to spark discussion at the workshop:

  • A 2 to 3 page position statement describing an idea, research question, or work in progress related to the design, teaching, or study of visual programming environments.
  • short paper (up to 4 pages, excluding references and/or acknowledgments) describing previously unpublished results involving the design, study, or pedagogy of visual programming.
  • long paper (up to 8 pages, excluding references and/or acknowledgments), with the same goals and content requirements of the short paper, but with a more substantial contribution.

To maximize discussion time at the workshop, paper presentation times will be very short.

All workshop participants (whether or not they have an accepted paper) are encouraged to present a demo and/or poster of their work during the workshop. Anyone wishing to present a demo/poster should submit a 1 to 2 paragraph abstract. There is also an option to submit a 1 to 2 page demo/poster summary document that will appear in the proceedings.

Submission details for papers and demo/poster abstracts and summary documents can be found at the workshop website:  http://cs.wellesley.edu/blocks-and-beyond

As with the first two Blocks and Beyond workshops, we are applying to publish the proceedings of this workshop with the IEEE.

Important Dates

  • Fri 12 Jul 2019: Paper submissions due (due by end of day, anytime on Earth)
  • Fri 09 Aug 2019: Author notification
  • Fri 16 Aug — Fri 20 Sep 2019: Rolling demo/poster abstract submissions
  • Fri 16 Aug — Fri 25 Oct 2019: Rolling demo/poster summary document submissions
  • Mon 09 Sep 2019: Camera ready paper submissions and copyright forms due
  • Fri 13 Sep 2019: Early registration for VL/HCC and B&B ends
  • Fri 18 Oct 2019: Workshop in Memphis
  • Fri 01 Nov 2019: Camera-ready demo/poster summary documents and copyright forms due

 

June 12, 2019 at 7:00 am Leave a comment

Come hang out with Wil and me to talk about new research ideas! ACM ICER 2019 Work in Progress Workshop

Wil Doane and I are co-hosting the ACM ICER 2019 Work in Progress workshop that Colleen Lewis introduced at ICER 2014 in Glasgow (my report on participating). Colleen and I co-hosted last year.

It really is a “hosting” job more than an “organizing” or “presenting” role.  I love Colleen’s informal description of WiP, “You’re borrowing 4 other smart people’s brains for an hour. Then you loan them yours.”  The participants do the presenting. For one hour, your group listens to your idea and helps you think through it, and then you pass the baton. The whole organizing task is “Let’s put these 4 people together, and those 4 people together, and so on. We give them 4 hours, and appropriate coffee/lunch breaks.” (Where the value “4” may be replaced with “5” or “6”.)

Another useful description of WiP is “doctoral consortia for after-graduation.”  Doctoral consortia are these great opportunities to share your research ideas and get feedback on them.  Then there’s this sense that you graduate and…not have those ideas anymore? Or don’t need to share them or get feedback on them?  I’ve expressed concern previously about the challenges of learning when you’re no longer seen as a learner. Of course, PhD graduates are supposed to have new research ideas, which go into proposals and papers. But how do you develop ideas when you’re at the early stages, when they’re not ready for proposals or papers?  That’s what the WiP is about.

The WiP page is here (and quoted in part below). To sign up, you just fill out this form, and later give us a drafty concept paper to share with your group.

The WIP Workshop (formerly named the Critical Research Review) is a dedicated 1-day workshop for ICER attendees to provide and receive friendly, constructive feedback on works-in-progress. To apply for the workshop you will specify a likely topic about which you’ll request feedback. WIP participants will be assigned to thematic groups with 4-6 participants.

Two weeks before ICER, participants will submit to the members of their group a 2-4 page primer document to help prepare for the session and identify the types of feedback sought. At WIP, depending upon group size, each participant will have 45-75 minutes to provide context, elicit advice, support, feedback, and critique. Typically, one of the other group members acts as a notetaker during an individual’s time in order to allow the presenter to engage fully in the discussion.

WIP may be the right experience for you, if you would like to provide and receive constructive advice, support, feedback, or critique on computing education research issues such as:

  • A kernel of a research idea
  • A grant proposal
  • A rejected ICER paper
  • A study design
  • A qualitative analysis approach
  • A quantitative analysis approach
  • A motivation for a research project
  • A theoretical framing
  • A challenge in a research project

The goal of the workshop is to provide a space where we can receive support and provide support. The workshop is intended for active CS education researchers. PhD students are instead encouraged to apply for the Doctoral Consortium, held on the same day as WIP.

May 31, 2019 at 7:00 am Leave a comment

Learning to code is really learning to code something: One doesn’t just “learn programming” nor “learn tracing”

I asked a group of social studies educators what programming language(s) they might want to use in their classes. One of the interesting themes in the responses was “the same as what’s in math and science classes.” One teacher said that she didn’t want a “weird hierarchy” where there’s one programming language in STEM and another in “history and English” for fear they’d be seen as “dumbed down.” Another said that maybe teaching JavaScript in history class “would make history cool.”

There’s a belief in this theme that I think is wrong. Learning to program in science class probably won’t transfer without a bunch of work to programming in mathematics class, and programming STEM classes will probably be a very different thing than programming in the humanities classes. Even expert programmers learn to program in a domain, and have a hard time transferring that knowledge of programming between domains. Expertise is expertise in a domain.

My advisor, Elliot Soloway, was involved in some of the early studies that supported this claim. The first paper was “The role of domain experience in software design” by Beth Adelson and Elliot Soloway from 1985. I quote from the abstract:

A designer’s expertise rests on the knowledge and skills which develop with experience in a domain. As a result, when a designer is designing an object in an unfamiliar domain he will not have the same knowledge and skills available to him as when he is designing an object in a familiar domain.

In this study, they took expert software designers in various fields, and have them design systems in other fields. They also asked novice designers to do some of the same tasks. For example, maybe we have a software designer who has been building banking software, and another who has been designing real-time control systems. Now, let’s ask both designers to design an elevator control system.

What they found was that the designers in the new domain struggled. They stopped planning (e.g., making notes). When they were in the familiar domain, they would often visualize the working system (“simulation” in the paper). Novices didn’t. The experts didn’t when they were faced with a new domain. Experts in an unfamiliar domain looked much like novices. Now, experts in an unfamiliar domain were better than the novices at noticing constraints on the design, so something transferred.

The second paper is even more striking. “Empirical Studies of Programming Knowledge” (1984) by Elliot Soloway and Kate Ehrlich. From the abstract:

We suggest that expert programmers have and use two types of programming knowledge: (1) programming plans, which are generic program fragments that represent stereotypic action sequences in programming, and (2) rules of programming discourse, which capture the conventions in programming and govern the composition of the plans into programs.

When we teach programming, we tend to focus on the syntax and semantics of the language. We don’t explicitly teach plans — chunks of code that do something useful. But we expect students to figure them out. We rarely teach discourse rules. The domain-specific knowledge lies in both plans and discourse rules.

To test the claim about the importance of these discourse rules, they produce sets of two programs: Alpha and Beta. Alpha is a perfectly fine program. Beta breaks the rules. For example, if you see a variable initialized n := 0;, you would find it weird to later see read(n); (to input a new value for n). It’s not wrong. The code might work just fine — in fact, it does work just fine in the experimental construction of Beta. But the program breaks the rules of discourse. They write:

Notice that both Alpha version and the Beta version are runnable programs that in almost all cases compute the same values. Moreover, to an untrained eye their differences may even not be apparent; they always only differ by a very few textual elements.

Here’s an example of one Alpha and Beta — these both work. In this case, they do not do the same thing:

Beta isn’t wrong. It successfully computes minimum. However, it uses the variable max which is confusing. It breaks our discourse rule. The program does work.

Different domains use different standards and different styles of programming. Engineers using MATLAB rarely use FOR or WHILE loops, for example. Graphic designers writing JavaScript code use far more exception handling than we ever expected.

Soloway and Ehrlich showed these programs to “experts” (undergraduate juniors to graduate students) and novices (students in their first programming course). When asked questions about Alpha (e.g., “What goes in this missing line in the code?” Or “Do you remember that code that I showed you?”), experts do far better than novices. When asked questions about Beta, experts do essentially the same as novices (no statistically significant differences).

I find it particularly notable that the expert drop is steeper.  Experts rely heavily on cues like variable names, even more than novices. CS expertise is really expertise in the discourse rules.

If expert programmers “knew programming,” they should be able to just trace the code (“be a computer”) and answer the questions correctly. Instead, they struggle to understand what’s going on. They’re pretty much like a student in their first semester of programming. The experts know Alpha well because it’s just like all the other programs they’ve ever seen — they can pattern match, rather than reason about the code itself. The experts struggle with Beta. It’s kind of like the difference between humans and Econs. Econs can reason through code rationally. Humans rely on expectations.

These results also suggest that the question of “Does tracing come before writing?” is moot.  Tracing what?  The program matters.  Some programs are harder to trace than others — for everyone, and particularly, with expertise.  There is no generic “tracing skill.”

Conclusion: People don’t just learn “coding.” Programmers in general know plans and discourse rules. Break the rules and you just have the programming language — and even experts aren’t really good at just applying the syntax and semantics rules. No better than a novice. If you have enough expertise in different domains, then you can work in different domains. When you start programming in a new domain, you’re not that much different than a new programmer.

The social studies teachers I’m working with have a sense that students can just
know JavaScript.” I don’t think that’s true. I think if I taught students to write JavaScript code to use Google’s Charts service for making data visualizations, it wouldn’t be much easier to teach them Web programming with React, to write scripts for Adobe Photoshop, nor to build simulations in Lively Web. It’s all JavaScript, and the syntax and semantics are the same in each — but in terms of what people really know and use (i.e., plans and discourse rules), it’s completely different.

May 20, 2019 at 7:00 am 7 comments

Comparing performance in learning computer science between countries

Imagine that you are a high school chemistry teacher, and you’re convinced that you have developed a terrific way to teach the basic introductory to chemistry course. Your students do terrific on all your assessments and go on to success in chemistry in college. You decide that you want to test yourself — are your students really as good as you think they are?

You reach out to some friends in other schools and ask them to give your final exam to their students. You are careful about picking the other schools so that they’re really comparable along dimensions like student wealth, size of school, and student demographics. Your friends are willing, but they just have a few of their students take the test. You don’t know really how they pick. Maybe it’s the best students. Maybe it’s the students who need remedial help. Maybe it’s a punishment for students in detention. Of course, all of your students take the final exam.

In the end, you have lots of YOUR students who took YOUR exam, and you have a handful of other students. Your friends (who likely don’t teach like you) give you a few tests from their students. Is it at all surprising that your students will likely out-score the friends’ students?

That’s how I read this paper from Proceedings of the National Academy of Sciences of the US: “Computer science skills across China, India, Russia, and the United States.” The authors are quite careful about picking schools to compare, along dimensions of how “elite” the schools are. I’m quite willing to believe that there is a range of schools with different results along an “elite” spectrum.

They over-sample from the United States, compared to the population of these countries:

Altogether, 678 seniors from China (119 from elite programs), 364 seniors from India (71 from elite programs), and 551 seniors from Russia (116 from elite programs) took the examination…We also obtained assessment data on 6,847 seniors from a representative sample of CS programs in the United States (607 from elite programs).

The test they use is the “Major Field Test” from ETS. I don’t know that it’s a bad test. I do suspect that it’s US-centric. It’s like the final exam from our Chemistry teacher in my example. Compare that to the TIMSS assessments that go to great lengths to make sure that the data are contextualized and that the assessments are fair for everyone.

Maybe the results are true. Maybe US computer science students are far better than comparable CS students in Russia, China, and India. I’m just not convinced by this study.

May 6, 2019 at 7:00 am 1 comment

What’s NOT Computational Thinking? Curly braces, x = x + 1, and else.

In the previous blog post, I suggested that Computational Thinking is the friction necessary to make your problem solvable by a computer. It should be minimized unless it’s generative.  It’s a very different framing for computational thinking.  Rather than “what’s everything that we use in computing that might be useful for kids,” it’s closer to, “the day is full and students are already in so many subjects — what do they have to know about computing in order to use it to further their learning and their lives?”

What is NOT Computational Thinking

I have been talking to my students about what’s on the list of things that we typically teach but don’t fit into this model of computational thinking. Here’s what I’ve thought of so-far:

Here are criteria for what should NOT be part of teaching computational thinking:

  • These are hard for students — why go to that extra effort unless it’s worthwhile?
  • We have invented ways of framing problems for a computer that do not use these things, so they’re not necessary.
  • They are not generative. Knowing any of these things does not give you new leverage on thinking about problems within a domain.

If Computational Thinking is something we should teach to everyone, these are items that are not worth teaching to everyone.

Computational thinking includes programming, for me. It is generative.  It allows students to explore causal models that are tested with automation.  It’s the most powerful idea in computational thinking.

What is Computational Thinking for OTHER subjects

Then there are the ideas that are on most lists of computational thinking, like decomposition and abstraction. I absolutely believe that all programmers have those skills. They are absolutely generative. I believe that programming is a terrific place to try out and play with those ideas.

In the Rich et al. paper about learning trajectories that I reference so often, they talk about students learning “Different sets of instructions can produce the same outcome.” That’s a critical idea if you want students to learn that different decompositions can still result in the same outcome.

But does abstraction and decomposition belong in a Computational Thinking class?  They feel more like mathematics, science, and engineering to me.  Yes, use computing there, but don’t break them out into a separate class.  A mathematics teacher may be better prepared to teach decomposition and abstraction than are computer science teachers. It’s better to teach these ideas in a context with a teacher who has the PCK to teach them.

What’s more, it’s clear that you don’t need abstraction and decomposition to program computers as a way to learn.  Task-specific programming languages are usable for learning something else without developing new abilities to abstract or decompose. Our social studies teachers did in our participatory design study in March — they learned things about life expectancy in different parts of the world, using programming that they did themselves, in 10-20 minutes.

What is Computer Science that EVERYONE should know

There’s another list we could make that is ideas in computer science that everyone should know because it helps them to understand the computation in their lives.  Yes, there’s a lot in the school day — but this is worth it for the same reason that Physics or Biology is worth it. This is a different matter than what helps them solve problems (which is the guts of the computational thinking definitions we have seen earlier).  On my list, I’d include:

  • Bits, the atom of information processing.
  • Processes, what programs allow us to define.
  • Programming, as a way to define processes.

Other suggestions?

  • What’s on your list for what’s NOT necessary in Computational Thinking, and
  • What is in Computer Science that everyone needs but is not Computational Thinking?

May 3, 2019 at 7:00 am 36 comments

A new definition of Computational Thinking: It’s the Friction that we want to Minimize unless it’s Generative,

David Benedetto wrote a blog post about computational thinking for CSTA that gave me new insight into Computational Thinking (thanks to Shuchi Grover whose tweets drew me to it):

http://advocate.csteachers.org/2019/02/27/situated-computational-thinking/

David says:

I think this definition of CT is as good a starting point as any:

Computational Thinking is the thought processes involved in formulating problems and their solutions so that the solutions are represented in a form that can be effectively carried out by an information-processing agent (Cuny, Snyder, Wing, 2010).

He evolves this position until, like Shuchi, he comes up with two definitions of CT:

What are the implications of this? I think there are two clear options for how we define CT:

(A) Restrict what we mean by CT. This is perfectly reasonable and probably necessary for most practical purposes. However, this has the inevitable consequence of fragmenting our understanding of CT. There will be different CTs in different disciplines / fields. We will do this, but we should try to understand the restrictions that we are imposing, and the consequences of imposing them.

(B) Break our concept of CT wide open. I think the scientific community (at least, those who are studying the construct of CT and how it plays out in real cultural contexts) should do this, so that we can explore how CT is understood and practiced in a variety of contexts and for a wide range of purposes.

As a researcher, I’m more in favor of the former — let’s define Computational Thinking precisely.  David’s concern is really about the social context around CT. People want to call lots of things Computational Thinking. Can we come up with a definition for CT that bridges these? That represents the discipline-specific uses of CT, and is well enough defined that we can actually measure something about it?

There are many other “thinkings” that lay claim to providing students with critical skills. Admiral Grace Hopper would likely support “mathematical thinking” more than “computational thinking,” as this interesting essay from Yale points out. Skills like “decomposition” or “abstraction” are included in many definitions of computational thinking (eg this blog post), and it’s true that you need those in computing.  But those skills first belonged to mathematics, engineering, and science, and I’d argue that the teachers in those subjects might be in a better position to teach them and to measure them. Computation can play an important role in learning decomposition and abstraction, but those skills don’t belong uniquely to computation, or to a class on computational thinking. So, what is unique about computation?

The tension between HCI and Computational Thinking

On the computer science side of my life, my research community is human-computer interaction.  I’ve published in CHI, DIS, CSCW, VL/HCC, and UIST. The Cuny, Snyder, and Wing definition is hard for me to reconcile with being an HCI researcher.  The point of HCI research is to minimize the amount that a user has to learn in order to “formulate problems and their solutions so that the solutions are represented in a form that can be effectively carried out by an information-processing agent.”  HCI is trying to make it easier for the user to think with a computer whatever they want to think about. Computational Thinking is about what you need to think with a computer.

Over the last few weeks in this blog, I’ve been exploring the notion of task-specific programming languages. I was amazed at how much social studies teachers could do with Vega-Lite in a participatory design session we ran in early March. Sarah Chasin’s work with Helena and Rousillon is absolutely stunning for how much people could achieve with no training. Hariharan Subramonyam sent me this fascinating essay on end-user programming and about how to minimize the effort it takes end users to start programming: https://www.inkandswitch.com/end-user-programming.html. As I talked about in my SIGCSE 2019 keynote, Bootstrap:Algebra and most uses of Scratch actually rely on a small number of computational ideas. There is expressive and learning power in even a small amount of computation.

Michael Mateas wrote an essay back in 2009 that has been influential in my thinking. I blogged about it here: “There will always be friction.” Michael looked at the Alan Perlis talk of 1961 (that I talk and write about often), and particularly, at the exchange with Peter Elias. Elias argued that students shouldn’t have to learn to program — the computer should learn to understand us. Both Perlis and Mateas disagree. The computer can never understand us completely. We have to smooth the communication because the computer cannot. There will always be a challenge to human-computer interaction. There will always be friction, and it’s the human’s job to manage that friction..

A New Definition for Computational Thinking

So, here’s my new take on Computational Thinking: It’s the friction. Let’s take the original Cuny, Snyder, and Wing definition — computational thinking is about framing problems so that computers can solve them. The work around task-specific programming languages is showing us that we can make that amount that the user has to learn in order to use programming for their problem very small.

To meet Alan Kay’s point about generativity, there are some things in computing that we want to teach because they give us new leverage on thinking. We want to teach things that are useful, but not those that are necessary just because we have bad user interfaces.

A minimal definition of Computational Thinking: The stuff that we have to learn in order to communicate our tasks with a computer. It should be small, and the part that we learn should be generative, useful for new problems and new thinking. Everything else should be eliminated by good user interfaces.

You don’t have to master abstraction and decomposition just to use a programming language to help you learn. Our social studies teachers modified Vega-Lite programs, made mistakes (every single one of them) and recovered from them, and tried new things that they figured out on their own — all in 10-20 minutes. They already have problem solving skills. They didn’t need any “computational problem solving skills.” They certainly didn’t learn any special computational abilities to abstract and decompose in 10 minutes. They already know enough to use programming to learn. If we can eliminate the need for a particular skill in order to use computing to learn something else, we should.

This meshes with David Weintrop and Uri Wilesnky’s definition — it’s the computational practices of actual scientists and engineers who use computing. Their definition is particularly strong because it’s empirically grounded. They asked computational scientists and engineers what they actually do. Weintrop and Wilesnky’s participants want to do their work, not programming for its own sake. So they use a minimal subset of computing that buys them something for their thinking and in their tasks.

I like this definition because it’s aspirational.  Today, there’s a lot of stuff that you have to learn to use a computer to solve problems. Philip Guo gave a talk here at Michigan recently (similar to one he gave at U-W) and described how data scientists have to become system administrators to manage all the various packages and databases to do their job.  That’s a problem. That’s not computational thinking. That’s stuff to get rid of. How small can we make computational thinking?

 

April 29, 2019 at 7:00 am 11 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 2 comments

Older Posts


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

Join 6,246 other followers

Feeds

Recent Posts

Blog Stats

  • 1,654,690 hits
June 2019
M T W T F S S
« May    
 12
3456789
10111213141516
17181920212223
24252627282930

CS Teaching Tips