Posts tagged ‘programming languages’
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.
Since states are making computing courses count as foreign language courses (even if that’s a bad idea), it’s worthwhile to consider what the value is of learning a foreign language. A recent Freakonomics podcast (linked below) considers the return on investment of learning a foreign language. Most intriguing is that people problem-solve differently in their non-native languages. I wonder what the implications are for programming languages? We know that people have negative transfer when their native language abilities conflict with their programming language problem-solving. Are there ways we could make the programming language better for problem-solving?
Learning a language is of course not just about making money — and you’ll hear about the other benefits. Research shows that being bilingual improves executive function and memory in kids, and may stall the onset of Alzheimer’s disease.
And as we learn from Boaz Keysar, a professor of psychology at the University of Chicago, thinking in a foreign language can affect decision-making, too — for better or worse.
Bertrand Meyer is making a similar point to Andy Ko’s argument about programming languages. Programming does matter, and the language we use also matters. Meyer’s goes on to suggest that those saying that “code doesn’t matter” may be just rationalizing that they continue to live with antiquated languages. It can’t be that the peak of human-computer programming interfaces was reached back in New Jersey in the 1970’s.
Often, you will be told that programming languages do not matter much. What actually matters more is not clear; maybe tools, maybe methodology, maybe process. It is a pretty general rule that people arguing that language does not matter are simply trying to justify their use of bad languages.