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.

 

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.

 

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.

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?

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.

 

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.

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.

• Arithmetic: http://www.jsoftware.com/books/pdf/arithmetic.pdf
• Calculus: http://www.jsoftware.com/books/pdf/calculus.pdf
• Discrete Mathematics: http://www.jsoftware.com/books/pdf/cmc.pdf (as a companion to “Concrete Mathematics”)

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.

 

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

Is there a “hype cycle” for educational programming languages?

As a longtime Smalltalk-er, I loved this piece: “The 50-year Gartner Hype Cycle for Smalltalk”

Interesting how the hype cycle applies to Smalltalk:

• Technology Trigger — the hype began with the famous 1981 BYTE cover and continued throughout the 1980s.
• Peak of Inflated Expectations — in the 1990s, Smalltalk became the biggest OOP language after C++ and even IBM chose it as the centrepiece of their VisualAge enterprise initiative to replace COBOL.
• Trough of Disillusionment — Java derailed Smalltalk by being: 1) free; and 2) Internet-ready. Free Squeak (1996) and Seaside web framework (2002) were not enough to save it.
• Slope of Enlightenment — Pharo was released in 2008 and became the future of Smalltalk, thanks to its remarkable pace of evolution. We are still in this phase, which requires continuing and sustained advocacy.
• Plateau of Productivity — we are waiting for this phase, perhaps in the next decade. I am sanguine.

Educational programming languages (or maybe just programming languages’ use in education) don’t seem to follow this curve at all.  Does a programming language ever “come back” once it has left classrooms?  Logo? Pascal?  Even if there’s a “Trough of Disillusionment” (e.g., when we realized just how hard C++ and Java are), we still see longterm use. Even if we later realize how good something was (e.g., Logo for integration into curriculum), it doesn’t come back.

I wonder what the similar curve looks like for programming languages in education.

New programming languages are important to develop as we improve our knowledge of how students learn computing

I was at a workshop at Google a couple weeks ago where someone asked me, “Do you still think that there’s a place for developing new programming languages in computing education?” I said, “ABSOLUTELY!”.

We know little about how people learn programming, and developing new programming languages is important for improving usability, learnability, and productivity of programmers (professional, novice, end-user, casual, or conversational). The interplay between design of programming languages and research into how people learn programming languages is a hot and important research topic. (See, for example, the recent Dagstuhl seminar on empirical data for programming language design.)

My Blog@CACM post for this month (see link here) is based on the cover story for the March Communications of the ACM (CACM), on “A Programmable Programming Language.” The (interesting and recommended) article is on building problem-specific programming languages. My post was about the educational questions raised by these languages. Would they be easier or harder to learn if they’re problem-specific? Will novices be willing to put in the effort to learn a programming language that is specific to a problem? Do problem-specific languages make it harder or easier to find (or train) programmers to work on old software (built in these problem-specific languages)? If a programmer learns a problem-specific programming language created at Company X, then leaves for Company Y and creates a similar problem-specific programming language, was intellectual property stolen?

Barbara Ericson’s defense was March 12 (as mentioned here). It was very successful — not only did she pass, but all of her committee signed off on the same day. She’s Dr. Ericson!

Alan Kay was on her committee and asked some insightful questions about her work with Parsons problems. In a Parson problem, students are ordering lines of code into a correct solution. Barb did her research using Python, and she’s also done work with Parsons problems in Java. These are pretty similar languages in terms of notional machines.

What’s the influence of the programming language on student success with Parsons problems? What if the underlying notional machine was simpler to understand? Would students find it easier to sequence a program? In general, we explore non-imperative programming paradigms so rarely in computing education research. We change modality (e.g., Scratch), but not the underlying computational model. The work with Racket is a rare example. Alan mentioned HyperCard in his comments, which was explicitly designed to be easy to learn. Would HyperCard programs be easier for students to order correctly?

I hope that we continue to invent new programming languages and explore the educational implications of them. There’s a big space of possible designs, and we have only started evaluating them empirically.

Jean Sammet passes away at age 89

Jean Sammet passed away on May 21, 2017 at the age of 88. (Thanks to John Impagliazzo for passing on word on the SIGCSE-members list.)  Valerie Barr, who has been mentioned several times in this blog, was just named the first Jean E. Sammet chair of computer science at Mount Holyoke.  I never met Jean, but knew her from her work on the history of programming languages which are among the most fun CS books I own.

