Posts tagged ‘Scratch’
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.
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?
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.
- 24 Jul. 2014: Submissions due.
- 14 Aug. 2015: Author notification.
- 4 Sep. 2015: Camera ready copies due.
- 22 Oct. 2015: Workshop in Atlanta.
- Franklyn Turbak (chair), Wellesley College
- David Bau, Google
- Jeff Gray, University of Alabama
- Caitlin Kelleher, Washington University, St. Louis
- Josh Sheldon, MIT
- 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.
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?
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”.
Pretty exciting new direction for Scratch! I’m really curious about the research that’s going to come out using ScratchJr. What can students learn to do with ScratchJr, and what’s the distribution (e.g., all kids learn X, but only 10% reach Y)? What do students transfer forward from learning ScratchJr?
ScratchJr is an introductory programming language that enables young children ages 5-7 to create their own interactive stories and games. Children snap together graphical programming blocks to make characters move, jump, dance, and sing. Children can modify characters in the paint editor, add their own voices and sounds, even insert photos of themselves — then use the programming blocks to make their characters come to life.ScratchJr was inspired by the popular Scratch programming language http://scratch.mit.edu, used by millions of young people ages 8 and up around the world. In creating ScratchJr, we redesigned the interface and programming language to make them developmentally appropriate for younger children, carefully designing features to match young children’s cognitive, personal, social, and emotional development.ScratchJr is now available as a free iPad app. We expect to release an Android version later in 2014 and a web-based version in 2015.
via ScratchJr – About.
Philip Guo did an analysis of what top CS departments teach in their introductory courses (see link below) and found that Python now tops Java. MATLAB tops C and C++ (though not if these are combined), and Scheme and Scratch are near the bottom.
It’s reasonable to say that an AP will only succeed (e.g., students will take it) if they can get credit or placement for the exam in college or university. Typically, colleges and universities give credit for courses that are currently taught. Will we see colleges and universities start teaching CS Principles? Will they give credit for a course that they don’t teach? For languages they don’t teach? Maybe we’ll see more of an influx of CSP languages and courses into colleges and universities. I predict that we won’t.
Scratch is the only visual, blocks-based language that made this list. It’s one of the most popular languages of this genre, which include related projects such as Alice, App Inventor, Etoys, Kodu, StarLogo, and TouchDevelop. The creators of these sorts of languages focus mostly on K-12 education, which might explain why they haven’t gotten as much adoption at the university level.