A nice definition of computational thinking, including risks and cyber-security

GasStationWithoutPumps did a blog piece on the newspaper articles that I mentioned earlier this week, and he pointed out something important that I missed.  The Guardian’s John Naughton provided a really nice definition of computational thinking:

… computer science involves a new way of thinking about problem-solving: it’s called computational thinking, and it’s about understanding the difference between human and artificial intelligence, as well as about thinking recursively, being alert to the need for prevention, detection and protection against risks, using abstraction and decomposition when tackling large tasks, and deploying heuristic reasoning, iteration and search to discover solutions to complex problems.

I like this one.  It’s more succinct than others that I’ve seen, and still does a good job of hitting the key points.

Naughton’s definition includes issues of cyber-security and risk.  I don’t see that often in “Computational Thinking” definitions.  I was reminded of a list that Greg Wilson generated recently in his Software Carpentry blog about what researchers need to know about programming the Web.

Here’s what (I think) I’ve figured out so far:

1. People want to solve real problems with real tools.
2. Styling HTML5 pages with CSS and making them interactive with Javascript aren’t core needs for researchers.
3. All we can teach people about server-side programming in a few hours is how to create security holes, even if we use modern frameworks.
4. People must be able to debug what they build. If they can’t, they won’t be able to apply their knowledge to similar problems on their own.

Greg’s list surprised me, because it was the first time that I’d thought risk and cyber-security as critical to end-user programmers.  Yes, cyber-security plays a prominent role in the CS:Principles framework (as part of Big Idea VI, on the Internet), but I’d thought of that (cynically, I admit) as being a nod to the software development firms who want everyone to be concerned about safe programming practices.  Is it really key to understanding the role of computing in our everyday lives?  Maybe — the risks and needs for security may be the necessary consequent of teaching end-users about the power and beauty of computing.

Greg’s last point is one that I’ve been thinking a lot about lately.  I’ve agreed to serve on the review committee for Juha Sorva’s thesis, which focuses on his excellent program visualization tool, UUhistle.  I’m enjoying Juha’s document very much, and I’m not even up to the technology part yet.  He has terrific coverage of the existing literature in computing education research, cognitive science, and learning sciences, and the connections he draws between disparate areas is fascinating.  One of the arguments that he’s making is that the ability to understand computing in a transferable way requires the development of a mental model — an executable understanding of how the pieces of a program fit together in order to achieve some function.  For example, you can’t debug without a mental model of how the program works (to connect to Greg’s list).  Juha’s dissertation is making the argument (implicitly, so far in my reading) that you can’t develop a mental model of computing without learning to program.  You have to have a notation, some representation of the context-free executable pieces of the program, in order to recognize that these are decontextualized pieces that work in the same way in any program.  A WHILE loop has the same structure and behavior, regardless of the context, regardless of the function that any particular WHILE loop plays in any particular program. Without the notation, you don’t have names or representations for the pieces that is necessary for transfer.

Juha is making an argument like Alan Perlis’s argument in 1961: Perlis wasn’t arguing that everyone needed to understand programming for its own sake.  Rather, he felt that the systems thinking was the critical need, and that the best way to get to systems thinking was through programming.  The cognitive science literature that Juha is drawing on is saying something stronger: That we can’t get to systems thinking (or computational thinking) without programming.  I’ll say more about Juha’s thesis as I finish reviewing it.

It’s interesting that there are some similar threads about risk and cyber-security appearing in different definitions of computational thinking (Naughton and Wilson discussed here), and those thinking about how to teach computational thinking (Sorva and Perlis here) are suggesting that we need programming to get there.