How CS differs from other STEM Disciplines: Varying effects of subgoal labeled expository text in programming, chemistry, and statistics

My colleagues Lauren Margulieux and Richard Catrambone (with Laura M. Schaeffer) have a new journal article out that I find fascinating. Lauren, you might recall, was a student of Richard’s who applied subgoal labeling to programming (see the post about her original ICER paper) and worked with Briana Morrison on several experiments that applied subgoal labeling to textual programming and Parson’s problems (see posts on Lauren’s defense and Briana’s).

In this new paper (see link here), they contrast subgoal labels across three different domains: Chemistry, statistics, and computer science (explicitly, programming).  I’ve been writing lately about how learning programming differs from learning other STEM disciplines (see this post here, for example). So, I was intrigued to see this paper.

The paper contrasts subgoal labeled expository text (e.g., saying explicitly as a heading Compute Average Frequency) and subgoal labeled worked examples (e.g., saying Compute Average Frequency then showing the equation and the values and the computed result).  I’ll jump to the punchline with the table that summarizes the result:

Programming has high complexity.  Students learned best when they had both subgoal labeled text and subgoal labeled worked examples. Either one alone didn’t cut it. In Statistics, subgoal labeled examples are pretty important, but the subgoal labeled text doesn’t help much.  In Chemistry, both the text and the worked examples improve performance, and there’s a benefit to having both.  That’s an argument that Chemistry is more complex than Statistics, but less complex than Programming.

The result is fascinating, for two reasons.  First, it gives us a way to empirically order the complexity of learning in these disciplines. Second, it gives us more reason for using subgoal labels in programming instruction — students just won’t learn as well without it.

 

No, Really – Programming is Hard and CS Flipped Classrooms are Complicated: ITICSE 2016 Award-Winning Papers

I only recently started digging into the papers from the ITICSE 2016 conference (see Table of Contents link at ACM Digital Library here).  There were two papers that caught my attention.

First, the best paper award went to one of my former PhD students, Brian Dorn: An Empirical Analysis of Video Viewing Behaviors in Flipped CS1 Courses, by  Suzanne L. Dazo, Nicholas R. Stepanek, Robert Fulkerson, and Brian Dorn.  Brian has this cool piece of technology where students can view videos, annotate them, be challenged to answer questions from specific places, and have discussions.  They used this for teaching a flipped CS1 class, where students were required to watch videos before class and then engage in more active learning opportunities in class.  The real trick, as you might imagine and that the paper goes into detail on, is getting students to watch the video.  I liked both the techniques for prodding students to watch videos and the fascinating results showing the relationship between watching the videos and learning.

ITICSE 2016 recognized two “commended” papers this year.  I haven’t found the listing of which papers they were, but I did learn that one of them is Learning to Program is Easy by Andrew Luxton-Reilly.  I enjoyed reading the paper and recommend it — even though I disagree with his conclusions, captured in the paper title.  He does a good job of exploring the evidence that programming is hard (and even uses this blog as a foil, since I’ve claimed several times that programming is hard), and overall, is a terrific synthesis of a bunch of computing education papers (40 references is a lot for a six page ITICSE paper).

His argument that programming is easy has two parts:

• First, children do it. As he says in the abstract, “But learning to program is easy — so easy that children can do it.”  That’s a false comparison — what children do in programming is not the same definition of “programming” that is in most of the literature that Andrew cites.  The evidence that programming is hard is coming mostly from higher-ed CS classes.  What is going on in introductory University CS classes and what children do is dramatically different.  We saw that in the WIPSCE 2014 Fields and Kafai paper, and those results were recently replicated in a recent ICER 2016 paper.  These are two different activities.
• Second, what higher-education CS teachers expect at the end of the first course is too much.  He presents significant evidence that what CS teachers expect is achieved by students, but at the end of the second course.  The paper from Morrison, Decker, and Margulieux supports the argument that students think and work very differently and much more successfully by the end of the second CS course than in the first course.

