Posts tagged ‘programming languages’
Summarizing the Research on Designing Programming Languages to be Easier to Learn: NSF CS Ed Community Meeting
I’m at the NSF STEM+Computing and Broadening Participation in Computing Community Meeting. At our ECEP meeting on Saturday, we heard from White House Champion of Change Jane Margolis. She did a great job of getting our states to think about how to change their state plans to emphasize diversity and equity — more on that in a future blog post.
I moderated a panel yesterday on how to integrate computing education into schools of education. Here’s the description of the session — again, more later on this.
Integrating Computing Education into Preservice Teacher Development Programs
(Mark Guzdial (moderator), Leigh Ann DeLyser, Joanna Goode, Yasmin Kafai, Aman Yadav)For computing education to become ubiquitous and sustainable in US K-12 schools, we need schools of Education to teach computing.
- What should we be teaching to preservice teachers?
- Where should we teach CS methods in preservice teacherdevelopment?
- How do we help schools of Ed to hire and sustain faculty who focus on computing education?Panelists will talk about how CS Ed is being integrated into their preservice teacher development programs, and about alternative models for addressing these questions.
Yesterday, our other computing education research Champion of Change, Andreas Stefik presented a summary of the empirical evidence on how to design programming languages to make them easier to learn. Follow the link below to get to the two-page PDF pamphlet he produced for his presentation — it’s dense with information and fascinating.
This pamphlet is designed to provide an overview of recent evidence on human factors evidence in programming language design. In some cases, our intent is to dispel myths. In others, it is to provide the result of research lines.
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 Andy Ko’s comments about programming languages as being a powerful and unusable user interface (see his 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.
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
I’m leaving May 24 for a two week trip to Germany. Both one week parts are interesting and worth talking about here. I’ve been reflecting on my own thinking on the piece between, and how it relates to computing education themes, too.
I’m attending a seminar at Schloss Dagstuhl on Human-Centric Development of Software Tools (see seminar page here). Two of the seminar leaders are Shriram Krishnamurthi of Bootstrap fame who is a frequent visitor and even a guest blogger here (see post here) and Andy Ko whose seminal work with Michael Lee on Gidget has been mentioned here several times (for example here). I’ve only been to Dagstuhl once before at the live-coding seminar (see description here) which was fantastic and has influenced my thinking literally years later. The seminar next week has me in the relative-outsider role that I was at the live-coding seminar. Most of the researchers coming to this event are programming language and software engineering researchers. Only a handful of us are social scientists or education researchers.
The Dagstuhl seminar ends Thursday after lunch. Saturday night, I’m to meet up with a group in Oldenburg Germany and then head up Sunday to Stadland (near the North Sea) for a workshop where I will be advising STEM Education PhD students. I don’t have a web link to the workshop, but I do have a page about the program I’ll be participating in — see here. My only contact there is Ira Diethelm, whom I’ve met several times and saw most recently at WIPSCE 2014 in Berlin (see trip report here). I really don’t know what to expect. Through the ICER DC and WIPSCE, I’ve been impressed by the Computing Education PhD students I’ve met in Germany, so I look forward to an interesting time. I come back home on Friday June 5 from Bremen.
There’s a couple day gap between the two events, from Thursday noon to Saturday evening. I got a bunch of advice on what to do on holiday. Shriram gave me the excellent advice of taking a boat cruise partway north, stopping at cities along the way, and then finishing up with a train on Saturday. Others suggested that I go to Cologne, Bremen, Luxembourg, or even Brussels.
I’ve decided to take a taxi to Trier from Dagstuhl, tour around there for a couple days, then take a seven hour train ride north on Saturday. Trier looks really interesting (see Tripadvisor page), though probably not as cool as a boat ride.
Why did I take the safer route?
The science writer, Kayt Sukel, was a once student of mine at Georgia Tech — we even have a pub together. I am so pleased to see the attention she’s received for her book Dirty Minds/This is Your Brain on Sex. She has a new book coming out on risk, and that’s had me thinking more about the role of risk in computing education.
In my research group, we often refer to Eccles model of academic achievement and decision making (1983), pictured below. It describes how students’ academic decisions consider issues like gender roles and stereotypes (e.g., do people who are like me do this?), expectation for success (e.g., can I succeed at this?), and the utility function (e.g., will this academic choice be fun? useful? money-making?). It’s a powerful model for thinking about why women and under-represented minorities don’t take computer science.
Eccles’ model doesn’t say much about risk. What happens if I don’t succeed? What do I need to do to reduce risk? How will I manage if I fail? How much am I willing to suffer/pay for reduced risk?
That’s certainly playing into my thinking about my in-between days in Germany. I don’t speak German. If I get into trouble in those in-between days, I know nobody I could call for help. I still have another week of a workshop with a keynote presentation after my couple days break. I’ve already booked a hotel in Trier. I plan on walking around and taking pictures, and then I will take a train (which I’ve already booked, with Shriram’s help) to Oldenburg on Saturday. A boat ride with hops into cities sounds terrific, but more difficult to plan with many more opportunities for error (e.g., lost luggage, pickpockets). That’s managing risk for me.
I hear issues of risk coming into students’ decision-making processes all the time, combined with the other factors included in Eccles’ model. My daughter is pursuing pre-med studies. She’s thinking like many other pre-med students, “What undergrad degree do I get now that will be useful even if I don’t get into med school?” She tried computer science for one semester, as Jeanette Wing recommended in her famous article on Computational Thinking: “One can major in computer science and go on to a career in medicine, law, business, politics, any type of science or engineering, and even the arts.” CS would clearly be a good fallback undergraduate degree. She was well-prepared for CS — she had passed the AP CS exam in high school, and was top of her engineering CS1 in MATLAB class. After one semester in CS for CS majors, my daughter hated it, especially the intense focus on enforced software development practices (e.g., losing points on homework for indenting with tabs rather than spaces) and the arrogant undergraduate teaching assistants. (She used more descriptive language.) Her class was particularly unfriendly to women and members of under-represented groups (a story I told here). She now rejects the CS classroom culture, the “defensive climate” (re: Barker and Garvin-Doxas). She never wants to take another CS course. The value of a CS degree in reducing risks on a pre-med path does not outweigh the costs of CS classes for her. She’s now pursuing psychology, which has a different risk/benefit calculation (i.e., a psychology undergraduate degree is not as valuable in the marketplace as a CS undergraduate degree), but has reduced costs compared to CS or biology.
Risk is certainly a factor when students are considering computer science. Students have expectations about potential costs, potential benefits, and about what could go wrong. I read it in my students’ comments after the Media Computation course. “The course was not what I expected! I was expecting it to be much harder.” “I took a light load this semester so that I’d be ready for this.” Sometimes, I’m quite sure, the risk calculation comes out against us, and we never see those students.
The blog will keep going while I’m gone — we’re queued up for weeks. I may not be able to respond much to comments in the meantime, though.
C is Manly, Python is for “n00bs”: Our perception of programming languages is influenced by our gender expectations
Surprising and interesting empirical evidence that language use is mostly gender-neutral. Our expectations about gender influence how we think about programming languages. These perceptions help explain the prevalence of C and C++ in many undergraduate computing programs.
There is also a gendered perception of language hierarchy with the most “manly” at the top. One Slashdot commenter writes, “Bah, Python is for girls anyways. Everybody knows that PERL is the language of true men.” Someone else responds, “Actually, C is the language of true men…” Such views suggest that women might disproportionately use certain languages, but Ari and Leo found in their programmer surveys that knowledge of programming languages is largely equivalent between genders. Women are slightly more likely to know Excel and men are slightly more likely to know C, C#, and Ruby, but not enough to establish any gendered hierarchy.
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”.
The ITICSE’14 paper referenced below is getting discussed a good bit in the CS Education community. Is it really the case that enhancing error messages doesn’t help students?
Yes, if you do an ineffective job of enhancing the error messages. I’m disappointed that the paper doesn’t even consider the prior work on how to enhance error messages in a useful way — and more importantly, what has been established as a better process. To start, the best paper award at SIGCSE’11 was on an empirical process for analyzing the effectiveness of error messages and a rubric for understanding student problems with them — a paper that isn’t even referenced in the ITICSE paper, let alone applying the rubric. That work and the work of Lewis Johnson in Proust point to the importance of bringing more knowledge to bear in creating useful error messages–by studying student intentionality, by figuring out what information they need to be successful. Andy Ko got it right when he said “Programming languages are the least usable, but most powerful human-computer interfaces ever invented.” We make them more usable by doing careful empirical work, not just tossing a bunch of data into a machine learning clustering algorithm.
I worry that titles like “Enhancing syntax error messages appears ineffectual” can stifle useful research. I already spoke to one researcher working on error messages who asked if new work is even useful, given this result. The result just comes from a bad job at enhancing error messages. Perhaps a better title would have been “An approach to enhancing syntax error messages that isn’t effective.”
Debugging is an important skill for novice programmers to acquire. Error messages help novices to locate and correct errors, but compiler messages are frequently inadequate. We have developed a system that provides enhanced error messages, including concrete examples that illustrate the kind of error that has occurred and how that kind of error could be corrected. We evaluate the effectiveness of the enhanced error messages with a controlled empirical study and find no significant effect.