Posts filed under ‘Uncategorized’

An Ebook for Java AP CS Review: Guest Blog Post from Barbara Ericson

My research partner, co-author, and wife, Barbara Ericson, has been building an ebook (like the ones we’ve been making for AP CSP, as mentioned here and here) for students studying Advanced Placement (AP) CS Level A. We wanted to write a blog post about it, to help more AP CS A students and teachers find it. She kindly wrote this blog post on the ebooks

I started creating a free interactive ebook for the Advanced Placement (AP) Computer Science (CS) A course in 2014.  See http://tinyurl.com/JavaReview-new. The AP CSA course is intended to be equivalent to a first course for computer science majors at the college level.  It covers programming fundamentals (variables, strings, conditionals, loops), one and two dimensional arrays, lists, recursion, searching, sorting, and object-oriented programming in Java.

The AP CSA ebook was originally intended to be used as a review for the AP CSA exam.  I had created a web-site that thousands of students were using to take practice multiple-choice exams, but that web-site couldn’t handle the load and kept crashing.  Our team at Georgia Tech was creating a free interactive ebook for Advanced Placement Computer Science Principles (CSP) course on the Runestone platform. The Runestone platform was easily handling thousands of learners per day, so I moved the multiple choice questions into a new interactive ebook for AP CSA.  I also added a short description of each topic on the AP CSA exam and several practice exams.