I see Andrew’s argument as evidence that programming is hard.  The problem is that Andrew doesn’t define the target.  What level of ability counts as “programming”?  I believe that level of ability described by the McCracken Working Group, by the FCS1/SCS1 exams, and by most teachers as the outcomes from CS1 (these are all cited by Andrew’s paper) is the definition of the lowest level of “programming ability.”  That it takes two courses to reach that level of ability is what I would call hard.

I’ve been reading a terrific book, Proust and the Squid: The Story and Science of the Reading Brain by Maryanne Wolf.  It’s the story of how humans invented reading, how we teach reading, and how reading changes our brains (physically and in terms of cognitive function).  Oral language is easy.  We are literally wired for that.  Reading is hard.  We are not wired for that, and much of the invention of reading is about inventing how to teach reading.  Unless you can teach reading to a significant part of your population, you don’t develop a literate culture, and your written language doesn’t succeed.

Much of the invention of written language is about making it easier to learn and teach because learning to read is so hard.  Have you ever thought about why our Latin alphabet is ordered?  Why do we talk about the “ABC”‘s and sing a song about them?  We don’t actually need them to be ordered to read.  Ordering the alphabet makes it easier to memorize, and learning to read is a lot about memorization, about drill-and-practice to make the translation of symbols to sounds to words to concepts effortless (or at least, all System 1 in Kahneman terms).  This makes it easier, but the task of learning to read and write is still a cognitively complex task that takes a significant amount of time to master. It’s hard.

Programming is hard like written language is hard.  It’s not possible to program unless you know how to read.  Programming is particularly hard because the concepts that we’re mapping to are unfamiliar, are not part of our daily experience.  We only see it as easy because we have expert blind-spot.  We have already learned these concepts and made those mappings.  We have constructed understandings of iteration and conditional execution and variable storage.  It is difficult for experts to understand how hard it is to develop those concepts.  The evidence of children programming suggests that most children who program don’t have those concepts.

I remain unconvinced by Andrew’s argument, but I recommend the paper for a great summary of literature and an interesting read.

 

Programming Is Not Math

Fun and interesting blog addressing the belief that mathematics is necessary for programming, a misconception that Nathan Ensmenger claims has reduced the percentage of women in computing.  Sarah Mei goes into some depth addressing (and dispensing with) each of the three claims below

Specifically, learning to program is more like learning a new language than it is like doing math problems. And the experience of programming today, in industry, is more about language than it is about math.And my next thought, of course, was why doesn’t anyone else think this? Why do we still have this idea that math skills indicate programming potential, while language skills mean you should go into poli sci?Well, when I feel out of my depth, I usually start by looking for “official” opinions. So I looked for relevant academic research.
WTF ACADEMIA?!?

I found absolutely none, which is pretty flabbergasting. I found a lot of opinions, both from computer science educators, and from people in industry. Perhaps within academia, the link between math and programming is considered such an obvious truth that it isn’t worth confirming with research.It seems more likely, though, that this research exists, but not under the search terms I tried. Please let me know if you are aware of relevant papers.In the meantime, if we can’t have data, we can at least examine the conversations people have on this topic. Here are some things people often say when asserting that people must be good at math to be good developers.Generally, they fall into three categories:

1. “You need to know math to be a good programmer.”

2. “You need to learn math to get the skills you need for programming.”

3. “Plenty of programming is still math!”

via Sarah Mei » Programming Is Not Math.

Computer coding more in demand than languages: Survey of UK adults

It’s almost a race to the bottom — which do people care less about, learning programming or learning a modern language?

The teaching of computer coding should be prioritised over modern languages, according to a survey of British adults.

Twice as many thought teaching computer coding in school should be a priority than the number who saw Mandarin Chinese as more important. Coding was the top choice for 52%, against 38% who favoured French lessons, 32% Spanish, 25% German and 24% Mandarin.

The poll was published by code.org, a campaign to introduce children and parents to coding. It has created Hour of Code, a series of free tutorials designed to show students the basics of programming in an hour.

via Computer coding more in demand than languages, survey shows | Education | The Guardian.

Eye Movements in Programming Education: Interesting new workshop

