Posts tagged ‘Alice’

One of the results from Betsy DiSalvo’s dissertation on Glitch (see a post on that work) that I found most interesting was that there wasn’t a clear winner between graphical, drag-and-drop programming (Alice) and text-based programming (Python). She has now written up that part of the dissertation work, and it’s linked below.

To determine appropriate computer science curricula, educators sought to better understand the different affordances of teaching with a visual programming language (Alice) or a text-based language (Jython). Although students often preferred one language, that language wasn’t necessarily the one from which they learned the most.

I’ve been excited to see this paper get published since Betsy first told me about the work. The paper described below (by Betsy DiSalvo, Cecili Reid, and Parisa Khanipour Roshan) looks at the terms that families commonly use to find on-line resources to help their children learn about computer science. They didn’t find Alice or Scratch or Blockly — none of the things that would be our first choices for CS education opportunities on-line. Betsy and her students show how we accidentally hide our resources from the uneducated and under-privileged, by presuming that the searchers are well-educated and privileged. They point out that this is one way that open education resources actually actuallyincrease the socioeconomic gap, by not being easily discoverable by those without privilege. I got to see a preview of this talk, and the results are surprising — a video of the preview talk will be available here. Friday March 7, 3:45-5, in Room Hanover DE.

They Can’t Find Us: The Search for Informal CS Education

In this study we found that search terms that would likely be used by parents to find out-of-school computer science (CS) learning opportunities for their children yielded remarkably unproductive results. This is important to the field of CS education because, to date, there is no empirical evidence that demonstrates how a lack of CS vocabulary is a barrier to accessing informal CS learning opportunities. This study focuses on the experience of parents who do not have the privilege of education and technical experience when searching for learning opportunities for their children. The findings presented will demonstrate that issues of access to CS education go beyond technical means, and include ability to conduct suitable searches and identify appropriate computational learning tools. Out-of-school learning is an important factor in who is motivated and prepared to study computer science in college. It is likely that without early access to informal CS learning, fewer students are motivated to explore CS in formal classrooms.

