Keeping the Machinery in Computing Education: Back to the Future in the Definition of CS

I’ve been excited to see this paper finally come out in CACM. Richard Connor, Quintin Cutts, and Judy Robertson are leaders in the Scotland CAS effort. Their new curriculum re-emphasizes the “computer” in computer science and computational thinking. I have bold-faced my favorite sentence in the quote below. I like how this emphasis reflects the original definition of computer science: “Computer science is the study of computers and all the phenomena surrounding them.”

We do not think there can be “computer science” without a computer. Some efforts at deep thinking about computing education seem to sidestep the fact that there is technology at the core of this subject, and an important technology at that. Computer science practitioners are concerned with making and using these powerful, general-purpose engines. To achieve this, computational thinking is essential, however, so is a deep understanding of machines and languages, and how these are used to create artifacts. In our opinion, efforts to make computer science entirely about “computational thinking” in the absence of “computers” are mistaken.

As academics, we were invited to help develop a new curriculum for computer science in Scottish schools covering ages 3–15. We proposed a single coherent discipline of computer science running from this early start through to tertiary education and beyond, similar to disciplines such as mathematics. Pupils take time to develop deep principles in those disciplines, and with appropriate support the majority of pupils make good progress. From our background in CS education research, we saw an opportunity for all children to learn valuable foundations in computing as well, no matter how far they progressed ultimately.

Source: Keeping the Machinery in Computing Education | November 2017 | Communications of the ACM

November 20, 2017 at 7:00 am 3 comments

Parsons Problems have same Learning Gains as Writing or Fixing code, in less time: Koli Calling 2017 Preview

On Saturday, Barbara Ericson will be presenting at Koli Calling her paper (with Lauren Margulieux and Jeff Rick), “Solving Parsons Problems Versus Fixing and Writing Code.”

The basic design of her experiment is pretty simple.  Everybody gets a pretest where they answer multiple-choiced questions, write some code, fix some code, and solve some Parsons problems.  (I’ve written about Parsons Problems here before.)

Then there are three instructional treatments with three different kinds of problem-solving practice:

  • One group gets Parsons Problems with distractors in them — blocks that should not be dragged into the solution.
  • One group gets the same code to fix — same code as in the Parsons Problems but all the distractors are there.  They have to fix the broken code in the distractor to get to the same code as the correct block in the Parsons.
  • One group gets to write the code to solve the same problem.

Then they take an isomorphic (same basic problems with context and constants changed) post-test, go away, and come back one week later for a retention test (which is isomorphic to both the pretest and the first posttest: multiple choice questions, Parsons, fix code, write code).  So we have students who study with Parsons Problems getting tested by writing and fixing code.

Here’s the bottom line from their abstract: “We found that solving two-dimensional Parsons problems with distractors took significantly less time than fixing code with errors or than writing the equivalent code. Additionally, there was no statistically significant difference in the learning performance, or in student retention of the knowledge one week later.”

That’s it. It’s simple but profound.  Below is the timing table from the paper. The Parsons Problems took effort, but always less time — sometimes they took only half the time of fixing or writing code, and other times it was only a few percentage less. But it was always less.

One takeaway idea is: If Parsons leads to the same learning in less time, why wouldn’t every teacher use more Parsons problems?  A second one that we’ve been thinking alot about is: Can we provide more Parsons problems so that in the same amount of time that students were writing code, they actually learn more? Efficiency matters, as Elizabeth Patitsas’s work suggests — more efficient learning may mean less belief in Geek Gene by CS teachers.

Cursor_and_ParsonsVsFixAndWrite-Final_pdf__page_8_of_10_

November 17, 2017 at 7:00 am 6 comments

Royal Society Report on CS in English Schools: The Challenge of Reaching Everyone

The new report from the UK’s Royal Society is fascinating and depressing. More than half of school don’t offer CS. Because the largest schools do offer CS, 70% of English students are at a school that offer CS — but they’re still not getting into CS classes. Only 1 in 5 CS students are female. The Royal Society recommends a tenfold increase in funding.