Eye Movements in Programming Education: Analyzing the expert’s gaze

Workshop at the 13th KOLI CALLING INTERNATIONAL CONFERENCE ON COMPUTING EDUCATION RESEARCH

Joensuu, Finland, November 13th – November 14th, 2013

Computer Science Education Research and Teaching mainly focus on writing code, while the reading skills are often taken for granted. Reading occurs in debugging, maintenance and the learning of programming languages. It provides the essential basis for comprehension. By analyzing behavioral data such as gaze during code reading processes, we explore this essential part of programming.

This first workshop gives participants an opportunity to get insights into code reading with eye movement data. However, as this data only reflects the low level behavioral processes, the challenge to tackle is how to make use of this data to infer higher order comprehension processes. We will take on this challenge by working on a coding scheme to analyze eye movement data of code reading. The links between low and high level behaviors will help computing science educators to design, realize and reflect on the teaching of code reading skills.

Furthermore, we aim to open discussion about the ways of explicit teaching of readership skills in computing education. Therefore we will discuss the role of reading skills in teaching programming, facilitated by position papers of each participant.

To participate send a mail to teresa.busjahn@fu-berlin.de. It is possible to participate independent of attending Koli Calling. Participants will get eye movement data of reading and comprehension processes of expert programmers, and a coding scheme for annotating the process. You will annotate the video, and reflect on the (perceived) intentions behind the visible pattern. Applying and refining the coding scheme on the data gives insight into the higher order comprehension strategies of the reader.

A short individual reflection and position paper of the results and perspectives for teaching programming is required by the participants [max. 2-3 pages]. As a result, participants will jointly prepare a paper with the data and the refined coding scheme.

via Eye Movements in Programming Education • Computer Science Education • Department of Mathematics and Computer Science.

Teaching Programming To A Highly Motivated Beginner: The Difference between Anecdote and Data

Phillip Guo has a piece in Blog@CACM on how he tutored a single adult to learn to program. He contrasts it with the MOOC approach of teaching thousands. There’s another important contrast–between anecdote and data.

Phillip’s story is interesting and compelling. He raises some key insights, like the value of motivation to drive someone to come to a new understanding. But some of his claims are just too broad, like the one he boldfaced below in his original, “I don’t think there is any better way to internalize knowledge than first spending hours upon hours growing emotionally distraught over such struggles and only then being helped by a mentor.”

Phillip could be right. (I don’t think that he is.) But to suggest that there isn’t a better way based on the study of one learner is over-generalizing. There is a research methods for produce case studies, which is the closest research method to what Phillip did. There’s only so much you can claim from a single case study, though.

Brian usually did 10-15 hours of programming on his own before each 1-2 hour Skype call with me, so he always had plenty of urgent questions and newly-written code that he wanted me to help him debug or improve. If I had just given him lectures without any context, he would not have internalized the lessons as thoroughly. He would have probably nodded his head and been like, “uh huh, ok that makes sense … cool. what’s next?” Instead, because he was usually struggling with concrete, code-related problems before our tutoring sessions — often to the point of frustration and discouragement — he would respond more like, “OHHH, WOW! Now I totally get it!”, whenever I guided him over some problem that seemed insurmountable to him at the time. His joy and relief were always unmistakable. I don’t think there is any better way to internalize knowledge than first spending hours upon hours growing emotionally distraught over such struggles and only then being helped by a mentor.

via Teaching Programming To A Highly Motivated Beginner | blog@CACM | Communications of the ACM.

In the Chronicle: What counts as “programming”? Will it be different for “the rest of us”?

Interesting question, beyond asking what is computational thinking: If you require “programming,” what counts as “programming”?  The Chronicle asks, does typesetting in LaTeX count?

I’m interested in how the non-CS community will answer that question.  What will programming look like for “everyone else,” the non-CS majors, those who aren’t professional software developers?  I’m fascinated by CSound, the music and sound synthesis language.  There are no looping structures, just go-to.  If your first thought is “it looks like assembly language,” check your CS-informed biases at the door, please.  If you don’t know what “assembly language” is, what is CSound?  Almost none of the examples include looping or conditionals.  But for me, it’s definitely programming.  What is our bottomline of what is programming, and in particular, for what communities of practice?