Over the years, my team of undergraduate and high school students and I have added more content to the Java Review ebook and thousands of learners have used it.  It includes text, pictures, videos, executable and modifiable Java code, multiple-choice questions, fill-in-the-blank problems, mixed-up code problems (Parsons problems), clickable area problems, short answer questions, drag and drop questions, timed exams, and links to other practice sites such as CodingBat (https://codingbat.com/java) and the Java Tutor (http://pythontutor.com/java.html#mode=edit). It also includes free response (write code) questions from past exams.

Fill-in-the-blank problems ask a user to type in the answer to a question and the answer is checked against a regular expression. See https://tinyurl.com/fillInBlankEx.   Mixed-up code problems (Parsons problems) provide the correct code to solve a problem, but the code is broken into code blocks and mixed up.  The learner must drag the blocks into the correct order. See https://tinyurl.com/ParsonsEx.  I studied Parsons problems for my dissertation and invented two types of adaptation to modify the difficulty of Parsons problems to keep learners challenged, but not frustrated.  Clickable area questions ask learners to click on either lines of code or table elements to answer a question. See https://tinyurl.com/clickableEx.   Short answer questions allow users to type in text in response to a question.  See https://tinyurl.com/shortAnsEx. Drag and drop questions allow the learner to drag a definition to a concept.  See https://tinyurl.com/y68cxmpw.  Timed exams give the learner practice a set amount of time to finish an exam.  It shows the questions in the exam one at a time and doesn’t give the learner feedback about the correctness of the answer until after the exam.  See https://tinyurl.com/timedEx.

I am currently analyzing the log file data from both the AP CSA and CSP ebooks.  Learners typically attempt to answer the practice type questions, but don’t always run the example code or watch the videos.  In an observation study I ran as part of my dissertation work, teachers said that they didn’t run the code if the got the related practice question correct. They also didn’t always watch the videos, especially if the video content was also in the text.  Usage of the ebook tends to drop from the first chapter to the last instructional chapter, but increases again in the practice exam chapters at the end of the ebook. Usage also drops across the instructional material in a chapter and then increases again in the practice item subchapters near the end of each chapter.

Beryl Hoffman, an Associate Professor of Computer Science at Elms College and a member of the Mobile CSP team, has been creating a new AP CSA ebook based on my AP CSA ebook, but revised to match the changes to the AP CSA course for 2019-20202.  See https://tinyurl.com/csawesome.  One of the reasons for creating this new ebook is to help Mobile CSP teaches prepare to teach CSA.  The Mobile CSP team is piloting this book currently with CSP teachers.

June 17, 2019 at 7:00 am Leave a comment

Blocks and Beyond 2019 and SnapCon19 Call for Papers

#SnapCon19, the first Snap Conference, will be held September 22-25, 2019, in Heidelberg, Germany.  Register by June 24 at this website.


Blocks and Beyond 2019: Beyond Blocks 

VL/HCC workshop in Memphis, TN, USAFri Oct 18, 2019
http://cs.wellesley.edu/blocks-and-beyond

Scope and Goals

Blocks programming has become increasingly popular in programming environments targeted at beginner programmers, end users, and casual programmers. Capitalizing on the energy and enthusiasm from the first two Blocks and Beyond workshops, we are pleased to announce the 2019 Blocks and Beyond workshop.

Since blocks are only a small step towards leveraging visual languages and notations for specifying and understanding computation, the emphasis of the 2019 workshop is on the Beyond aspect of Blocks & Beyond: what kinds of visual notations and programming environment scaffolding facilitate: Understanding program semantics? Learning computational concepts? Developing computational identity and fostering computational participation and computational action?

The goal of this workshop is to bring together language designers, educators, researchers, and members of the broader VL/HCC community to answer these questions. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, human factors, the learning sciences, and learning analytics.

This workshop will engage participants to (1) discuss the state of the art of visual languages targeted at beginners, end users, and casual programmers; (2) assess the usability and effectiveness of these languages and their associated pedagogies; and (3) brainstorm about future directions for these languages.

Suggested Topics for Discussion

  • In what ways have blocks languages succeeded or failed at fulfilling the promise of visual languages to enhance the ability of humans to express computation?
  • How can visual languages and environments better support dynamic semantics and pragmatics, particularly with features for liveness, debugging, and understanding the dynamic execution of programs?
  • How usable and effective are visual environments for teaching computational thinking and programming? For democratizing programming and enabling computational participation and computational action? How do we know?
  • In what ways does visual programming help or hinder those who use them as a stepping stone to traditional text-based languages? What are good ways to support the transition between visual languages and text-based languages? How important is this?
  • How does the two-dimensional nature of visual language workspaces affect the way people create, modify, navigate, and search through their code?
  • What tools are there for creating new visual languages, especially domain-specific ones?
  • What are effective mechanisms for multiple people to collaborate on a visual programming when they (1) are co-located or (2) are working together remotely?
  • What are effective pedagogical strategies to use with visual languages, both in traditional classroom settings and in informal and open-ended learning environments?
  • What are the most effective ways to provide help to visual programmers, especially in settings outside the classroom?
  • How can visual environments and associated curricular materials be made more accessible to everyone, especially those with visual and motor impairments and underrepresented populations in computing?
  • What lessons from the visual programming community are worth sharing with other language designers? Are there features of visual languages that should be incorporated into IDEs for traditional programming environments? What features of modern IDEs are lacking in visual languages?
  • How can online communities associated with these environments be leveraged to support users? Are these online communities inclusive and how can they be more inclusive?
  • For 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 such data to answer larger scale questions about early experiences with programming?

Submission

We invite three kinds of paper submissions to spark discussion at the workshop:

  • A 2 to 3 page position statement describing an idea, research question, or work in progress related to the design, teaching, or study of visual programming environments.
  • short paper (up to 4 pages, excluding references and/or acknowledgments) describing previously unpublished results involving the design, study, or pedagogy of visual programming.
  • long paper (up to 8 pages, excluding references and/or acknowledgments), with the same goals and content requirements of the short paper, but with a more substantial contribution.

To maximize discussion time at the workshop, paper presentation times will be very short.

All workshop participants (whether or not they have an accepted paper) are encouraged to present a demo and/or poster of their work during the workshop. Anyone wishing to present a demo/poster should submit a 1 to 2 paragraph abstract. There is also an option to submit a 1 to 2 page demo/poster summary document that will appear in the proceedings.

Submission details for papers and demo/poster abstracts and summary documents can be found at the workshop website:  http://cs.wellesley.edu/blocks-and-beyond

As with the first two Blocks and Beyond workshops, we are applying to publish the proceedings of this workshop with the IEEE.

Important Dates

  • Fri 12 Jul 2019: Paper submissions due (due by end of day, anytime on Earth)
  • Fri 09 Aug 2019: Author notification
  • Fri 16 Aug — Fri 20 Sep 2019: Rolling demo/poster abstract submissions
  • Fri 16 Aug — Fri 25 Oct 2019: Rolling demo/poster summary document submissions
  • Mon 09 Sep 2019: Camera ready paper submissions and copyright forms due
  • Fri 13 Sep 2019: Early registration for VL/HCC and B&B ends
  • Fri 18 Oct 2019: Workshop in Memphis
  • Fri 01 Nov 2019: Camera-ready demo/poster summary documents and copyright forms due

 

June 12, 2019 at 7:00 am Leave a comment

Computer Science Teachers as Provocateurs: All learning starts from a problem

One of the surprising benefits of working with social science educators (history and economics) has been new perspectives on my own teaching. I’ve studied education for several years, and have worked with science and mathematics education researchers in the past. It hadn’t occurred to me that history education is so different that it would give me a new way of looking at my own teaching.

Last week, I was in a research meeting with Bob Bain, a history and education professor here at U. Michigan. He was describing how historians understand knowledge and what historian’s practice looks like, and how that should be reflected in the history classroom.

He said that all learning in history starts from a problem. That gave me pause. What’s a “problem” in history?

Bob explained that he defines problem as John Dewey did, as something that disturbs the equilibrium. “Activities at the Dewey School arose from the child’s own interests and from the need to solve problems that aroused the child’s curiosity and that led to creative solutions.” We don’t think until our environment is disturbed, but that environment may just be in your own head.

We each have our own stories that we use to explain the world, and these make up our own personal equilibria. Maybe students have always been told that the American Civil War was about states’ rights, and then they read the Georgia Declaration of Secession. Maybe they’ve thought of Columbus as the explorer who discovered America, and then note that he wasn’t celebrated until 1792, 300 years after his arrival. Why wasn’t he celebrated earlier, and why him and at that time? A good history teacher sets up these conflicts, disequilibria, or problems. Bob says it can be easy enough to create, simply by showing two contrasting accounts of the same historical event.

Research in the learning sciences supports this definition of learning. Roger Schank talked about the importance of learning through “expectation failure.” You learn when you realize that you don’t know something:

The understanding cycle – expectation failure – explanation – reminding – generalization – is a natural one. No one teaches it to us. We are not taught to have goals, nor to attempt to develop plans to achieve those goals by adapting old plans from similar situations. We need not be taught this because the process is so basic to what comprises intelligence. Learning is a natural act.

In progressive education, we’re told that the teacher should be a “Guide on the Side, not the Sage on the Stage.” When Janet Kolodner was developing Learning By Design, she talked about the role of teacher as coach and orchestrator. Those were roles I was familiar with. Bob was describing a different role.

I challenged him explicitly, “You’re a provocateur. You create the problems in the students’ minds.” He agreed.

Bob got me thinking about the role of the teacher in the computer science class. We can sometimes be a guide, a coach, and orchestrator — when students are working away on some problem or project. But sometimes, we have to be the provocateur.

We should always start from a problem. In science education, this is easy. Kids naturally do wonder why the sky is blue, why sunsets are more red, why heat travels along metal but not wood, and why stars twinkle. In more advanced computer science, we can also start from questions that students’ already have. I’m taking a MOOC right now because it explains things I’ve wondered about.

But in introductory classes, students already use a computer without problems. They may not see enough of real computing to wonder about how it works. The teacher has to generate a problem, inculcate curiosity — be a provocateur.

We should only teach something when it solves a problem for the student. A lecture on variables and types should be motivated by a problem that the variables and types solve. A lecture on loops should happen when students need to do something so often that copy-pasting the code repeatedly won’t work. Saying “You’re going to need this later” is not motivation enough — that doesn’t match the cycle that Schank described as natural. Nobody remembers things they will need in the future. Learning results when you need new knowledge to resolve the current problem, disequilibria, or conflict.

Note: Computer science doesn’t teach problem-solving. Dewey’s and Schank’s point is that problem-solving is a natural way in which people learn. Learning to program still doesn’t teach problem-solving skills.

June 10, 2019 at 7:00 am 1 comment

The gender imbalance in AI is greater than in CS overall, and that’s a big problem

My colleague, Rada Mihalcea, sent me a copy of a new (April 2019) report from the AI Now Institute on Discriminating Systems: Gender, Race, and Power in AI (see link here) which describes the diversity crisis in AI:

There is a diversity crisis in the AI sector across gender and race. Recent studies found only 18% of authors at leading AI conferences are women, and more than 80% of AI professors are men. This disparity is extreme in the AI industry: women comprise only 15% of AI research staff at Facebook and 10% at Google. There is no public data on trans workers or other gender minorities. For black workers, the picture is even worse. For example, only 2.5% of Google’s workforce is black, while Facebook and Microsoft are each at 4%. Given decades of concern and investment to redress this imbalance, the current state of the field is alarming.

Without a doubt, those percentages do not match the distribution of gender and ethnicity in the population at large. But we already know that participation in CS does not match the population. How do the AI distributions match the distribution of gender and ethnicity among CS researchers?

A sample to compare to is the latest graduates with CS PhDs. Take a look at the 2018 Taulbee Survey from the CRA (see link here).  19.3% of CS PhD’s went to women. That’s terrible gender diversity when compared to the population, and AI  (at 10%, 15%, or 18%) is doing worse. Only 1.4% of new CS PhD’s were Black. From an ethnicity perspective, Google, Facebook, and Microsoft are doing surprisingly well.

The AI Now Institute report is concerned about intersectionality. “The overwhelming focus on ‘women in tech’ is too narrow and likely to privilege white women over others.” I heard this concern at the recent NCWIT Summit (see link here).  The issues of women are not identical across ethnicities. The other direction of intersectionality is also a concern. My student, Amber Solomon, has published on how interventions for Black students in CS often focus on Black males: Not Just Black and Not Just a Woman: Black Women Belonging in Computing (see link here).

I had not seen previously a report on diversity in just one part of CS, and I’m glad to see it. AI (and particularly the sub-field of machine learning) is growing in importance. We know that having more diversity in the design team makes it more likely that a broader range of issues are considered in the design process. We also know that biased AI technologies are already being developed and deployed (see the Algorithmic Justice League). A new Brookings Institute Report identifies many of the biases and suggests ways of avoiding them (see report here). AI is one of the sub-fields of computer science where developing greater diversity is particularly important.

 

June 3, 2019 at 7:00 am 1 comment

Come hang out with Wil and me to talk about new research ideas! ACM ICER 2019 Work in Progress Workshop

Wil Doane and I are co-hosting the ACM ICER 2019 Work in Progress workshop that Colleen Lewis introduced at ICER 2014 in Glasgow (my report on participating). Colleen and I co-hosted last year.

It really is a “hosting” job more than an “organizing” or “presenting” role.  I love Colleen’s informal description of WiP, “You’re borrowing 4 other smart people’s brains for an hour. Then you loan them yours.”  The participants do the presenting. For one hour, your group listens to your idea and helps you think through it, and then you pass the baton. The whole organizing task is “Let’s put these 4 people together, and those 4 people together, and so on. We give them 4 hours, and appropriate coffee/lunch breaks.” (Where the value “4” may be replaced with “5” or “6”.)

Another useful description of WiP is “doctoral consortia for after-graduation.”  Doctoral consortia are these great opportunities to share your research ideas and get feedback on them.  Then there’s this sense that you graduate and…not have those ideas anymore? Or don’t need to share them or get feedback on them?  I’ve expressed concern previously about the challenges of learning when you’re no longer seen as a learner. Of course, PhD graduates are supposed to have new research ideas, which go into proposals and papers. But how do you develop ideas when you’re at the early stages, when they’re not ready for proposals or papers?  That’s what the WiP is about.

The WiP page is here (and quoted in part below). To sign up, you just fill out this form, and later give us a drafty concept paper to share with your group.

The WIP Workshop (formerly named the Critical Research Review) is a dedicated 1-day workshop for ICER attendees to provide and receive friendly, constructive feedback on works-in-progress. To apply for the workshop you will specify a likely topic about which you’ll request feedback. WIP participants will be assigned to thematic groups with 4-6 participants.

Two weeks before ICER, participants will submit to the members of their group a 2-4 page primer document to help prepare for the session and identify the types of feedback sought. At WIP, depending upon group size, each participant will have 45-75 minutes to provide context, elicit advice, support, feedback, and critique. Typically, one of the other group members acts as a notetaker during an individual’s time in order to allow the presenter to engage fully in the discussion.

WIP may be the right experience for you, if you would like to provide and receive constructive advice, support, feedback, or critique on computing education research issues such as:

  • A kernel of a research idea
  • A grant proposal
  • A rejected ICER paper
  • A study design
  • A qualitative analysis approach
  • A quantitative analysis approach
  • A motivation for a research project
  • A theoretical framing
  • A challenge in a research project

The goal of the workshop is to provide a space where we can receive support and provide support. The workshop is intended for active CS education researchers. PhD students are instead encouraged to apply for the Doctoral Consortium, held on the same day as WIP.

May 31, 2019 at 7:00 am Leave a comment

Why I say task-specific programming languages instead of domain-specific programming languages

I’ve written several posts about task-specific programming languages over the last few weeks (here’s the first one), culminating in my new understanding of computational thinking (see that blog post).

The programming languages community talks about “domain-specific programming languages.”  That makes a lot of sense, as a contrast with “general purpose programming languages.” Why am I using a different term?

It’s inspired from my interaction with social studies teachers. They talk about “the language used in math class” and about “what language should we use in history?” History and mathematics are domains. If we talk about a programming language for all of history, that’s too big. It will be difficult to design languages to be easily learned and used.  There are lots of tasks in history that are amenable to using computing to improve learning, including data visualization and testing the rigor of arguments.

“Task-specific programming language” makes clear that we’re talking about a task, not a whole domain. I don’t want teachers rejecting a language because “I can’t use it for everything.”  I want teachers to accept a language because it helps their students learn something. I want it to be so easy to learn and use, that (a) it’s not adding much additional load and (b) it’s obvious that it would help.

I like “task-specific programming language,” too, because the name suggests how we might design them. Human-computer interface researchers and designers have been developing methods to analyze tasks and design interfaces for those tasks for decades. The purpose of that analysis is to create interfaces for users to achieve those tasks easily and with minimal up-front learning.  For 25 years (Soloway, Guzdial, and Hay, 1994) , we have been trying to extend those techniques to design for learners, so that users achieve the tasks and learn in the process.

Task-specific programming languages are domain-specific programming languages (from the PL community) that are designed using learner-centered design methods (HCI).  It’s about integrating between two communities to create something that enables integration of computing across the curriculum.

 

May 27, 2019 at 7:00 am 1 comment

Learning to code is really learning to code something: One doesn’t just “learn programming” nor “learn tracing”

I asked a group of social studies educators what programming language(s) they might want to use in their classes. One of the interesting themes in the responses was “the same as what’s in math and science classes.” One teacher said that she didn’t want a “weird hierarchy” where there’s one programming language in STEM and another in “history and English” for fear they’d be seen as “dumbed down.” Another said that maybe teaching JavaScript in history class “would make history cool.”

There’s a belief in this theme that I think is wrong. Learning to program in science class probably won’t transfer without a bunch of work to programming in mathematics class, and programming STEM classes will probably be a very different thing than programming in the humanities classes. Even expert programmers learn to program in a domain, and have a hard time transferring that knowledge of programming between domains. Expertise is expertise in a domain.

My advisor, Elliot Soloway, was involved in some of the early studies that supported this claim. The first paper was “The role of domain experience in software design” by Beth Adelson and Elliot Soloway from 1985. I quote from the abstract:

A designer’s expertise rests on the knowledge and skills which develop with experience in a domain. As a result, when a designer is designing an object in an unfamiliar domain he will not have the same knowledge and skills available to him as when he is designing an object in a familiar domain.

In this study, they took expert software designers in various fields, and have them design systems in other fields. They also asked novice designers to do some of the same tasks. For example, maybe we have a software designer who has been building banking software, and another who has been designing real-time control systems. Now, let’s ask both designers to design an elevator control system.

What they found was that the designers in the new domain struggled. They stopped planning (e.g., making notes). When they were in the familiar domain, they would often visualize the working system (“simulation” in the paper). Novices didn’t. The experts didn’t when they were faced with a new domain. Experts in an unfamiliar domain looked much like novices. Now, experts in an unfamiliar domain were better than the novices at noticing constraints on the design, so something transferred.

The second paper is even more striking. “Empirical Studies of Programming Knowledge” (1984) by Elliot Soloway and Kate Ehrlich. From the abstract:

We suggest that expert programmers have and use two types of programming knowledge: (1) programming plans, which are generic program fragments that represent stereotypic action sequences in programming, and (2) rules of programming discourse, which capture the conventions in programming and govern the composition of the plans into programs.

When we teach programming, we tend to focus on the syntax and semantics of the language. We don’t explicitly teach plans — chunks of code that do something useful. But we expect students to figure them out. We rarely teach discourse rules. The domain-specific knowledge lies in both plans and discourse rules.

To test the claim about the importance of these discourse rules, they produce sets of two programs: Alpha and Beta. Alpha is a perfectly fine program. Beta breaks the rules. For example, if you see a variable initialized n := 0;, you would find it weird to later see read(n); (to input a new value for n). It’s not wrong. The code might work just fine — in fact, it does work just fine in the experimental construction of Beta. But the program breaks the rules of discourse. They write:

Notice that both Alpha version and the Beta version are runnable programs that in almost all cases compute the same values. Moreover, to an untrained eye their differences may even not be apparent; they always only differ by a very few textual elements.

Here’s an example of one Alpha and Beta — these both work. In this case, they do not do the same thing:

Beta isn’t wrong. It successfully computes minimum. However, it uses the variable max which is confusing. It breaks our discourse rule. The program does work.

Different domains use different standards and different styles of programming. Engineers using MATLAB rarely use FOR or WHILE loops, for example. Graphic designers writing JavaScript code use far more exception handling than we ever expected.

Soloway and Ehrlich showed these programs to “experts” (undergraduate juniors to graduate students) and novices (students in their first programming course). When asked questions about Alpha (e.g., “What goes in this missing line in the code?” Or “Do you remember that code that I showed you?”), experts do far better than novices. When asked questions about Beta, experts do essentially the same as novices (no statistically significant differences).

I find it particularly notable that the expert drop is steeper.  Experts rely heavily on cues like variable names, even more than novices. CS expertise is really expertise in the discourse rules.

If expert programmers “knew programming,” they should be able to just trace the code (“be a computer”) and answer the questions correctly. Instead, they struggle to understand what’s going on. They’re pretty much like a student in their first semester of programming. The experts know Alpha well because it’s just like all the other programs they’ve ever seen — they can pattern match, rather than reason about the code itself. The experts struggle with Beta. It’s kind of like the difference between humans and Econs. Econs can reason through code rationally. Humans rely on expectations.

These results also suggest that the question of “Does tracing come before writing?” is moot.  Tracing what?  The program matters.  Some programs are harder to trace than others — for everyone, and particularly, with expertise.  There is no generic “tracing skill.”

Conclusion: People don’t just learn “coding.” Programmers in general know plans and discourse rules. Break the rules and you just have the programming language — and even experts aren’t really good at just applying the syntax and semantics rules. No better than a novice. If you have enough expertise in different domains, then you can work in different domains. When you start programming in a new domain, you’re not that much different than a new programmer.

The social studies teachers I’m working with have a sense that students can just
know JavaScript.” I don’t think that’s true. I think if I taught students to write JavaScript code to use Google’s Charts service for making data visualizations, it wouldn’t be much easier to teach them Web programming with React, to write scripts for Adobe Photoshop, nor to build simulations in Lively Web. It’s all JavaScript, and the syntax and semantics are the same in each — but in terms of what people really know and use (i.e., plans and discourse rules), it’s completely different.

May 20, 2019 at 7:00 am 7 comments

Older Posts


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 6,246 other followers

Feeds

Recent Posts

Blog Stats

  • 1,654,712 hits
June 2019
M T W T F S S
« May    
 12
3456789
10111213141516
17181920212223
24252627282930

CS Teaching Tips