We have heard about some of these demographics before (see the Roehampton report and BBC coverage). Here in the US, we’re also talking about dramatically increasing funding (see blog post here about the $1.3B funding from White House and Tech industry).  Are the US and England on the same paths in CS? Is there any reason to expect things to be different, or better, in the US?

report by the UK’s national academy of sciences finds that more than half of English schools do not offer GCSE Computer Science, leaving too many young people without the chance to learn critically important programming and algorithm skills at a crucial stage of their education.

Unless the government urgently invests £60m in computing education over the next five years – a tenfold increase from current levels that puts it on par with support for maths and physics – an entire generation may never unlock the full potential of new technologies such as robotics, artificial intelligence and machine learning.

Key findings from the report include:

  • 54% of English schools do not offer Computer Science GCSE

  • 30% of English GCSE pupils attend a school that does not offer Computer Science GCSE – the equivalent of 175,000 pupils each year

  • Bournemouth leads England with the highest uptake of Computer Science GCSE (23% of all pupils), with Kensington & Chelsea (5%), Blackburn (5%) and City of London coming last (4%)

  • England meets only 68% of its recruitment target for entries into computing teacher training courses, lower than Physics and Classics

  • Only 1 in 5 Computer Science GCSE pupils are female

Source: Invest tenfold in computing in schools to prepare students for digital world, says Royal Society

November 13, 2017 at 7:00 am 4 comments

Why do so few schools try LiveCode? We let industry dictate our tools

I’m an old HyperCard programmer, so I like LiveCode.  LiveCode does very well on the five principles I suggest for picking an educational programming language. The language is highly readable, and was actually designed drawing on research on how novices best understand programming. It’s easy to put together something that looks authentic and that runs on virtually any platform — much easier than Python, Java, Scratch, Blockly, or any of the other top five most popular teaching languages. Authenticity is often engaging for students.

The LiveCode folks have just put together a web page (linked below) describing some of the reasons why teachers should consider LiveCode.  But in general, we don’t.  Why not?  I have two guesses:

  1. There is no community of practice. There isn’t a visible community of teachers using LiveCode. There isn’t an obvious industry call for more LiveCode programmers.
  2. We in computing education are mostly driven by surface-level interpretations of industry needs.  It isn’t obvious that it must be so, or even that it should be so.  But the same forces that killed Pascal and promoted Python, Java, and C++ as our intro languages prevent LiveCode from getting adopted.

I think LiveCode, Smalltalk, and Lisp are all excellent pedagogical programming languages, but our teaching decisions in secondary and post-secondary CS education are rarely based on what will engage students, be easier to learn, or lead to transferable knowledge.  Instead, we tend to make decisions on what obviously looks like what current professionals do.  It binds us to normative practices. We’re stuck in apprenticeship as our teaching perspective, and can’t consider social reform or developmental perspectives.

Better Exam Results, Better Real Life Outcomes, More Fun!

Over a third of Scottish schools are now teaching using LiveCode. They are doing this because they have proven results showing that using LiveCode results in more students remaining engaged, reaching good grades, and continuing in the direction of a coding career.

Source: Education | LiveCode

November 10, 2017 at 7:00 am 24 comments

How to scale our capacity to offer high-quality CS Education – CRA Education Committee

What a great idea!  The CRA Education Committee has created a website of practices to help CS departments manage “Generation CS.”  It includes projects from Google’s CS Capacity Awards.

Although different institutions, large and small, are experiencing the enrollment increases in different ways, many programs are already operating at or beyond their maximum capacity. To help departments and faculty deal with this capacity crunch, this Scaling Capacity website is intended to provide a platform for sharing technological and pedagogical interventions for addressing capacity challenges. These practices are not designed to be ‘one size fits all’, but rather offer a variety of solutions derived from specific university needs.This intervention list includes recipients of Google’s CS Capacity Awards and other self-nominated programs.

Source: Scaling Capacity – CRA Education

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

Open Research Questions in Computing Education, 2017 Edition

When I last taught the Computing Education Research question class in 2015, we generated a list of open research questions (see post here).  We’ve got even more students this time in the class, so our list of questions is even longer.  We tried to cluster them, so similar questions should be near each other

.