We’ve discussed this before here at the blog, and I suggested that the definition of “programming” be broadly defined to include any creative work that gets a computer to work beyond its basic feature set. So, for example, learning to use MS Word to write a paper — while that’s important — would not count as “programming”, but learning to typeset a research paper in LATEX with a bibliography would (probably) count. Georgia Tech’s approach of using of media computation would seem especially attractive to students who wouldn’t normally count themselves among CS enthusiasts.

via Making Computer Science a Requirement? – Casting Out Nines – The Chronicle of Higher Education.

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.

InfoWorld Programming trends: Education matters less, more JVM/JavaScript-target languages

I found this piece at Infoworld really interesting.  Originally, I was going to blog on it because of the growing trend of languages that target the JVM or JavaScript — what are the implications about Java and JavaScript when there’s so much interest in creating specialized languages on top of them?  But then I got to Programming Trend #8 and realized that this was really a piece for us to talk about — does traditional computing education matter anymore?

Ask any project manager and they’ll say there’s not enough talent from top-tier computer science departments. They may go so far as to say they would hire a new CS major from a top school without reading the résumé. But ask this same desperate project manager about a middle-aged programmer with a degree from the same school, and they’ll hesitate and start mumbling about getting back to you later.

Indeed, it isn’t unheard of to find major technology companies complaining to Congress that they can’t find Americans capable of programming, all while defending themselves in age-discrimination lawsuits from older programmers with stellar résumés and degrees from top universities.

Some of this may suggest that education doesn’t have the same value it used to hold. Older workers with degrees that used to be valuable are saying companies want only young, unfettered bodies that will work long hours. It leaves you to wonder whether it’s the age and implied lower pay expectations, not the knowledge that makes fresh college graduates so desirable.

via 11 programming trends to watch.

Teaching programming to those who don’t shoot: Give up on the shooters

I’ve been exchanging email lately with a CS teacher using media computation in Python with her 9th grade class this year. She has been pushing the boundaries of JES, trying to do more interactive programming. It’s hard to do with JES. Swing and Jython don’t get along all that well, particularly from within JES, a Swing application.  I finally asked her: Why not just use media computation for what it’s good for?  Play to its strengths: Make collages, sound collages, music, and videos.  Interactivity is hard for early beginners.  She had this response.

I need to develop an approach that appeals to all of the people who have traditionally signed up for programming classes (because they want to shoot things) along with the underrepresented groups who have not signed up for programming because they don’t want to shoot things.

It’s a great comment, and it’s a deep question.  Does she?  Does she need to serve both audiences?  Do we need to teach, in every classroom, to engage every student?

This issue comes up when I talk to people about Threads.  “We love your approach, but we have a small school.  We can’t cover all those Threads.  What should we do?”  The answer is not “whatever we have been doing, pretty much decontextualized, which works for any problem” (which is what I normally hear).  Go ahead and specialize. Teach to a context.  Students (especially novices who don’t understand what computing is for) will learn more, and more deeply, than by teaching in a decontextualized way.  Your students will be more marketable by knowing about computing + X, where X is some interesting applications context.  Pick a context that draws the students that you want to encourage and engage.

At the post-secondary level, you don’t have to please everybody in every class in every school. Students have choices. Colleges should play to their strengths.  Larger Universities can offer more options on the same campus.  For smaller schools, build coalitions so students have choices between the schools.

But the question is harder for the high school teacher.  Her students don’t have a choice.  If she doesn’t engage them, they’re not going to get computer science somewhere else.

Here’s my answer, though I realize that it comes at some risk: Give up on the shooters.  There’s a lot more of those who weren’t interested in computing traditionally, than those that were.  Computer science in the last decades has drawn from only a small demographic.  Play to the larger audience. Play to the audience with different interests than those most commonly in CS today.  Teach to those who don’t shoot.