We would like to inform you that we have added recently many new resources to the Computer Science Open Educational Resources Portal (CS OER Portal) (http://iiscs.wssu.edu/drupal/csoer ). For those of you who have not visited it, the Portal hosts a rich collection of links to open teaching/learning materials targeted specifically the area of Computer Science. It provides multiple ways for locating resources, including search with filtering the results by CS categories, material type, level, media format, etc., as well as browsing by institutional (OpenCourseWare) collections, by CS categories, or by topics as recommended by the ACM/IEEE Computer Science Curriculum. The browsing functionality is supplemented with recommendations for similar courses/resources.

It’s really great that there are so many repositories, so many resources to help CS teachers, and so many people developing and sharing resources. I get concerned when I’m in a meeting where we’re talking about how to help CS teachers, and someone suggests (and it really happens in many of the meetings I attend), “If we only had a repository where teachers could find resources to help them…” No, I really don’t think that morerepositories is going to solve any problems at this point.

Interesting arguments from the CEO of LiveCode. These two points are particularly interesting. The first is: What sits between Scratch, or Alice, or App Inventor, and professional-class languages like JavaScript or C++? I would put Python in there, but I still see that the Scratch->Python gap is a big one. The second paragraph is really striking, and I’d like to see more evidence. Does Israel’s great CS ed system lead to the strong startup culture, or is it because Israelis value technology that they have both a great startup culture and a great CS Ed system?

Up to about age 13 there are some excellent tools in widespread use, most notable among them being the free and popular Scratch from MIT and MIT App Investor However students outgrow Scratch by around age 13 and schools often don’t make a good choice of language for the next phase in a child’s education. Many traditional programing languages such as JavaScript or C++ are completely inappropriate for this age group. Students struggle to understand what they are learning and often spend their lessons searching for a missing symbol. The current generation of students use smartphones and so selecting a tool that allows them to create their own apps is another great opportunity to make learning directly relevant to them. Our own LiveCode platform provides a handy solution to these issues by allowing students to create their own mobile apps using a programming language that is close to English.

I firmly believe that a strengthening computer science education program has to be one of the most obvious and cost effective things we can do to ensure future economic prosperity. Israel has the highest rate of startup per capita anywhere and that in part stems from its strong computer science education program. Estonia, another country with both a strong tech sector and economy, recently announced a plan to expand teaching of computer science to all primary school children. Do we want to be left in the dust by these countries, or left unable to compete with the growing economies of India and China? What is it going to take to get computer science education moved up the agenda in the USA and here in the UK?

I have had several people now send me a link to Bret Victor’s video on Inventing on Principle. It is a really impressive demo!

His system reminds me of Mike Eisenberg’s work on SchemePaint. Mike wanted the artist to be able to interleave programming and direct manipulation. In SchemePaint, you could draw something by hand, then store the result in a variable to manipulate in a loop. Or you could write some code to tesselate some graphical object, then add tweaks by hand. It was beautiful. The work that Mike did on SchemePaint led to his wonderful work on HyperGami, a CAD system for origami, which was the start of his Craft Technology group. That’s the group from which Leah Buechley graduated — she did the LilyPad.

The problem is that visualization is about making information immediate and accessible, but learning is about changes in the mind — invisible associations and structures. Sometimes good usability makes it easier to make these associations and structures. Tools like Scratch and Alice increase usability in one direction (e.g., syntax) while still asking students to make an effort toward understanding (e.g., variables, loops, and conditionals).

My first PhD student was Noel Rappin, who explored the features of modeling environments that lead to learning. He had a CHI paper about his work on helping chemical engineers learn through modeling. Our colleagues in chemical engineering complained that their students couldn’t connect the equations to the physical details of the pumping systems that they were modeling. Noel built a system where students would lay out the physical representation of a pumping system, then “look underneath” to see the equations of the system, with the values filled in from the physical representation (e.g., height difference between tanks).

He ran a pilot study where students would lay out a system according to certain characteristics. They would then manipulate the system to achieve some goal, like a given flow rate at a particular point in the system. When Noel asked the pilot students if they gained any new insights about the equations, one student actually said, “What equations?” They literally didn’t see the equations, just the particular value they were focusing on. The system was highly usable for modeling, but not for learning.

Noel built a new system, where students could lay out a model, and values from the model were immediately available in an equation space. To get the flow rate, the student would have to lay out the equations for themselves. They would still solve the problem by manipulating the physical representation in order to get the right flow rate, and the system would still do all the calculations — but the students would have to figure out how to compute the flow rate. The system became much harder to use. But now, students actually did learn, and better than students in a comparison group.

Bret’s system is insightful and may have some terrific ideas for helping learning. I’m not convinced that they’re new ideas yet, but an old idea in a new setting (e.g., JavaScript) can be powerful. I worry that we get too entranced by improvements in usability. In the end, learning is in the student, not in the system.

Last week was the International Computing Education Research conference for 2011 at Rhode Island College in Providence, RI. (What a cool city! My first time, and I enjoyed getting lost on one of my runs!) It was the first time in years that I actually stayed for the whole conference, since I left after the first day last year. I enjoyed realizing again why I loved this conference so much. Several of the papers were wonderful, the discussions and hallway chit-chat were terrific, and it was great to see so many colleagues, as well as meet people whose papers I’ve been reading but hadn’t yet met.

I’m labeling this “Mark’s Trip Report” because I’m not going to attempt to be thorough or fair in what papers I mention. I’ll tell you about what struck me. I’ll do a separate post just on the keynote.

The first set of papers were ostensibly about how students choose computing, but I thought that there was a strong subtext about understanding the student experience of a computing classes.

Colleen Lewis talked about “Deciding to Major in Computer Science: A grounded theory of students’ self-assessment of ability,” but it was really much more about that “self-assessment” part than about the “deciding” part. Colleen told us that a common theme in her interviews were the tension between growth vs. fixed mindset (drawing on Carol Dweck’s work). Many students decide early on that they’re bad at computing and they can’t get better, i.e., they don’t have the “Geek gene.” Those students won’t choose CS, of course, but for such a disappointing reason.

Mike Hewner presented his work, which spoke to where students get their information about CS and how a good class experience can color a student’s perception of a specialization area.

Päivi Kinnunen presented “CS Majors’ Self-Efficacy Perceptions in CS1: Results in light of social cognitive theory” which was about applying Bandura’s work (which explores how early failures at something lower students’ belief of their ability to do that something) to CS1.
Päivi’s paper got me wondering what we’re telling CS majors when we have them use Alice or Scratch in CS1. As we know from Mike’s work, CS majors know something about CS — they know something about the languages used in regular practice. When we tell them to use Alice or Scratch, are we saying to them (in light of Bandura’s work), “You aren’t capable of using the real, authentic practice” and thus lower their self-efficacy? And if we use a “real” language (even if harder) are we saying (in a Dweck growth mindset sense), “Yeah, this is hard, but you can do it. You can learn to handle the real thing.”?

Päivi’s talk was a great set-up for Sally Fincher’s “Research Design: Necessary Bricolage,” which ended up winning the people’s choice (voted) best paper award (called the “Fool’s Award” at ICER). Sally was asking how we go about gathering information about our students’ practices. She said that we rely far too much on semi-structured interviews, and we should think about combining other methods and practices to gain more insight. She showed examples of some of her research instruments, which were really wonderful (i.e., I plan to steal them as early as this semester!). Here’s a neat combination of methods: First, give students a graph of 24×7 in 30 minute increments, and ask them to mark when they work on the class.

That’s the “when.” To get the “where,” Sally (and Josh Tenenberg and Anthony Robins) gave students cheap digital cameras, and asked them to take a picture of where they were working.

That upper left hand corner is a bus seat. Would you have guessed that your students do CS homework on the bus? Notice the mixture of affordances: In the bus, in the dorm room, in the lab with peers, at a table to work with friends. Did you realize that students are working so much away from a rich computational infrastructure? There’s no bottomline result here — rather, it’s about what data we should be gathering to figure out the things that we don’t realize yet that we need to know.

I enjoyed the papers by Cynthia Bailey-Lee, Beth Simon (for her paper on PeerWise with lead author Paul Denny — Beth’s name seemed to be on every-other paper this year!), and Matt Jadud because they were all replication studies. Cynthia was taking a finding from Biology (on using peer instruction) and seeing if it worked in CS. Beth and Matt were both taking earlier CS Ed papers, and see if they still worked in new settings. It doesn’t matter what the bottomline finding was. It’s so cool that our field is starting to go deep and check the work of earlier papers, to explore where it works and where it doesn’t, and to develop more general understanding.

Kathi Fisler presented a really interesting paper, “Do values grow on trees? Expression integrity in functional programming” that was particularly interesting for the variety of interpretations of the paper. Kathi presented it as an exploration of whether function programming is “unnatural” for students. I’m not sure how to ask that question. What I found them exploring was, “How do novices and experts see the nested structure of s-expressions? Do they see the trees? Is that evident in their editing behavior, e.g., do they edit maintaining expression integrity, or do they ignore the parentheses when typing?” Since so much computing involves the Web today, I’m wondering how comparable the results would be to people typing HTML (which is also a nested, tree-based notation).

I had a nice chat with Kathi’s co-author Guillaume Marceau who, with Kathi and Shriram, won the SIGCSE 2011 best paper award on designing error messages for students (which is an issue that has come up here recently). I told Guillaume about Danny Caballero’s thesis, and he told me about why it’s so difficult to get error messages right for students. The problem is that, by the time the parser has figured out what the problem is, all the context information to help the student has been thrown away. An example is “identifier not found.” For a student, a variable and a method/function name are completely different identifiers, completely different meanings. It takes students a long time to generalize an identifier-value pairing such that the value could be an integer, an object, or a code block. For most compilers, though, why you want the identifier is lost when the compiler can’t find an identifier’s meaning. Racket contains compiler calls that help you construct the context, and thus provide good error messages. He doesn’t hold out much hope for Java — it’s so hard just to compile Java, and refactoring it for good error messages to help students may be impossible.

Two other papers that I want to say brief words about:

Simon’s paper on “Explaining program code: giving students the answer helps — but only just” follows up on the Bracelet work where students were asked to read and explain the purpose of a piece of code. The students failed miserably. Simon wondered, “What if we gave them the answer?” Rather than have the students fill-in-a-blank about what the code did, he gave them a multiple-choice question where the answers were the top five guesses from the first study. Yes, there was improvement. But no, performance was still appalling.

Michael Lee presented on “Personifying programming tool feedback improves novice programmers’ learning,” which is a slightly wrong title. What they did was to create a programming task (moving a little graphical character around on a board), but “personified” the parser. A mistyped command might get the little character to say sheepishly, “I’m sorry, but I really don’t know how to do that. I wish I did. I know how to do X. Is that what you would like me to do?” I don’t think that the authors really measured learning, but what they did measure was how long students stuck with it — and a personified compiler is not nearly as scary, so students stick with it longer. (See Bandura above.)

Chris is actually working on several different ideas including audio debuggers and manipulatives (physical artifacts) for representing the programs. Chris said that his colllaborator, Andreas Stefik (Chris’ former student) is excellent at empirical methods, so all his design ideas are carefully developed with lots of trials. The paper includes results from a test of the whole suite of tools.

I hope that lots of people follow-up on Chris’s work and direction. My bet that what they’re finding will enable multi-sensory programming environments that will help everyone.