Posts tagged ‘Scratch’
Code Smells might suggest a different and better Notional Machine: Maybe students want more than one main()
There is a body of research that looks for “code smells” in Scratch projects. “Code smells” are characteristics of code that suggest a deeper problem (see Wikipedia description here). I have argued that these shouldn’t be applied to Scratch, that we’re confusing software engineering with what students are doing with computing (see post here).
One of the smells is having code lying around that isn’t actually executed from the Go button, the green flag in Scratch. The argument is that code that’s not executed from the Go button is unreachable. That’s a very main() oriented definition of what matters. There was a discussion on Twitter about that “smell” and why it’s inappropriate to apply to Scratch. I know that when I program in GP (another block-based program), I often leave little bits of maintenance code lying around that I might use to set the world’s state.
There’s another possibility for code lying around that isn’t connected and thus doesn’t executd properly — it should execute properly. There’s evidence that novice students are pretty comfortable with the idea of programs/functions/codechunks executing in parallel. They want more than one main() at once. It’s our programming systems that can’t handle this idea well. Our languages need to step up to the notional machines that students can and want to use.
For example, in Squeak eToys, it’s pretty common to create multiple scripts to control one object. In the below example, one script is continually telling the car to turn, and the other script is continually telling the car to go forward. The overall effect is that the car turns in circles.
I was on Kayla DesPortes dissertation committee (now at NYU!). She asked novice programmers to write a script to make two lights on an Arduino to blink. She gave them the code to blink one light: In a Forever loop, they raise the voltage on a pin high, then wait a bit, then lower the voltage, then wait a bit. That makes a single light blink.
The obvious thing that more than half of the participants in her study did was to duplicate the code — either putting it in parallel or putting in sequence. One block blinked the light on one pin, and the other block blinked the light on the other pin. However, both blocks were Forever loops. Only script can execute on Arduino at a time.
On the Arduino, what the students did was buggy. It “smelled” because the second or parallel Forever block would never execute.
These examples suggest that parallel execution of scripts might be normal and even expected for novices. Maybe parallel execution is an attribute of a notional machine that is natural and even easier for students than trying to figure out how to do everything in one loop. Maybe concurrency is more natural than sequentiality.
Something that “smells” to a software engineer might actually be easier to understand for a layperson.
A little bit of computing goes a long way, and not everyone needs software engineering: The SIGCSE 50th Anniversary issue of ACM Inroads
This year is the 50th SIGCSE Technical Symposium, and Jane Prey was guest editor for a special issue of ACM Inroads on 50 years of ACM SIGCSE. You can see the current issue here, but yes, it’s behind a paywall — ACM Inroads is meant to be a membership benefit.
I’m really fascinated by this issue. Sally Fincher does a nice job telling the story of ICER. I enjoyed Susan Rodgers’ and Valerie Barr’s reflections. I’m still trying to understand all of Zach Dodds’ references in his SIGCSE 2065 future-retrospective. I found some of the articles frustrating and disagreed with some of the claims (e.g., I don’t think it’s true that AP CS enrollments plummeted after introducing Java), but discussion can be good for the community.
I was asked to write a piece about What we care about now, and what we’ll care about in the future. My bottom line is a claim that John Maloney (of Squeak, Scratch, and GP fame) reminded me is a favorite phrase of the great Logo (and many other things) designer, Brian Silverman: A little bit of computing goes a long way.
The important part of Scratch is that computationalists find value in it, i.e., that they can make something that they care about in Scratch. What we see in Scratch is the same process we see among the computationalists in computational photography, journalism, and science. They don’t need all of computer science. They can find value and make something useful with just some parts of computing. Scratch projects smell wonderful to Scratch computationalists.
There’s been a thread on Twitter recently about the use of software engineering principles to critique Scratch projects (see the thread starting here). Researchers in software engineering claim that Scratch code “smells,” e.g., has bad practices associated with it. There’s even a website that will analyze your Scratch project in terms of these software engineering practices, DrScratch. The website claims that it is measuring computational thinking skills — I see no evidence of that at all.
These software engineering researchers are misunderstanding users and genres of programming. They ought to read Turkle and Papert’s Epistemological Pluralism and the Revaluation of the Concrete. People code for different purposes, with different ways of appropriating code. The standards of the software engineer are not appropriate to apply to children. Not everybody is going to be a professional software developer, and they don’t need to be.
Increasingly, people are only going to use parts of computer science, and they will achieve fluency in those. That’s a wonderful and powerful thing. A little bit of computing goes a long way.
Visiting NTNU in Trondheim Norway June 3-23
Barbara and I are just back from a three week trip to NTNU in Trondheim, Norway. Katie Cunningham came with us (here’s a blog post about some of her work). Three weeks is enough time to come up with a dozen ideas for blog posts, but I don’t have the cycles for that. So let me just give you the high-level view, with pictures and links to learn more.
We went at the beginning of June because Barb and I (and the University of Michigan) are part of the IPIT network (International Partnerships for Excellent Education and Research in Information Technology) that had its kick-off meeting June 3-5. The partnership is about software engineering and computing education research, with a focus student and faculty exchange and meetings at each others’ institutions: NTNU, U. Michigan, Tsinghua University, and Nanjing University. I learned a lot about software engineering that I didn’t know before, especially about DevOps.
If you ever get the chance to go to a meeting organized by Letizia Jaccheri of NTNU, GO! She was the organizer for IPIT, co-chair of IDC 2018, and our overall host for our three weeks there. She has a wonderful sense for blending productivity with fun. During the IDC 2018 poster session, she brought in high school students dressed as storybook characters, just to wander around and “bring in a bit of whimsy.” For a bigger example, she wanted IPIT to connect with the NTNU campus at Ålesund, which just happens to be near the Geiranger fjord, one of the most beautiful in Norway. So, she flew the whole meeting to Ålesund from Trondheim! We took a large cruise-ship like boat with meeting rooms down the fjord. We got in some 5-6 hours of meetings, while also seeing amazing waterfalls and other views, and then visited the Ålesund campus the next day before flying home. We got work done and WOW!
For the next week and a half, we got to know the computing education research folks at NTNU. We were joined at the end of the first week by Elisa Rubegni from the University of Lincoln, and Roberto Martinez-Maldonado came by a couple days later. Barb, Elisa, and I held a workshop on the first Monday after IPIT. A couple days later, we had a half-day meeting with Michalis Giannakos’s group and Roberto, then Elisa led us all in a half-day design exercise (pictured below — Elisa, Sofia, Javi, and Katie). In between, we had individual meetings. I think I met with every one of the PhD students there working in computing education research. (And, in our non-meeting time, Barb and I were writing NSF proposals!)
Michalis’s group is doing some fascinating work. Let me tell you about some of the projects that most intrigued me.
- Sofia (with Kshitij and Ilias) is lead on a project where they track what kids using Scratch are looking at, both on and off screen. It’s part of this cool project where kids program these beautiful artist-created robots with Scratch. It’s a pretty crazy looking experimental setup, with fiducial markers on notebooks and robots and screens.
- Kshitij is trying to measure EEG and gaze in order to determine cognitive load in a user interface. Almost all cognitive load measures are based on self-report (including ours). They’re trying to measure cognitive load physiologically, and correlate it with self-report.
- Katerina and Kshitij is using eye-tracking to measure how undergrads use tools like Eclipse. What I found most interesting was what they did not observe. I noticed in their data that they had no data on using the debugger. They explained that in 40 students, only five people even looked at the debugger. Nobody used data or control flow visualizations at all. I’m fascinated by this — what does it take to get students to actually look at the debuggers and visualizers that were designed to help them learn?
- Roberto is doing this amazing work with learning analytics in physical spaces, where nurses are working on robot patients. Totally serious — they can gather all kinds of data about where people are standing, how they interact, and when they interact. For tasks like nursing, this is super important to understand what students are learning.
Then came FabLearn with an amazing keynote by Leah Buechley on art, craft, and computation. I have a long list of things to look up after her talk, including Desmos, computer controlled cutting machines (which I had never heard of before) which are way cheaper than 3-D printers but still allow you to do computational craft, and http://blog.recursiveprocess.com/ which is all about learning coding and mathematics. She made an argument that I find fascinating — that art is what helps diverse students reflect their identity and culture in their school, and that’s why students who get art classes (controlling for SES) are more likely to succeed in school and go onto post-secondary schooling. Can computing make it easier to bring art back into school? Can computing then play a role in engaging children with school again?
The next reason we were at NTNU was to attend the EXCITED Centre advisory board meeting. Barb and I were there for the launch of EXCITED in January 2017. It’s a very ambitious project, starting from students making informed decisions to go into CS/IT, helping students develop identities in CS, learning through construction, increasing diversity in CS, and moving into careers. We got to hang out with Arnold Pears, Mats Daniels, and Aletta Nylén of UpCERG (Upssala Computing Education Research Group), the world’s largest CER group.
Finally, for the last four days, we attended the Interaction, Design and Children Conference, IDC 2018. I wrote my Blog@CACM post for this month about my experiences there. I saw a lot there that’s relevant to people who read this blog. My favorite paper there tested the theory of concreteness fading on elementary school students learning computing concepts. Here’s a picture of a slide (not in the paper) that summarizes the groups in the experiment.
I’ll end with my favorite moment in IDC 2018, not in the Blog@CACM post. We met Letizia’s post-doc, Javier “Javi” Gomez at the end of our first week in Trondheim. Summer weather in Trondheim is pretty darn close to winter in Atlanta. One day, we woke up to 44F and rain. But we lucked out — the weekends were beautiful. On our first Saturday, Letizia invited us all to a festival near her home, and we met Javi and Elisa. That evening (but still bright sunlight), Javi, Elisa, Barb, and I took a wonderful kayaking trip down the Nidelva river. So it was a special treat to be at IDC 2018 to see Javi get TWO
awards for his contributions, one for his demo and an honorable mention for his note. The note was co-authored by Letizia, and was her first paper award (as she talks about in the lovely linked blog post). It was wonderful to be able to celebrate the success of our new friends.
On the way back, Barb and I stopped in London to spend a couple days with Alan Kay and his wife, Bonnie MacBird. If I could come up with a dozen blog post ideas from 3 weeks, it’s probably like two dozen per day with Alan and Bonnie, and we had two days with them. Visiting a science museum with an exhibit on early computers (including an Alto!) is absolutely amazing when you’re with Alan. But those blog posts will have to wait until after my blog hiatus.
The General Purpose Blocks Programming Language, GP, is now in beta
GP, the powerful new blocks-based programming language (that I wrote about here, helped show at SIGCSE 2017, and used for MediaComp in a new kind of ebook here), is available for beta-testing as the Scratch 2017 conference starts in Bordeaux, France. You can access GP at http://www.gpblocks.org. You can run projects in your browser on the website, or download the application.
GP is a free, general-purpose blocks language that is powerful yet easy to learn.
GP can:
-
generate high-quality graphics computationally
-
manipulate images and sounds
-
analyze text files or CSV data sets
-
simulate physical, biological, or economic systems
-
access the web and use cloud data
-
connect to hardware via the serial port
-
deploy projects on the web or as stand-alone apps
Source: About · GP Blocks
Attending the amazing 2017 Computing at School conference #CASConf17
June 17, Barbara and I attended the Computing at School conference in Birmingham, England (which I wrote about here). The slides from my talk are below. I highly recommend the summary from Duncan Hull which I quote at the bottom.
CAS was a terrifically fun event. It was packed full with 300 attendees. I under-estimated the length of my talk (I tend to talk too fast), so instead of a brief Q&A, there was almost half the time for Q&A. Interacting with the audience to answer teachers’ questions was more fun (and hopefully, more useful and entertaining) than me talking for longer. The session was well received based on the Tweets I read. In fact, that’s probably the best way to get a sense for the whole day — on Twitter, hashtag #CASConf17. (I’m going to try to embed some tweets with pictures below.)
Barbara’s two workshops on Media Computation in Python using our ebooks went over really well.
I enjoyed my interactions all day long. I was asked about research results in just about every conversation — the CAS teachers are eager to see what computing education research can offer them. I met several computing education research PhD students, which was particularly exciting and fun. England takes computing education research seriously.
Miles Berry demonstrated Project Quantum by having participants answer questions from the database. That was an engaging and fascinating interactive presentation.
Linda Liukas gave a terrific closing keynote. She views the world from a perspective that reminded me of Mitchel Resnick’s Lifelong Kindergarten and Seymour Papert’s playfulness. I was inspired.
The session that most made me think was from Peter Kemp on the report that he and co-authors have just completed on the state of computing education in England. That one deserves a separate blog post – coming Wednesday.
Check out Duncan’s summary of the conference:
The Computing At School (CAS) conference is an annual event for educators, mostly primary and secondary school teachers from the public and private sector in the UK. Now in its ninth year, it attracts over 300 delegates from across the UK and beyond to the University of Birmingham, see the brochure for details. One of the purposes of the conference is to give teachers new ideas to use in their classrooms to teach Computer Science and Computational Thinking. I went along for my first time (*blushes*) seeking ideas to use in an after school Code Club (ages 7-10) I’ve been running for a few years and also for approaches that undergraduate students in Computer Science (age 20+) at the University of Manchester could use in their final year Computer Science Education projects that I supervise. So here are nine ideas (in random brain dump order) I’ll be putting to immediate use in clubs, classrooms, labs and lecture theatres:
Source: Nine ideas for teaching Computing at School from the 2017 CAS conference | O’Really?
My talk slides:
Visit to researchers at ExcITEd Center at NTNU
In January, Barbara Ericson and I were invited to visit the new ExcITED Center at NTNU in Trondheim, Norway. ExcITED is the Centre for Excellent IT Education. It was a whirlwind trip, fitting it in after the start of our semester at Georgia Tech, but really wonderful. We got there just as NTNU was celebrating their new Department of Computer Science with an “IDIovation” celebration which included some great research talks and (a highlight for me) a live coding computer music performance. The whole event was recorded and is available here.
Our host for the visit was Michail Giannakos, who is a learning scientist interested in a variety of educational technologies. We got a chance to meet with several of the faculty and many of the students working in ExcITED. Like I said, it was a whirlwind trip, so please excuse me if I only mention a few of the projects we saw — the ones that particularly stuck with me, despite the jet-lag.
One team at ExcITED is logging student interactions with the IDE that they use in their classes at the University, like the BlueJ Blackbox effort. What makes what they’re doing remarkable is that they’re immediately turning the data around, to present a process mirror to the students. They show students a visualization of what they have been doing. The goal is to encourage reflection, to get students to realize when they’re spending too much time on one phase of their work, or maybe not enough (e.g., in testing). The challenge is mapping from the low-level user interactions to higher-level visualizations that might inform students.
There are several projects that are working with children who are programming in Scratch (which can be localized to Norwegian). The one that most captured my attention was where students were programming these beautiful robotic sculptures, created by professional artists. The team is exploring how this influences student motivation. How does motivation change when the robots under the students’ control are neither student-generated nor stereotypically “robotic”?
The Tiles project by Simone Mora, Francesco Gianni, and Monica Divitini aims to engage designers in ubiquitous computing. They have these cool cards that they use in an activity with designers to get them thinking about the kinds of everyday items in which computation might be embedded. They want designers to think about how sensors and actuators might be used to support user activity.
They’re now working to extend these cards with ties to JavaScript code that would actually allow designers to build the things that they designed. It’s an innovative activity to engage designers with embedded computing and then to carry the designs to prototype.
On the weekend after our visit, the chair of the department, Letizia Jaccheri, took Barb and I off to ski in Sweden in Åre. We arrived on a Thursday, spoke at IDIovation that night, met with ExcITED researchers on Friday, traveled to Sweden to ski on Saturday, back on Sunday, and flew home on Monday. An absolutely amazing trip for which we were both grateful to have had the opportunity!
A goal for teaching CS: Fostering Creativity Through Computing
Aman Yadav and Steve Cooper have the CACM Viewpoints Education column this month. They raise the questions of how learning computing can lead to greater creativity, and how we can design computing education experiences to draw students in to greater depth.
Computing has the potential to provide users opportunities to extend their creative expression to solve problems, create computational artifacts, and develop new knowledge. The pervasive nature of computing and accessibility of digital tools is also transforming K-12 education as students move from being mere consumers of content to engaging in the subject matter by creating computational artifacts. Take Scratch, for example, which is one of the many tools designed to teach kids to code, and comes with varying levels of support for educators implementing them in both formal and informal learning settings. Scratch provides students with an opportunity to express their creativity through stories, games, and animations. While Scratch has the potential to be a powerful tool, it is often used as little more than a presentation tool in the classroom. Studies of Scratch users show that few projects use variables or control flow data structures. While the Scratch environment provides a ‘low floor, high ceiling’ that allows beginners to dive into the environment without frustration, many students do not advance to a higher level. Tools like Scratch can empower students to showcase their creativity like never before; however, the way these tools are taught by teachers and used by students significantly influences whether students move along the creativity continuum. While Scratch is widely used, we know little about how it influences students’ creative thinking.
Source: Fostering Creativity Through Computing | February 2017 | Communications of the ACM
Introducing GP: A General Purpose Block Language
GP is a new blocks-based programming language being developed by John Maloney (most well-known for developing Scratch), Jens Mönig (developer of Snap!), and Yoshiki Ohshima (one of the developers of Squeak EToys) in Alan Kay’s group. They are all part of the new partnership between Alan Kay and Y-Combinator Research: HARC (Human Advancement Research Community). GP started in the SAP-funded CDG (Communications Design Group).
GP is not yet released, and there’s not much publicly available on it yet. The GP Team published a paper and poster in the Blocks and Beyond Workshop at last year’s VL/HCC on GP. The best introductory article on GP so-far is on the Scratch Wiki at MIT based on John’s presentation at the Scratch conference last year.
What makes GP remarkable is that it aims to be a general purpose language. John’s vision for GP is to be the language that students might move to after Scratch, with the highest possible ceilings. Think about GP as Python or Smalltalk in blocks — and even more the latter than the former. From the virtual machine (VM) on which it runs to the class browser, GP feels like a blocks-based form of Smalltalk. Because GP is VM-based, it’s portable — there are versions for Mac, Windows, iOS, and even a JavaScript implementation of the VM so that GP runs in the browser.
GP is an exploration of the question, “How far can we go with a blocks-based programming language? Do we have to move students to a textual programming language to let them develop everything from data analyses to real applications?”
GP users can do a lot with GP’s built-in blocks. However, as they grow in mastery, some users may wish to add new blocks to GP (e.g. to manipulate images), or even to extend the GP programming environment itself (e.g. by adding an image editor). GP is designed to be extended in itself using the same blocks language that users already know. However, unlike Smalltalk or Snap!, the GP language itself cannot be extended (e.g. to add a new control structure) without modifying the virtual machine. Keeping the GP language simple and fixed is intended to ease the learning path for beginners.
A brief tour of Smalltalk-like features of GP
When you first start up GP, it looks like Scratch. The blocks palette is different, because it’s covering a larger space of blocks. GP includes blocks for dealing with data (e.g., JSON, comma-separated values), media generation and manipulation, connections to the network and external devices, and the ability to create and coordinate multiple objects.
There are even blocks in there for manipulating pixels in an image and samples in a sound. GP is the first blocks-based language in which I’ve been able to do both sound and pixel Media Computation examples. I built the first version of MediaComp blocks for GP, then John figured out which ones were actually useful and then re-implemented them in GP much more efficiently than what I did.
I’m introducing GP here with the GP Team’s permission in order to show you a prototype ebook I’ve been building the last few months. You can play with GP at http://home.cc.gatech.edu/GPBlocks. This is the browser-based version which is offered with no guarantees — the browser version will likely change dramatically as GP is still being developed, and even the examples in the ebook may break over time. (Note: These browser-based examples are best viewed in Firefox on a desktop or laptop computer; they do not yet work on iOS or Android tablets.)
Here’s a brief series of snapshots to give you a sense of what makes GP so interesting and powerful compared to most other blocks-based languages. In the stage area (upper right-hand corner) right-click (control-click on a Mac) to bring up the stage menu.
The menu options for a workspace and to browse will elicit warm feelings of recognition for Smalltalk and Self programmers. Go ahead and click on the browse menu item.
Scanning the classes along the left hand side you realize that this is a full Smalltalk-like language. All the pieces are there and inspectable. The middle panes show the instance variables in the class (top) and the methods for the class (bottom). The rightmost pane shows the code for the method — in blocks!
One of the big goals of GP is that all of GP is written in GP. Even the lowest levels of GP (e.g., how bitmaps and blocks are constructed) can be manipulated in GP, all in blocks. Those methods are real code and “live.” Change them and you change how GP is working immediately. Right now, that’s super dangerous — there is no “editing” mode. Move a block out of place, and the method is changed at that moment. Beware of re-defining how Integers work! The GP team is currently working to complete this part of GP, allowing the GP programming system to be used to modify itself, like Smalltalk.
The GP team is also exploring the stages between blocks and text. At the top right hand corner of GP is a slider between blocks and text. Switch it to text, and all of GP is presented and usable in a textual form. (There’s even an interesting middle stage between blocks and text.)
I’ve been using GP for about nine months. During the Spring semester, I’ve been using GP with an undergraduate research assistant, David Tran, to build a prototype of a new kind of ebook structure. Play around (muck/MOHQ around) in the GPBlocks MOHQ, and in the next blog post, I’ll explain what it is and what we’re exploring in it.
My thanks to the GP team for review and comments on drafts of this post.
What’s the impact of the Hour of Code? It goes way beyond an Hour
Code.org has just released an interesting survey about their Hour of Code initiative. They’ve been criticized for providing only an hour and overly focusing on puzzles (see Mitchel Resnick’s article here). The results suggest that they’re reaching a diverse audience, and having an effect beyond an hour — students keep going, and teachers start teaching CS.
Programming is a literacy, and no one develops any kind of literacy in just an hour of practice. Games are not the most interesting and powerful kinds of programming activities.
But they’re a start. Particularly when we get past the Inverse Lake Wobegon Effect of thinking about students as being like us. We know from many studies that students are afraid of computer programming. I’m teaching Media Computation again this semester, and at least a third of the students who have come talk to me after class have started their conversation with, “I’m one of those people who just don’t do computers.” And that’s just those self-reporting without prompting! Students associate CS with being a geek and wouldn’t want to let their friends know they like computer science, even if they do. Few students get any kind of computer science education outside of Hour of Code.
When we think about most people, sustained activity in programming for one hour can go a long way to reducing fear, increasing self-efficacy, and nurturing interest. (Consider an Hour of Code compared to less than <5 minutes typically spent at a museum exhibit.) Games are a useful place to start because they’re well-structured. Aptitude-treatment interaction tells us that more structure is better with students who have less background in a subject. Open-ended, constructionist activities like those that Mitchel is promoting are more successful with more privileged students, those who have more experience which results in higher-ability students. The Hour of Code can help inspire students to get that additional experience needed to develop more ability.) An Hour of Code is a good first step for the remedial state of computing education in the United States today.
Hooray for Hour of Code, and thanks to Code.org for promoting it and for sharing these data.
The onus is on us to turn the Hour of Code into a Lifetime of Computational Literacy.
After the Hour of Code, we asked participating organizers how it went and got some fantastic news for our field.
- 98% had a good or great experience.
- 85% of those new to computer science said the Hour of Code increased their interest in teaching computer science.
- 49% said they plan to continue teaching computer science beyond one hour.
- 18% said they began teaching computer science after a previous Hour of Code campaign!
- 87% said their students did more than just one hour of coding.
ICER 2015 Report: Blocks win–Programming Language Design == UI Design
ICER 2015 at the University of Nebraska, Omaha was fantastic. Brian Dorn did a terrific job hosting all of us.
The Doctoral Consortium went really well. We had 20 students from US, Chile, Germany, and UK. Below is a picture from the “Up against the wall bubble sort” where experienced students went to one side, and newer students went to the other, and the former gave advice to the latter.
Georgia Tech had even more going on at ICER and RESPECT than I mentioned in my earlier blog posts (like here and here). The GVU Center did a nice write up about all of us here. The biggest thrill at ICER for the GT crowd was Briana Morrison receiving the Chairs Award (one of two best paper awards at ICER) for the paper that I blogged about here. Below is the whole GT contingent at ICER (including chair Brian Dorn, GT alum).
The other best paper award, the peoples’ choice John Henry Award, went to Kristin Searle and Yasmin Kafai (see paper here) about the e-textiles work with American Indians that I blogged about here. Kristin had so many interesting insights, like the boys in her project telling her that “I don’t own” the projects they made because they felt no ownership over the programming environment they were using.
The quality of the papers was very good (you can see the list of all of them here). My favorite paper from my review packet was presented Monday morning, Spatial Skills in Introductory Computer Programming. Steve Cooper and Sheryl Sorby with two undergraduates at Stanford did the study that I’ve been wanting to see for ages (see blog post where I talk about it). Training an experimental group in spatial skills improved performance over a control group. Surprisingly, SES and race differences disappeared in the experimental group! This is an important result.
But one session blew me away — it changed how I think about blocks programming.
- The first paper was from Thomas Price and Tiffany Barnes showing that students using blocks were able to achieve programming tasks faster than those using text, but with no difference in learning or attitudes afterwards (paper here). This was an interesting result, but it was a limited study (short intervention, no pre-test) so it mostly supported a finding from Chris Hundhausen from years previous that graphical, direct-manipulation languages lead to faster start-up than text languages (see paper here).
- David Weintrop presented his remarkable paper with Uri Wilensky (see paper here). Below is the graph that changed my thinking about blocks. David carefully developed an isomorphic test in blocks and text, and gave it to the same population. Students did much better on the blocks-based test. MODALITY MATTERS! Blocks and text are not equivalent. He did careful analyses at each level of the test. For example, David replicated the result that else clauses in text are really hard for novices (which I talked about here), but students perform much better in blocks-based if-else.
- Diana Franklin presented their paper describing fourth graders reading Scratch programs (see paper here). I was expecting a paper on program comprehension — it wasn’t. Instead, it was a paper about user interfaces, and how the user interface interfered or supported students exploring and coming to understand the program.
I came away from that three papers realizing that blocks programming is likely the best modality to use in elementary school programming, and perhaps even when starting to program in high school, and maybe even for end-user programmers. But even more important, I realized that Amy Ko’s comments about programming languages as being a powerful and unusable user interface (see her blog post here) is the critical insight about programming today. David showed us that blocks can dramatically increase readability of programs. Diana showed us that the user interface dramatically influences the readability of the blocks. At the novice programming level, blocks-based languages are the most promising direction today, and designing good blocks languages is as much a user interface design problem as it is a programming language design problem.
Do blocks equal “making” and text equal “coding”? Doing MediaComp in Blocks-Based Languages
Interesting perspective from a blogger in the Scratch community, liked below. I do frequently hear the pattern described in the post quoted below. “I’ve started by daughter/niece/local-school on Scratch, and now I want to know how to move them into something ‘real’ (e.g., text).” I typically point them to amazing things that can be done in Scratch (like Alex Ruthmann’s beautiful livecoding of music in Scratch).
I recently got a chance to play with GP, a new programming language from John Maloney (of Scratch fame), where all blocks and texts are isomorphic. There’s a slider that lets you switch from one to the other. Even the debugger and class browser show up with tiles. Where does that play out in this debate? GP is the first blocks-based language I’ve used with the right primitives to do MediaComp, so I built one of my examples in it. Took me about three times as much time to write and four times as much space (in screen real estate) as in Python (even with John looking over my shoulder guiding me). Maybe that’s not a bad thing — maybe that encourages a different style of use. Next time I try something like that, I’m far more likely to think about building my own blocks and using more abstraction to save on dragging-and-fitting effort.
I’ve been a part of the Scratch community for about 8 years now (yes, really). During this time, I’ve noticed a pattern that seems to apply to a lot of people:
join Scratch => create projects => discover text-based programming => quit Scratch because of “real programming”
Note the scare quotes around “real programming”. Generally, a “real” programming language is text-based (C, Python, etc.) and apparently qualifies as real because it’s used by well-known developers for something.
Obviously I disagree with disqualifying Scratch as a real programming language.
Blocks and Beyond Workshop at VL/HCC: Lessons and Directions for First Programming Environments
Thursday, October 22, 2015, Atlanta, GA
A satellite workshop of the 2015 IEEE Symposium Visual Languages and Human-Centric Computing (VL/HCC) https://sites.google.com/site/vlhcc2015
Scope and Goals
Blocks programming environments represent program syntax trees as compositions of visual blocks. This family of tools includes Scratch, Code.org’s Blockly lessons, App Inventor, Snap!, Pencil Code, Looking Glass, etc. They have introduced programming and computational thinking to tens of millions, reaching people of all ages and backgrounds.
Despite their popularity, there has been remarkably little research on the usability, effectiveness, and generalizability of affordances of these environments. The goal of this workshop is to begin to distill testable hypotheses from the existing folk knowledge of blocks environments and identify research questions and partnerships that can legitimize, or discount, pieces of this knowledge. It will bring together educators and researchers who work with blocks languages and members of the broader VL/HCC community interested in this area. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, the learning sciences, data analytics, usability, and more.
The workshop will be a generative discussion that sets the stage for future work and collaboration. It will include participant presentations and demonstrations that frame the discussion, followed by reflection on the state of the field and smaller working-group discussion and brainstorming sessions.
Suggested Topics for Discussion
- Who uses blocks programming environments and why?
- Which features of blocks environments help or hinder users? How do we know? Which of these features are worth incorporating into more traditional IDEs? What helpful features are missing?
- How can blocks environments and associated curricular materials be made more accessible to everyone, especially those with disabilities?
- Can blocks programming appeal to a wider range of interests (e.g., by allowing connections to different types of devices, web services, data sources, etc.)?
- What are the best ways to introduce programming to novices and to support their progression towards mastery? Do these approaches differ for for learners of computing basics and for makers?
- What are the conceptual and practical hurdles encountered by novice users of blocks languages when they face the transition to text languages and traditional programming communities? What can be done to reduce these hurdles?
- How can we best harness online communities to support growth through teaching, motivating, and providing inspiration and feedback?
- What roles should collaboration play in blocks programming? How can environments support that collaboration?
- In these environments, what data can be collected, and how can that data be analyzed to determine answers to questions like those above? How can we use data to answer larger scale questions about early experiences with programming?
- What are the lessons learned (both positive and negative) from creating first programming environments that can be shared with future environment designers?
Submission
We invite two kinds of submissions:
- A 1 to 3 page position statement describing an idea or research question related to the design, teaching, or study of blocks programming environments.
- A paper (up to 6 pages) describing previously unpublished results involving the design, study, or pedagogy of blocks programming environments.
All submissions must be made as PDF files to the Easy Chair Blocks and Beyond workshop submission site (https://easychair.org/conferences/?conf=blocksbeyond2015). Because this workshop will be discussion-based, rather than a mini-conference, the number of presentation/demonstration slots are limited. Authors for whom presentation or demonstration is essential should indicate this in their submission.
Important Dates
- 24 Jul. 2014: Submissions due.
- 14 Aug. 2015: Author notification.
- 4 Sep. 2015: Camera ready copies due.
- 22 Oct. 2015: Workshop in Atlanta.
Organizers
- Franklyn Turbak (chair), Wellesley College
- David Bau, Google
- Jeff Gray, University of Alabama
- Caitlin Kelleher, Washington University, St. Louis
- Josh Sheldon, MIT
Program Committee
- Neil Brown, University of Kent
- Dave Culyba, Carnegie Mellon University
- Sayamindu Dasgupta, MIT
- Deborah Fields, Utah State University
- Neil Fraser, Google
- Mark Friedman, Google
- Dan Garcia, University of California, Berkeley
- Benjamin Mako Hill, University of Washington
- Fred Martin, University of Massachusetts Lowell
- Paul Medlock-Walton, MIT
- Yoshiaki Matsuzawa, Aoyama Gakuin University
- Amon Millner, Olin College
- Ralph Morelli, Trinity College
- Brook Osborne, Code.org
- Jonathan Protzenko, Microsoft Research
- Ben Shapiro, Tufts University
- Wolfgang Slany, Graz University of Technology
- Daniel Wendel, MIT
Programming with Pseudocode, Keeping Student Interest, the Need for School, and International Curricula: Trip Report on WiPSCE 2014
First week of this month, Barb and I went to Berlin for WiPSCE 2014 conference. See the program here and the proceedings here, and the post on my keynote here. Let me tell you about some of the interesting things I heard there.
We heard about so many international CS curricula efforts. Tim Bell talked about different levels of programming activity going on in different curricula (all the images in this blog post are from me snapping pictures of presentations).
We heard about Austrian efforts, Flemish efforts, and programs I was aware of in the UK, New Zealand, Germany, Israel, and the United States. I had not previously hear much about Poland in CS Ed, but they’ve been including computing in their curriculum for a long time.
Quintin Cutts (Code or (not Code) – Separating Formal and Natural Language in CS Education) talked about a problem that they’re having in Scotland that we’re also facing in the US with the CS Principles effort. There are several different programming languages in use in schools. Nobody wants to be the bad guy to say “You have to use X (maybe Scratch? Alice? App Inventor? Python?), because that’s what the national test will be in.” So, national test-developers are creating pseudocode languages that aim to be understandable without getting hung up on syntax. Scotland has one that’s made up of bits and pieces of other languages (which they call “Haggis” — seriously!). The problem is that if a piece of code is never expected to run, it can have assumptions within it that would have to be cleared up to build a runtime system. Quintin showed how even simple examples of the pseudocode from their national test have all kinds of logical inconsistencies.
It’s a real problem. Allison Elliott Tew’s dissertation (see here for post) showed that weakest performing students had the worst time transferring their knowledge from whatever language they learned to a pseudo-code. That means that your top students are going to be fine with a pseudo-code test, but your bottom students are not going to do well at all — they won’t know all the concepts, and they’re going to trip over the language. A pseudo-code test is going to be another barrier to underprepared students getting into CS.
Now, once you get them in the door, how do you keep them there? One interesting paper (Scratch vs. Karel – Impact on Learning Outcomes and Motivation) compared student interest in using Scratch or Karol the Robot. Scratch is a blocks-based language, and Karol was programmed in a text-based language. Students liked Scratch and performed better with it, but felt that Karol was more “real-life” and thus was more motivating for doing more in CS later. Betsy DiSalvo found similar results with her Glitch students. When comparing Alice and Python, students liked what they could produce with Alice, but felt that Python was more like what real programmers did and was consequently more motivating for some students. This paper has had me thinking, “Maybe we should bring Logo back?” It’s text-based like Karol, designed for students, and we have LOTS of books and other materials available for Logo across the curriculum.
Leigh Ann DeLyser talked about her work with CS NYC (Software Engineering Students in the City). It’s a remarkable program: 1900 students applied for 120 slots, and the selection among the qualified students was by lottery. They did pre and post surveys around the first year of the program, with questions like “Would you like to study CS or SE after this semester?” or “Want to be a computer scientist or software engineer one day?” Females lost much more interest in a future computing career then males.
Finally, the talk that has most been in my thoughts since the conference was by Debby Fields and Yasmin Kafai on their Scratch study (Programming in the Wild: Patterns of Computational Participation in the Scratch Online Social Networking Forum). They studied 5000 visitors to the Scratch website in the first quarter of 2012. First big finding — most of them don’t do much. 55% visit but don’t do anything. The other 45% engage at a variety of levels, and the levels are pretty much gender-balanced. The most active participants are about evenly split male-female.
Debbie and Yasmin defined four “classes” of programming activity based on the programs that these users uploaded to the Scratch website. Booleans are a big differentiator, as are variables and random numbers. The below figure describes how much of each kind of programming block appears in each class of programs, and what percentage of programs they saw land in each class.
Here’s the disappointing part: The highest level of programming activity was almost all boys. Girls don’t go much beyond the simplest programming.
Now, we don’t know much about ages or where these students are or their ethnic group. As Debby pointed out, age and location are self-reported on the Scratch website, and it’s remarkable how many 100 year old Scratch programmers there are in Antartica. Their data suggest that informal education activities like Scratch (or Kahn Academy or MOOCs) are unlikely to reach a broad range of users. Debby pointed out that what students are building influences what students do. If Scratch programmers can tell stories without booleans, how do you motivate more advanced programming actvities if they’re only story-telling? If we want to reach more diverse students, and we want to encourage more kinds of activities, we need school. We need formal education to reach everyone.
Educational Technology as Imperialism: Finding a middle ground between Papert and Freire
Audrey Watters is an insightful writer who tackles hard issues in educational technology. I’ve cited her work before in this blog. The post linked below made me realize that I need to read more by Paulo Freire and Paulo Blikstein, and how important it is to avoid, “The latest in a long line of educational salvations that the Global North has imposed on the Global South.”
I deeply appreciate Freire’s emphasis on “school,” which Audrey emphasizes. The need for school can also be seen in the research findings of Yasmin Kafai and Deborah Fields (who found that kids who discover tools like Scratch tend to be even more privileged than those in undergrad CS classes) and Betsy DiSalvo (who found that immigrant families don’t even know what words to search for in order to find learning resources). Open education efforts alone are unlikely to reach the underprivileged students who most need the resources. We need school in order to reach everyone.
It isn’t simply that an XPRIZE would likely offer an imperialist curriculum — that it’s in English is only part of the problem here. What does it mean to teach “O is for Octopus” in Sub-Saharan Africa, for example? It’s that all of this will be delivered on an Android tablet, and with that comes a host of other technological imperialist overtures — telecommunications companies offering hardware and software and banking and schooling; Google’s special brand of data-mining; and more broadly the tech sector’s penchant for surveillance, for starters.What is the goal of the Global Learning XPRIZE when it comes to learning? Is it for children in the developing world to join the global economy, for example? If so how? On whose terms? To what end? In what role? Why? How? Under whose Terms of Service?
Moving from Scratch to text: Why We Need Sniff
I’m intrigued by this project and would really love to see some analysis. Do students who use Scratch recognize Sniff as being a text form of Scratch? If it doesn’t work well, is the problem in the syntax and semantics of Sniff, and maybe we could do better? Do students transfer their knowledge of Scratch into Sniff?
So if Scratch is so great why do we need Sniff? The problem is that at some point you need to move beyond Scratch. It could be that you want to tackle a different kind of problem that Scratch can’t handle well. Perhaps you’ve realised that graphical programming is a nice idea, and great way to start, but in practise its clumsy. Clicking and dragging blocks is a tedious and slow way to build large programs. It could be you need something that feels “more grown up” – the cat sprite/logo is cute, and even older children will find it fun for a while, but Scratch is designed to look and feel like a toy even though its actually very powerful. For whatever reason at some point you start to look for something “better”.
Computing Ed Research - Guzdial's Take 
Recent Comments