Posts tagged ‘programming languages’

Holding ourselves to a higher standard: “Language-independent” just doesn’t cut it

My CACM blog post this month (see link here) is a retraction of the term “language-independent” in our work on the FCS1 and SCS1:

There is no language independence here. The FCS1 and SCS1 are multi-lingual which is a remarkable achievement. We might also call them pseudcode-based assessments, which is how they can be multi-lingual, but since a pseudocode-based test isn’t necessarily validated across other languages, “multi-lingual” is a stronger claim than “pseudocode-based.” We do not cover all of any of those languages (Java, MATLAB, or Python), but we do cover the subset most often appearing in an introductory CS course.

They are clearly not language independent. In the great design space of programming languages, Java, MATLAB, and Python cluster together pretty closely. There are much more different programming languages than these — I’m sure it’ll take any reader here just a few moments to generate a half-dozen candidates whose learners would score poorly on the FCS1 and SCS1, from Scratch to Haskell to Prolog.

I only vaguely remember the discussion about using the term “language independence” with Allison many years ago.  I remember her asking me if we should worry about the (relatively few) classes that used languages other than Python, MATLAB, and Java.  I think I told her she needed to graduate. I judged from the perspective of what was being published at the SIGCSE Symposium — Python, MATLAB, and Java was “language independent” enough for the paper to be seen as valuable to SIGCSE reviewers. I don’t remember the details, but I’ll accept the blame for the decision to call FCS1 (and SCS1 later) language independent.

That was a long time ago, before the International Computing Education Research Conference (ICER) was invented.  Since then, we have a computing education research community that aims to answer questions about how people learn computing — period. We’re not just about undergraduate introductory computer science classes. Even at the undergraduate level, we should study the classes (no matter how few) doing something different to see what’s powerful and interesting about them. We should explicitly be exploring unusual (even purpose-invented) languages to understand more of the interaction between programming languages and human cognition.  An insightful PPIG paper from Clayton Lewis (see link here) was recently circulated on Twitter (see tweet) that makes great points about the complexity of measuring that interaction:

The PPIG community should be proud that cognitive dimensions analysis emerged from the work of people in its ranks, Thomas Green, Marian Petre, Alan Blackwell, and others. We should be skeptical of calls to replace its use with A-B trials or other quantitative methods that cannot cope with the complexity of the language design landscape. When results of A-B trials and similar studies are presented, we should diplomatically ask for the mechanisms that are involved to be described. Colleagues who present the results of such trials should be prepared to respond to this request, so that the generalizability of their results can be assessed.

We should not be driven by what’s in classrooms today (see previous post making that argument). We should hold ourselves to a higher standard. Our goal is to create a lasting record of exploration and research for a research community.

That’s why it’s past time for this retraction.

 

August 26, 2019 at 7:00 am Leave a comment

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 5 comments

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

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

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

Fixing Mathematical Notation with Computing, and “Proving” It with Education

I was looking for a paper that I needed to review last night, and came upon these paragraphs in the paper I brought up by mistake.

Computers_and_Mathematical_Notation_-_Iverson_on_J

This is bold language:

It might be argued that mathematical notation (MN) is adequate as it is, and could not benefit from the infusion of ideas from programming languages. However, MN suffers an important defect: it is not executable on a computer, and cannot be used for rapid and accurate exploration of mathematical notions.

The paper I found in my archive “Computers and Mathematical Notation” doesn’t seem to be published anywhere.The author is Kenneth E. Iverson, the inventor of APL. This paper echoes some of the thoughts in Iverson’s 1980 Turing Award Lecture, “Notation as a Tool of Thought.”

The unpbulished paper is notable because he wrote it in J, his successor language to APL.  He realized that his languages would be more accessible if they used the ASCII character set. J (which you can find at http://jsoftware.com/) is essentially APL, but mapped to a normal keyboard.

The attempt to “fix” mathematical notation (“suggestions for improvement,” to be exact) is bold and interesting.  What makes his argument particularly relevant for this blog is how he made the argument. How do you “prove” that you have improved on traditional mathematics notation?

Iverson decided that education was the way to do it.  He wrote mathematics textbooks, using J.  He wanted to show that basic mathematics is more explorable using his notation.

I find this network of papers and textbooks fascinating.  I love the goal of inventing a programming notation, not to develop software, but to improve the expression and exploration of mathematics. (In that sense, J is like Mathematica.) I am intrigued by the challenge of how to show that you succeeded, and to use education as a way to demonstrate that success. I’m amazed at these multiple textbooks that Iverson wrote and released for free, to encourage exploration of mathematical ideas with J.


This week, I was informed that I will be receiving the 2019 SIGCSE Award for Outstanding Contribution to CS Education. The award will be presented at the 2019 SIGCSE Technical Symposium to be held in Minneapolis, MN  from Feb 27 – March 2, 2019. I am honored and thrilled.  SIGCSE has been my academic home since my first ACM publication at SIGCSE’94. The list of awardees is stunning, including my advisor, Elliot Soloway, Alan Kay, Hal Abelson, Jan Cuny, Alan Perlis, Judith Gal-Ezer, Sally Fincher, Grace Murray Hopper, Wirth, Knuth, and Dijkstra (among many others — the award started in 1981). It’s an impressive club I’m joining.

That announcement didn’t feel like enough for a blog post in itself, so I’m just tacking it on down here.  I’ll probably write more about it when I figure out what I’m going to say in my talk.

 

November 2, 2018 at 7:00 am 8 comments

We can build new programming languages that people will teach, learn, and use: Scratch 3.0 in August

When I come out with blog posts saying that we need new programming languages (like this one), I regularly get a bunch of skepticism.  People will only use industry-approved languages, says one argument.  We need to teach the languages that exist, says another.

Then I just reply, “Scratch.”  It’s real programming, it’s popular, and it’s taught around the world.  We ought to study how Scratch succeeded.  One key insight: Don’t beat your head against the traditional CS1 teachers.  There’s a lot more people to teach, and not everyone has to become a software developer.

A new version of Scratch is coming this August!

Source: 3 Things To Know About Scratch 3.0 – The Scratch Team Blog – Medium

June 25, 2018 at 7:00 am 20 comments

Older Posts


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

Join 7,062 other followers

Feeds

Recent Posts

Blog Stats

  • 1,690,957 hits
October 2019
M T W T F S S
« Sep    
 123456
78910111213
14151617181920
21222324252627
28293031  

CS Teaching Tips