How only one path fails to help everyone succeed at learning how to code

Project Euler sounds great!  The author of the now oft-forwarded Atlantic piece is making a mistake by extrapolating from himself to everyone.

The article (linked below) tells the story of how author James Somers finally learned to program by discovering Project Euler, an effort to teach programming by leading students through a sequence of carefully constructed programming problems.  Somers “finally” learned to program after first failing at reading one of the enormous tomes on how to program and then after failing to learn through AP CS.

I don’t doubt that Somers really did learn a lot from Project Euler, and I believe that thousands have and will in the future.  The “inductive chain” theory described below seems plausible.  Project Euler is a terrific idea!  I also believe, though, that some people do learn (at least, get started) from those massive tomes, and others do learn through the more engineering-oriented approach that Somers dislikes in AP CS.  Some may even learn from playing with digital media.

I personally don’t find Project Euler’s problems attractive.  Somers gives this example of a Project Euler problem that inspired him:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

I completely believe that Somers was inspired by this.  I do not have an “itch” to solve this one.  I don’t find mathematical puzzles that fun.  I like to make things, so when I was getting started learning to program, I was motivated to play around and explore by building things.  My first sizable just-for-fun program played tic-tac-toe, and most of my just-for-fun projects were interpreters and compilers.  Today, I like to make interesting pictures and sounds with Media Computation.  My experience doesn’t mean that Somers is wrong about Project Euler working for him.  He’s wrong in believing it can work for everybody.

We need multiple paths.  Math works to motivate some.  Engineering for others.  Media for still others.  I agree that getting the playful learning that Somers wants is about engagement and motivation.  Math doesn’t engage and motivate everyone.

Project Euler, named for the Swiss mathematician Leonhard Euler, is popular more than 150,000 users have submitted 2,630,835 solutions precisely because Colin Hughes — and later, a team of eight or nine hand-picked helpers — crafted problems that lots of people get the itch to solve. And its an effective teacher because those problems are arranged like the programs in the ORIC-1s manual, in what Hughes calls an “inductive chain”:The problems range in difficulty and for many the experience is inductive chain learning. That is, by solving one problem it will expose you to a new concept that allows you to undertake a previously inaccessible problem. So the determined participant will slowly but surely work his/her way through every problem.

via How I Failed, Failed, and Finally Succeeded at Learning How to Code – Technology – The Atlantic.

A Computer Science Fair without Computer Science

(Thanks to Kevin Karplus for this link.)  I agree with the author quoted below, that it is alarming that the “Computer Science Fair” he’s describing doesn’t have a single example of computer science.  However, I’m not as hung up over the lack of coding.  I can imagine some really interesting projects at the middle school level science fair level that might be about digital representation or computation without being about programming.  I’m just making these up, but here are some examples:

• Given the same picture, is JPEG bigger than PNG, or vice versa?  Does it matter what’s in the picture? Why might the sizes differ?
• My Senior Design students built me a gadget I’ve been wanting for awhile: A spreadsheet to picture converter.  I’ll write more about it later. I could imagine using something like that to ask, “When I ‘remove red eye,’ what actually happens to the pixels in the picture?”
• For some activities that are like what we see computers doing (e.g., putting objects in bins, finding something in a pile, sorting numbered cards in increasing order, solving large-multi-digit arithmetic problems), can we figure out ways of doing those tasks faster with two people than with only one? (I am thinking about CS Unplugged-like activities here, but making it a science fair challenge.)
• Using only binary (only 0’s and 1’s), can I encode text? What is the smallest number of bits I can use to encode some text so that someone else, told the encoding, could get the text back out of the bits?

I have a middle schooler at home right now.  She’s curious and smart, but so far, she’s not shown much interest in programming.  But puzzles and how-things-work questions interest her — I think she could do things like these, and would like to do them.  She enjoys the puzzles that Barb poses to her, like how high can you count with the fingers of one hand (31, if you shift to binary).  It’s computer science, but it’s not programming.