Open Research Questions

What areas/findings of CS education research transfer to online learning? What doesn’t work the same?

Would more students pursue CS if it was incorporated into other introductory classes (different domains)?

Would more collaboration in two CS classes help reduce the defensive climate?

Do certain spoken languages allow for more effective learning of computing? If so, which ones?

Why don’t girls/minorities enter CS classes even if offered at their K12/undergrad school?

In underrepresented communities, is CS education a priority? If not, why not?

Does learning computing earlier quicken abstract reasoning?

How can you tell if a middle-schooler is learning computational thinking? What is computational thinking, operationally?

How can we get the attrition rate to decrease in CS education? Do we offer fewer jobs in industry? Force more people to teach CS? How do retain CS teachers?

Would teaching testing strategies from CS1 increase code writing skills?

Would undergrads be better programmers if they used weakly-typed languages before using strongly-typed languages?

Would students be better programmers if they learned ML or R first? Or if they learned to diagram programs first?

Can short informal CS Ed interventions (e.g., in museums, public spaces, etc.) have any effect on CS learning and/or self-efficacy and/or attitudes towards computing?

How can teach undergraduate students how to better understand documentation? Should we explore creating language documentation specific to intro classes?

How does learning functional vs. procedural programming first effect development of computational literacy?

How can we increase diversity in online CS education?

What kind of Community of Learners gravitates towards online education?

How can we make informal computational learning accessible to a wide audience?

Is it a positive or negative thing to have different forms of education for different communities within CS?

Would a computing course focused on creative activities have better recruitment/retention of diverse students?

Does physical computing engage students in a different way than traditional programming?

How do computational scientists think about code differently than computer scientists?

Can we teach computing to an elderly community of learners?

Would more diversity in Maker and Tinkerer spaces increase the diversity in CS?

November 3, 2017 at 6:00 am 5 comments

Lamport and how Education works: The Coming Software Apocalypse

Several people sent this article to me. It’s so one-sided and contrary to empirical evidence that I found it hard to finish. The belief that we can fix all of software through the use of software proofs and verification is contrary to software social processes, as shown by DeMillo, Lipton, and Perlis in 1979. Belief that Toyota sudden acceleration was due to a software bug ignores the empirical evidence about other causes for the phenomenon (as Gladwell described in his podcast last year).

It’s the paragraph quoted below that led to people sending me the article. Leslie Lamport suggests that if we just taught people TLA+, that would lead to better software.

Education of novices never works as a mechanism to change professional practice.  (Or at least, I’ve been trying to find an example of successfully changing a community through education of the young, and I haven’t found one yet.) Students who want to become software developers want to do what software developers do — that’s Lave and Wenger’s model of situated learning, where students join a Community of Practice through Legitimate Peripheral Participation (which I describe in this blog post). If you tell students to learn TLA+, you would most likely get a response like, “Why are we learning THIS? We want to real thing, not some academic toy!”

If you want to change a community of practice, you have to get the leaders in the community of practice to change. Students follow them. It doesn’t work the other way around.

But TLA+ occupies just a small, far corner of the mainstream, if it can be said to take up any space there at all. Even to a seasoned engineer like Newcombe, the language read at first as bizarre and esoteric—a zoo of symbols. For Lamport, this is a failure of education. Though programming was born in mathematics, it has since largely been divorced from it. Most programmers aren’t very fluent in the kind of math—logic and set theory, mostly—that you need to work with TLA+. “Very few programmers—and including very few teachers of programming—understand the very basic concepts and how they’re applied in practice. And they seem to think that all they need is code,” Lamport says. “The idea that there’s some higher level than the code in which you need to be able to think precisely, and that mathematics actually allows you to think precisely about it, is just completely foreign. Because they never learned it.”

Source: The Coming Software Apocalypse – The Atlantic

October 30, 2017 at 7:00 am 19 comments

Older Posts


Recent Posts

November 2017
M T W T F S S
« Oct    
 12345
6789101112
13141516171819
20212223242526
27282930  

Feeds

Blog Stats

  • 1,453,090 hits

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

Join 5,181 other followers

CS Teaching Tips