Sammet

GILLIAN: I remember my high school math teacher saying that an actuary was a stable, high-paying job. Did you view it that way?

JEAN: No. I was looking in The New York Times for jobs for women—when I tell younger people that the want ads were once separated by gender, they’re shocked—and actuary was one of the few listed that wasn’t housekeeping or nursing, so I went.Sammet found her way to Sperry. “Everything from there, for quite a while, was self-learned,” she says. “There were no books, courses, or conferences that I was aware of.” For her next move she applied to be an engineer at Sylvania Electric Products—though the job was again listed for men.

Source: Gillian Jacobs Interviews Computer Programmer Jean E. Sammet | Glamour

Stanford CS department updates introductory courses: Java is Gone

See update here: Stanford is NOT switching from Java to JavaScript: I was mistaken

Stanford has decided to move away from Java in their intro courses. Surprisingly, they have decided to move to JavaScript.  Philip Guo showed that most top CS departments are moving to Python.  The Stanford Daily article linked below doesn’t address any other languages considered.

The SIGCSE-Members list recently polled all of their members to talk about what they’re currently teaching.  The final spreadsheet of results is here.  Python appears 60 times, C++ 54 times, Java 84 times, and JavaScript 28 times.  I was surprised to see how common C++ is, and if Java is dying (or “showing its age,” as Eric Roberts is quoted below), it’s going out as the reigning champ.

When Java came out in 1995, the computer science faculty was excited to transition to the new language. Roberts wrote the textbooks, worked with other faculty members to restructure the course and assignments and introduced Java at Stanford in 2002. “Java had stabilized,” Roberts said. “It was clear that many universities were going in that direction. It’s 2017 now, and Java is showing its age.” According to Roberts, Java was intended early on as “the language of the Internet”. But now, more than a decade after the transition to Java, Javascript has taken its place as a web language.

Source: CS department updates introductory courses | Stanford Daily

ADDENDUM: As you see from Nick Parlante’s comment below, the JavaScript version is only an experiment.  From people I’ve talked to at Stanford, and from how I read the article quoted above (“more than a decade after the transition to Java, Javascript has taken its place”), I believe that Stanford is ending Java in CS106.  I’m leaving the title as-is for now. I’ve offered to Marty Stepp that if CS106 is still predominantly Java in one year, I will post a new blog post admitting that I was wrong.  Someone remind me in April 2018, please.

Scientists Looking at Programmers’ Brains see more Language than Mathematics: The Neuroscience of Programming

I’m not convinced that our ability to image brains is actually telling us much about cognition yet.  I did find this result surprising, that our understanding of programming languages seems more linguistic than mathematical

Scientists are finding that there may be a deeper connection between programming languages and other languages then previously thought. Brain-imaging techniques, such as fMRI allow scientists to compare and contrast different cognitive tasks by analyzing differences in brain locations that are activated by the tasks. For people that are fluent in a second language, studies have shown distinct developmental differences in language processing regions of the brain. A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking.

Source: Scientists Begin Looking at Programmers’ Brains: The Neuroscience of Programming | Huffington Post

Which is better for novices, C++ lambdas or iterators? New research from Andreas Stefik’s group

I needed to look up a paper on Andreas Stefik’s page the other day and came across this fascinating new paper from him:

Phillip Merlin Uesbeck, Andreas Stefik, Stefan Hanenberg, Jan Pedersen, and Patrick Daleiden. 2016. An empirical study on the impact of C++ lambdas and programmer experience. In Proceedings of the 38th International Conference on Software Engineering (ICSE ’16). ACM, New York, NY, USA, 760-771.