Not a single category, it would seem, for actual computer programming. No sense that computer programming involves anything more that the consumption and marketing of computer technology. No sense of the tremendous analytical skills that go into the coding that makes all the rest of this possible.

And yet another area that has been hijacked away from the most left-brained of our students.

Perhaps there’s some virtue in this contest, but could we possibly call it something other than a “Computer Science” fair?

And could we possibly have a city-wide Computer Science Fair that’s actually worthy of the name–i.e., one that showcases the work of those who do actual programming?

via Out In Left Field: The Right-Brained Computer Science Fair.

Programs as Poetry, and Programming as Art

Ian Bogost has just released a quartet of video games that he calls “poetry.”  I’m familiar with the idea that program code itself is a form of expression.  We have literate programming, and Donald Knuth’s famous Turing Award lecture “Computer Programming as an Art.”  Ian is saying something different here — that the program can be art, by being “expressive within tight constraints.”

Ian’s poems are saying something very interesting about human-computer interaction (HCI).  The poems are all about improving the lives of the humans who play them, in the subtle way of introducing new ideas and encouraging reflection.  However, they are not about usability.  These poems perform no useful, application-driven function.  They are “inscrutable.” The user manual for each program is a single Haiku.

Both literate programming and Ian’s poems introduce an interesting idea for computing teachers: What do we teach students about programming and programs as art? What should we be teaching them, about expressiveness, about craftsmanship, about creating code for reasons other than solving a problem or facilitating a task?

The games are simple, introduced to us who have no standards with which to judge the quality of video game poems. The A Slow Year games were made with the understanding that poetry can resist being obvious, that it can be expressive within tight constraints, that it can, like a video game, challenge its reader to work through it, that it can be vague but specific, harsh yet beautiful. The autumn game is just a slow game of waiting for a leaf to fall off a tree and catching it right on time. The spring game’s goal is to match thunder with lightning in a rainstorm. The summer game is the simple but daunting challenge to take a proper nap, a first-person game seen from behind drooping eyelids.

Each game was made to run on the Atari but will run on Windows or Macintosh computers.

Each is tough and accompanied with only a haiku for instructions.

via What If A Video Game Was Poetry? | Kotaku Australia.

(How to Write a (Lisp) Interpreter (in Python))

It’s not really computing education, but it’s totally geeky fun and could make for a cool project to dissect for a student in a programming language’s class.

This page has two purposes: to describe how to implement computer language interpreters in general, and in particular to show how to implement a subset of the Scheme dialect of Lisp using Python. I call my interpreter Lispy (lis.py). Years ago, I showed how to write a Scheme interpreter in Java as well as one in Common Lisp. This time around the goal is to demonstrate, as concisely and accessibly as possible, what Alan Kay called “Maxwell’s Equations of Software.”

via (How to Write a (Lisp) Interpreter (in Python)).

Programming or Be Programmed: A New Medium Requires A New Literacy

A new book is out by Douglas Rushkoff, Programming or Be Programmed, that makes a new, intriguing argument for learning to program: because “all systems have embedded purposes.”  If you don’t know about programming, you don’t know how to ask what that embedded purpose is.  I’m not sure that that’s true.  Don’t you wonder “Who is paying for this website?” for just about anyplace you visit, whether or not you program?

He argues that, “Amazingly, America — the birthplace of the Internet — is the only developed nation that does not teach programming in its public schools.”  Is that really true?  If so, that’s a stunning claim.

As we come to experience more of our world and one another through our digital interfaces, programming amounts to basic literacy. Even if we can’t truly program ourselves, recognizing how the programs we do use really work is revolutionary in itself. For once people come to see the way their technologies are programmed, they start to recognize the programs at play everywhere else – from the economy and education to politics and government.

All systems have embedded purposes. The less we recognize them, more we mistake them for given circumstances. We start to treat the map as the territory.

At the very least we must come to recognize the biases – the tendencies- of the technologies we are using, and encourage our young people to do the same. If we don’t participate in building our digital future together, it will be done by someone – or something – else.

via Douglas Rushkoff: Why Johnny Can’t Program: A New Medium Requires A New Literacy.