(You can download it for free from his publications page: http://web.cs.unlv.edu/stefika/research.html.)

Since this is Stefik, he carefully describes what his paper is saying and what it’s not saying.  For example, he and his students measured C++ lambdas vs iterators — not a particularly pleasant syntax to work with.

The results are quite interesting.  This graph is what caught my eye.  For professionals, iteration and lambdas work just about the same.  For novices, iterators blows lambdas away.  Lambda-using students took more time to complete tasks and received more compiler errors (though that might be a good thing, in terms of using the compiler to find and correct bugs).  Most interesting was how the differences disappeared with experience. Quoting from the abstract:

Finally, experienced users were more likely to complete tasks, with or without lambdas, and could do so more quickly, with experience as a factor explaining 45.7% of the variance in our sample in regard to completion time.

This is an example of my “Test, don’t trust” principle (see earlier blog post).  I was looking up Stefik’s paper because I received an email from someone who simply claimed, “And I’m using functional notation because it’s much easier for novices than procedural or object-oriented.”  That may be true, but it ought to be tested.

How to choose programming languages for learners: Reviewing JavaScript and Ready

My Blog@CACM post for June is Five Principles for Programming Languages for Learners. The five principles I identify are:

1. Connect to what learners know
2. Keep cognitive load low
3. Be honest
4. Be generative and productive
5. Test, don’t trust

I wrote the essay in response to Idit Harel’s influential essay American schools are teaching our kids how to code all wrong. There were many responses to Idit’s essay, on social media and in other blogs. Much of the discussion focused on text programming languages vs. drag-and-drop, blocks-based languages, which I don’t think is the most critical distinction.

In this post, I respond to two of the suggestions that came up in some of these discussions. I use the five principles to review the suggestions in a kind of heuristic evaluation.

JavaScript

If we were going to teach a professional language to students, JavaScript is attractive. It’s free and ubiquitous, available in every Web browser. There are many jobs for JavaScript programmers. Because so much is built on top of it, it’s likely to remain around for many years in a compatible form. I argue in the Blog@CACM post that there are many dimensions to “real” when it comes to programming languages. “Use by professionals” is not the most important one when we talk about learners.

I recommend considering each of these five principles before choosing a programming language like JavaScript for learners.

1. Connect to what learners know – You could teach JavaScript as a connection to what children already know. The notation of JavaScript doesn’t look like anything that children are likely to have seen before, in contrast to Logo’s emphasis on words and sentences, Squeak eToys’ “Drive the Car,” Boxer’s simple UI boxes (what diSessa calls naive realism), and Racket/Bootstrap’s connections between algebra and S-expressions.  However, JavaScript is the language of the Web today, so one could probably relate the programming activities to Web pages. Most learners are familiar with parts of a Web page, animations in a Web page, and other Web features that JavaScript can control. That might serve as a connection point for children.
2. Keep cognitive load low – JavaScript has a high cognitive load. I’m a JavaScript learner and am just meeting some of its weirder features. I was shocked when I first read that = is assignment, == is type-insensitive equality, and === is type sensitive equality/equivalence. So, "5"==5 is true, but "5"===5 is false. Counting the number of = and remembering what 1 vs 2 vs. 3 means is an excellent example of extraneous cognitive load. My bet is that JavaScript overwhelms children and is probably inefficient for adult learners. This means that learners are spending so much time making sense of the syntax, it takes them longer and more effort to get to the concepts (and they may lose interest before they get to the good stuff).
3. Be honest – JavaScript is authentic, it’s real for most senses of the term.
4. Be generative and productive – I don’t know if JavaScript would be generative and productive for students. I don’t know anyone teaching JavaScript as a way to teach significant ideas in CS or other STEM disciplines. My worry is that the cognitive load would be so overwhelming that you couldn’t get to the interdisciplinary or complex ideas. Students would spend too much effort counting = and fighting for loops.
5. Test, don’t trust – The only study that I know comparing JavaScript to a blocks-based language had JavaScript losing. JavaScript conditionals and loop structures were far harder for students than the equivalent block-based structures.

We should experiment more with JavaScript, but I suspect that students would do better (struggle less with syntax, learn more, connect to other disciplines more) with a different syntax. If I were trying to get the advantages of JavaScript without the syntax cost, I’d try something like ClojureScript — freely available, as fast as JavaScript, as ubiquitous as JavaScript, used professionally, can be used to control Web pages like JavaScript (so connectable for learners), and with the syntactic similarities to mathematics that Racket enjoys.

Ready

Baker Franke of Code.org is promoting the essay Coding snobs are not helping our children prepare for the future as a response to Idit’s essay. The essay is about the application-building tool, Ready. Media theorist Dough Rushkoff has also been promoting Ready, What happens when anyone can code? We’re about to find out.

I disagree with Rushkoff’s description of Ready, even in the title. As the first essay by David Bennahum (a “Ready Maker and Venture Partner) points out, it’s explicitly not about using a programming language.

Our efforts at Ready, a platform that enables kids to make games, apps, whatever they want, without knowing a computer language, are designed to offer a new approach to broadening access to code literacy.

Bennahum’s essay means to be provocative — and even insulting, especially to all the teachers, developers, and researchers who have been creating successful contextualized computing education:

In this new world, learning coding is about moving away from computer languages, syntax, and academic exercises towards real world connections: game design and building projects that tie into other subjects like science and social studies… This is the inverse of how computer science has been taught, as an impersonal, disconnected, abstracted, mathematical exercise.

I can see how Rushkoff could be confused. These two quotes from the Ready team seem contradictory. It’s not clear how Ready can be both about “learning coding” and “code literacy” while also allowing kids to make “without knowing a computer language.” There is no programming language in Ready.  What is coding then? Is it just making stuff?  I agree with Rushkoff’s concerns about Ready.

True, if people don’t have to code, they may never find out how this stuff really works. They will be limited to the programming possibilities offered by the makers of the platforms, through which they assemble ready-made components into applications and other digital experiences.

Let’s consider Ready against the five principles I propose.

1. Connect to what learners know – the components of Ready are the icons and sliders and text areas of any app or game. That part is probably recognizable to children.
2. Keep cognitive load low – Ready is all about dragging and dropping pieces to put them together. My guess is that the cognitive load is low.
3. Be honest – Ready is not “real” in most sense of authenticity. Yes, students build things that look like apps or games, but that’s not what motivates all students. More of Betsy DiSalvo’s “Glitch” students preferred Python over Alice (see blog post). Alice looked better (which appealed to students interested in media), but students knew that Python was closer to how professional programmers worked. Authenticity in terms of practice matters to students. No professional programmer solely drags and drops components. Programmers use programming languages.
4. Be generative and productive – Ready completely fails this goal. There is no language, no notation. There is no tool to think with. It’s an app/game builder without any affordances for thinking about mathematics, science, economics, ecology, or any other STEM discipline. There’s a physics engine, but it’s a black box (see Hmelo and Guzdial on black box vs glass box scaffolding) — you can’t see inside it, you can’t learn from it. They build “models” with Ready (see this neurobiology example), but I have a hard time seeing the science and mathematics in what they’re building.
5. Test, don’t trust – Ready offers us promises and quotes from experts, but no data, no results from use with students.

Ready is likely successful at helping students to make apps and games. It’s likely a bad choice for learners. I don’t see affordances in Ready for computational literacy.

Summarizing the Research on Designing Programming Languages to be Easier to Learn: NSF CS Ed Community Meeting

I’m at the NSF STEM+Computing and Broadening Participation in Computing Community Meeting.  At our ECEP meeting on Saturday, we heard from White House Champion of Change Jane Margolis.  She did a great job of getting our states to think about how to change their state plans to emphasize diversity and equity — more on that in a future blog post.

I moderated a panel yesterday on how to integrate computing education into schools of education.  Here’s the description of the session — again, more later on this.

Integrating Computing Education into Preservice Teacher Development Programs  

(Mark Guzdial (moderator), Leigh Ann DeLyser, Joanna Goode, Yasmin Kafai, Aman Yadav)

For computing education to become ubiquitous and sustainable in US K-12 schools, we need schools of Education to teach computing.

• ​What should we be teaching to preservice teachers?
• Where should we teach CS methods in preservice teacherdevelopment?
• How do we help schools of Ed to hire and sustain faculty who focus on computing education?

Panelists will talk about how CS Ed is being integrated into their preservice teacher development programs, and about alternative models for addressing these questions.

Yesterday, our other computing education research Champion of Change, Andreas Stefik presented a summary of the empirical evidence on how to design programming languages to make them easier to learn.  Follow the link below to get to the two-page PDF pamphlet he produced for his presentation — it’s dense with information and fascinating.

This pamphlet is designed to provide an overview of recent evidence on human factors evidence in programming language design. In some cases, our intent is to dispel myths. In others, it is to provide the result of research lines.

from Programming Languages and Learning by Andreas Stefik