Archive for July, 2019

Why high school teachers might avoid teaching CS: The role of industry

Fascinating blog post from Laura Larke that helps to answer the question: Why isn’t high school computing growing in England?  The Roehampton Report (pre-release of the 2019 data available here) has tracked the state of computing education in England, which the authors describe as a “steep decline.” Laura starts her blog post with the provocative question “How does industry’s participation in the creation of education policy impact upon what happens in the classroom?” She describes teachers who aim to protect their students’ interests — giving them what they really need, and making judgments about where to allocate scarce classroom time.

What I found were teachers acting as gatekeepers to their respective classrooms, modifying or rejecting outright a curriculum that clashed with local, professional knowledge (Foucault, 1980) of what was best for their young students. Instead, they were teaching digital skills that they believed to be more relevant (such as e-safety, touch typing, word processing and search skills) than the computer-science-centric content of the national curriculum, as well as prioritising other subjects (such as English and maths, science, art, religious education) that they considered equally important and which competed for limited class time.

Do we see similar issues in US classrooms?  It is certainly the case that the tech industry is painted in the press as driving the effort to provide CS for All.  Adam Michlin shared this remarkable article on Facebook, “(Florida) Gov. DeSantis okay with substituting computer science over traditional math and science classes required for graduation.” Florida is promoting CS as a replacement for physics or pre-calculus in the high school curriculum.

“I took classes that I enjoyed…like physics. Other than trying to keep my kids from falling down the stairs in the Governor’s mansion I don’t know how much I deal with physics daily,” the governor said.

The article highlights the role of the tech industry in supporting this bill.

Several top state lawmakers attended as well as a representative from Code.org, a Seattle-based nonprofit that works to expand computer science in schools. Lobbyists representing Code.org in Tallahassee advocated for HB 7071, which includes computer science initiatives and other efforts. That’s the bill DeSantis is reviewing.

A Microsoft Corporation representative also attended the DeSantis event. Microsoft also had lobbyists in Tallahassee during the session, advocating for computer science and other issues.

The US and England have different cultures. Laura’s findings do not automatically map to the US. I’m particularly curious if US teachers are similarly more dubious about the value of CS curricula if it’s perceived as a tech industry ploy.

 

July 29, 2019 at 7:00 am 3 comments

Beta release of new JES (Jython Environment for Students) now available: Media Computation for Python IDE

Veronica Day and Audrey Zhang are two undergraduate researchers with whom I have been working here at University of Michigan to update JES (Jython Environment for Students), the Python IDE for Media Computation.  We last updated it in 2015 (see announcement post here), so it’s long overdue. The last version has been downloaded over 50K times (see counts here). I’m grateful to Veronica and Audrey for their hard work.

Besides working their way through the bug list on GitHub, and adding contributed features into the main trunk (like Ben Shapiro’s support for Mac retina displays – many thanks, Ben!), they have added support that I’ve been wanting for awhile. We can now create pictures from a collection of pixels and sounds from a collection of samples. This allows for a more functional style of media manipulations. In the example below, we makePicture by filtering for only certain pixels with a list comprehension ([px for px in getPixels(p) if getRed(px)<120]).

Please try out the beta version of JES and let us know of errors. Thanks

http://web.eecs.umich.edu/~mjguz/uploads/jes-5.02b5/

We plan to update a few more parts of this version before the 6.0 release. In particular, we’d like to upgrade to the latest Jython and the latest JMusic. I’m expecting some of our regression tests to fail on that, so there will be some tweaks yet.

This may be our last release of JES.  Jython is no longer in development (see post here). I’ll have to try again to get Media Computation to work in CPython (see last try here) and/or move to one of the browser-based Python implementations.

July 22, 2019 at 7:00 am 2 comments

So what’s a notional machine anyway? A guest blog post from Ben Shapiro

Last week, we had a Dagstuhl Seminar about the concept of notional machines, as I mentioned in an earlier blog post about the work of Ben Shapiro and his student Abbie Zimmermann-Niefield. There is an amazing amount being written about the seminar already (see the Twitter stream here), with a detailed description from Amy Ko here in her blog and several posts from Felienne on her blog. I have written my own summary statement on the CACM Blog (see post here). It seems appropriate to let Ben have the summary word here, since I started the seminar with a reference to his work.

I’m heading back to Boulder from a Dagstuhl seminar on Notional Machines and Programming Language Semantics in Education. The natural question to ask is: what is a notional machine?

I don’t think we converged on an answer, but here’s my take: A notional machine is an explanation of the rules of a programmable system. The rules account for what makes a program a valid one and how a system will execute it.

Why this definition? Well, for one, it’s consistent with how du Boulay, coiner of the term notional machine, defined it at the workshop (“the best lie that explains what the computer does”). Two, it has discriminant utility (i.e. precision): the definition allows us to say that some things are notional machines and some are not. Three, it is consistent with a reasonable definition of formal semantics, and thus lets us imagine a continuum of notional machines that include descriptions of formal semantics, but also descriptions that are too imprecise — too informal — to be formal semantics but that still have explanatory value.

The first affordance is desirable because it allows us to avoid a breaking change in nomenclature. It would be good if people reading research papers about notional machines (see Juha Sorva’s nice review), including work on how people understand them, how teachers generate or select them, etc., don’t need to wrestle with what contemporary uses of the term mean in comparison to how du Boulay used the term thirty years ago. It may make it easier for the research community to converge on a shared sense of notional machine, unlike, say, computational thinking, where this has not been possible.

The second affordance, discriminant utility, is useful because it gives us a reason to want to have a term like notional machine in our vocabulary when we already have other useful and related terms like explanation and model and pedagogical content knowledge. Why popularize a new term when you already have perfectly good ones? A good reason to do so is because you’d like to refer to a distinct set of things than those terms refer to.

The scope of our workshop was explicitly pedagogical: it was about notional machines “in education.” It was common within the workshop for people to refer to notional machines as pedagogical devices. It is often the case that notional machines are invented for pedagogical purposes, but other contexts may also give rise to them. Consider the case of Newtonian mechanics. Newton’s laws, and the representations that we construct around them (e.g. free body diagrams), were invented before Einstein described relativity. Newton’s laws weren’t intended as pedagogical tools but as tools to describe the laws of the universe, within the scales of size and velocity that were accessible to humans at the time. Today we sequence physics curriculum to offer up Newtonian physics before quantum because we believe it is easier to understand. But in many cases, even experts will continue to use it, even if they have studied (and hopefully understand) quantum physics. This is because in many cases, the additional complexity of working within a quantum model offers no additional utility over using the simpler abstractions that Newtonian physics provides. It doesn’t help one to predict the behavior of a system any better within the context of use, but likely does impose additional work on the system doing the calculation. So, while pedagogical contexts may be a primary locus for the generation, selection, and learning of notional machines, they are not solely of pedagogical value.

Within the workshop, I noticed that people often seemed to want their definitions, taxonomies, and examples of notional machines to include entities and details beyond those encompassed by the definition I have provided above. For example, some participants suggested that action rules can be, or be part of, notional machines. An example of an action rule might be “use descriptive variable names” or “make sure to check for None when programming in Python.” While both of these practices can be quite helpful, my definition of notional machines accepts neither of them. It rejects them because they aren’t about the rules by which a computer executes a program. In most languages, what one names variables does not matter, so long as one uses a name consistently within the appropriate scope. “Make sure to check for None” is a good heuristic for writing a correct program, but not an account of the rules a programming environment uses to run a program. In contrast, “dereferencing a null pointer causes a crash” is a valid notional machine, or at least a fragment of one.

Why do I want to exclude these things? Because a) I think it’s valuable to have a term that refers to the ways we communicate about what programming languages are and how the programs written in them will behave. And b) a broader definition will refer to just about everything that has anything to do with the practice of programming. That doesn’t seem worth having another term in our lexicon, and it would be less helpful for designing and interpreting research studies for computing education.

The third affordance is desirable because it may allow us to form stronger bridges to the programming languages research world. It allows us to examine — and value — the kinds of artifacts that they produce (programming languages and semantics for those languages) while also studying the contradictions between the values embedded in the production of those artifacts and the values that drive our own work. Programming languages (PL) researchers are generally quite focused on demonstrating the soundness of designs they create, but typically pay little attention to the usability of the artifacts they produce. Research languages and written (with Greek) semantics have difficult user interfaces, at least to those of us sitting on the outside of that community. How can we create a research community that includes the people, practices, and artifacts of PL and that conducts research on learning? One way is to decide to treat the practices and artifacts of PL researchers, such as writing down formal semantics, an instance of something that computing education researchers care about: producing explanations of how programming systems work. PL researchers describing languages’ semantics aren’t doing something that is very different in kind than what educators do when they explain how programming languages work. But (I think) they usually do so with greater precision and less abstraction than educators do. Educators’ abstractions may be metaphorical (e.g. “There’s a little man inside the box that reads what you wrote, and follows your instructions, line by line…”) but at least if we use my definition, they are of the same category as the descriptions that semanticists write down. As such, the range of things that can be notional machines, in addition to the programming languages they describe, may serve as boundary objects to link our communities together. I think we can learn a lot from each other.

That overlap presents opportunities. It’s an opportunity for us to learn from each other and an opportunity to conduct new lines of research. Imagine that we are faced with the desire to explain a programming system. How would a semanticist explain this system? How would an experienced teacher? An inexperienced teacher? What do the teachers’ explanations tell us about what’s important? What does a semanticist’s explanation tell us about what’s the kernel of truth that must be conveyed? How do these overlap? How do they diverge? What actually works for students? Can pedagogical explanations be more precise (and less metaphorical) and still be as helpful to students? Are more precise definitions actually more helpful to students than less precise ones? If so, what does one need to know to write a formal semantics? How does one learn to do that? How does one teach educators to do that? How can we design better programming languages, where better is defined as being easier to understand or use? How can we design better programming languages when we have different theories of what it means to program well? How do we support and assess learning of programming, and design programming languages and notional machines to explain them, when we have different goals for what’s important to accomplish with programming?

There are many other questions we could ask too. Several groups at the workshop held breakout sessions to brainstorm these, but I think it’s best to let them tell their own stories.

In summary, I think the term notional machines has value to computing education research, but only if we can come to a consensus about what the term means, and what it doesn’t. That’s my definition and why I’ve scoped it how I have. What’s your take?

If you’d like to read more (including viewpoints different than mine), make sure to check out Felienne’s and Amy’s blog posts on this same topic.

Thank you to Shriram, Mark, Jan, and Juha for organizing the workshop, and to the other participants in the workshop for many lively and generous conversations. Thanks as well to the wonderful Dagstuhl staff.

 

July 15, 2019 at 12:00 pm 14 comments

How to reduce the defensive climate, and what students really need to understand code: ITICSE 2019 Preview

This year, we’re presenting two papers at the 2019 ACM SIGCSE Innovation and Technology in CS Education (ITICSE) conference in Aberdeen, Scotland. I’ve been to ITICSE several times and enjoy it every time, but I can’t always justify the trip. This year, Barbara Ericson, Katie Cunningham, and I are all in Germany for a Dagstuhl Seminar on Notional Machines the week before, so we took the opportunity to submit and are fortunate to be invited to present.

Making CS Learning Visible: Case Studies on How Visibility of Student Work Supports a Community of Learners in CS Classrooms by Amber Solomon, Vanessa Oguamanam, Mark Guzdial, and Betsy DiSalvo

When I taught CS Ed Research this last semester (see the blog post about open questions from the class), the students so resonated with Lecia Barker’s papers about defensive climate (the classic paper is here). The story about how CS classes are “characterized by competitiveness rather cooperation, judgments about others, superiority, and neutrality rather than empathy” still rings true, 17 years after first written. Several of my students proposed research to follow-up on the original study.

Amber and Vanessa are also motivated by the concerns about defensive climate in CS classes, but they don’t want to measure it. They are suggesting an intervention.

They suggest that a community of learners approach would reduce defensive climate. Key to creating a community of CS learners, they propose, is making student work and process visible. Vanessa works in marker-oriented curricula, where student work is physical and the work process is visible. Amber did the evaluation of the AR design studio classroom that I’ve written about previously. In both of these case studies, they observed student communication patterns that were different from the defensive climate studies and more in keeping with a community of learners culture. Defensive climate is still a problem, and changing culture and community is the way to address it.

Novice Rationales for Sketching and Tracing, and How They Try to Avoid It by Katie Cunningham, Shannon Ke, Mark Guzdial, and Barbara Ericson

At ICER 2017, Katie presented a study of how students trace their programs on paper (see ICER 2017 paper here, and my blog post summary here). She had some fascinating and surprising results. For example, if students traced their programs only part way and then guessed at the final result, they were more likely to get the problem wrong than if they’d never traced before. But why? Why would students trace the program part way and then stop — only to get it wrong?

That’s what Katie explored in this follow-up paper. She had an innovative experimental design. She replicated her original tracing experiment, then pulled out about a dozen interesting participants, and invited them back for a retrospective interview. She could show them the original problem and what they traced — and then ask them why? Here’s one of the answers: They thought that they “got the hang of it.” They recognized a goal or pattern. They just recognized wrong.

One of my favorite parts of the paper is completely visual. Katie had a terrific idea — let’s ask the teacher of the class to trace the problems. Here’s one of the traces that the teacher did:

Here are some examples of what students did:

Notice a distinct lack of similarity? Why? Why don’t students trace like the instructor did?

This is a qualitative study, so it’s rich with interview data. I recommend reading the whole paper. There’s a neat part at the end where Katie points out, “Program visualizations do X. When students trace, they do Y. Why are these things so different?”

July 14, 2019 at 1:00 pm 5 comments

Learning to build machine learning applications without code as an example of computing education research

 

Ben Shapiro shared a nice video that his student Abbie Zimmermann-Niefield made about their new paper at IDC. They built a system that allows kids to build applications with machine learning to detect (in this example) good from bad soccer passes.

The video (and paper) are perfect for IDC. It’s a wonderful example of giving students a new computational medium to build new kinds of applications that they couldn’t previously.  But the video also raised a bunch of questions for me.  Abbie at one point talks about users of her system as “learners.”  What are they learning?

David Moon put his finger on some of the issues for me with his tweet:

You don’t have to code to build ML applications.  But then, is it programming?  In the About page for this blog, I have defined computing education research as studying how people come to understand computing, and how to improve that process.  What are the students coming to understand in Abbie and Ben’s application?  Is studying how students come to build, understand, and debug their ML applications an example of computing education research?

I exchanged some messages with Ben, and came to an understanding of what he’s doing — which in turn gave me a new understanding of what I do.

In a blog post inspired by Juha Sorva, I suggested a refinement of my original definition.  “Coming to understand computing” means to develop a workable mental model or to learn a notional machine of a computing system. Programming is about intentionally defining a process for a computational agent to execute at another time. A notional machine is an explanation for the behavior of a system — it’s a teacher’s attempt to influence the mental model that the student is forming about the system.  I learned more about notional machines at a later Dagstuhl, and I’m excited to be attending a Dagstuhl Seminar this week where I’ll learn a lot more about notional machines.

Abbie’s participants are developing a mental model of how the system works — it’s not very elaborate, and it’s mostly wrong.  One student tells Abbie that she needs to have more both good and bad examples to make the system more accurate.  Okay, but why?

Ben says that they want to reach the point where students develop a working mental model of the system: About why they need to oversample some kinds of events, to be able to choose between different kinds of machine learning models, to be able able to judge what makes for a good data set, and to decide how to test the system to determine if it’s classifying all the desired inputs correctly.  Really, these are all the kinds of things we want students building any kind of program to think about — did I build this correctly (what I wanted it to be), how do I know, and how do I test to make sure?  Whether it’s by constructing data or by writing code, it’s still about intentionally defining a process for a computational agent, and then testing that process to determine if it matches the desired function.

It’s a fascinating question (which I expect we’ll be discussing this week) about what notional machines one uses to explain machine learning models.  It’s an important computing education research question: what mental models do students form about machine learning systems?  A different one is: what notional machines do we teach in order to improve the mental models that students develop about machine learning models?

Now, does it matter if students can’t see the code?  I don’t think so.  It probably matters for CS major undergraduates (which Ben, Peter, and Rebecca have argued elsewhere), but for the general population?  What does it mean to “see the code” anyway?

  • At a high level, I’m a big fan of block-based languages (as mentioned in a recent blog post about one of David Weintrop’s results). Block-based languages are also a higher-level representation of code.  That doesn’t matter. It’s still programming. It’s still computing.
  • At a low level, who really understand what their code does anymore?  With code optimization, processor prefetching, cache memory, and branch prediction, it’s really hard to know what’s really going on anyways.  Some people do. Most people don’t. And it really doesn’t matter.

The lack of code might make the notional machine harder to teach.  There is no code to point at when explaining an algorithm (see Amber Solomon’s work on the role of gestures in teaching CS).  Maybe you wouldn’t explain an algorithm.  Maybe instead you’d point at examples and point at key features of those examples.  Maybe. It’s an open and interesting research question.

So. Computing education is about helping students to develop mental models of computing systems. These models must be workable to the point of being usable for intentional construction and debugging. Studying how students build machine learning applications without code is also computing education research.

July 8, 2019 at 2:00 am 11 comments

Iterative and interdisciplinary participatory design sessions: Seeking advice on a research method

Here’s an unusual post for this blog: I’m looking for a research methodology, and I don’t know where to look for it. I’m hoping somebody here will have a suggestion — please do forward this blog post to others you think might have suggestions for me.

We’re running participatory design sessions with teachers — asking teachers to try out programming languages with scaffolded activities, and then tell us about what they’d like for their classroom. I’m collaborating with Tammy Shreiner and Bradford Dykes at Grand Valley State University around having social studies teachers build data visualizations. We’re scouring the book Participatory Design for Learning, and in particular, we’re using Michelle Wilkerson’s chapter (which I’ve read twice now) because it matches the kind of work we’re doing.

Michelle uses a technique called Conjecture Mapping to describe how her teams thinks about the components of a participatory design session. A session has a specific embodiment (things you put into the classroom or session), which you hope will lead to mediating processes (e.g., participants exploring data, people talking about their code, etc.). These are processes which should lead to desired outcomes based on theory. A conjecture map is like a logic model in that it connects your design to what you want to have happen, but a conjecture map is less about measuring outcomes. Rather, it’s more about describing mediating processes, which you theorize will lead to desired outcomes. The mediating process column is really key — it tells you what to look for when you run the design session. If you don’t hear the kind of talk you want and see participant success in the activity, something has gone wrong. Fix it before the next iteration. The paper on this technique is Conjecture Mapping: An Approach to Systematic Educational Design Research by William Sandoval.

So here’s the first problem: We have different set of outcomes for our sessions. They’re interdisciplinary. I want to see the teachers being successful with their programs, my collaborators Tammy Shreiner and Bradford Dyke wants to see them talking about their data, and we all want to see participants relating their data visualizations to their history class (e.g., they shouldn’t be just making pretty pictures, and they should be connecting the visual elements to the historical meaning). Should we put all of these mediating processes and outcomes into one big conjecture map?

We are not satisfied with this combined approach, because we’re going to be iterating on our designs over time. Most participatory design approaches are iterative, but I haven’t seen a way of tracking changes (in embodiment or mediating practices) over time. Right now, we’re working with Vega-Lite and JavaScript. In our next iterations, we’ll likely do different examples with Vega-Lite. Over time, we want to be building prototypes of data visualization languages designed explicitly for social studies educators (task-specific programming languages).

We are concerned about two big problems as we iterate:

  • Missing Out. I don’t want to lose any of our mediating processes. I want to make sure that we continue to see success with programming, engagement with data, and meaningful visualizations.
  • Changing the balance. The easiest trap for our work will be to over-emphasize the programming, and swamp out the data literacy and data visualization processes and outcomes. If our sessions become perceived as primarily a programming activity, we’re moving in the wrong direction. We want the data literacy and data visualization to be primary, with programming as a supporting activity.

The diagram at the bottom may help describe the problem — it’s the sketch that my PhD student Bahare Naimipour and I made while talking through this problem. We need to track multiple disciplinary processes and outcomes over time as we iterate across different embodiments. This isn’t about assessing an intervention or design. This is about gathering input as we design and implement technology prototypes. We want to be moving in the right direction, for the processes and outcomes that we want.

Here’s where I’m asking for help: Where should we be looking for exemplars? Who else is doing iterative, multidisciplinary participatory design sessions? What are good methods for use to use?

Thanks!

July 1, 2019 at 7:00 am 4 comments


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

Join 7,062 other followers

Feeds

Recent Posts

Blog Stats

  • 1,690,970 hits
July 2019
M T W T F S S
« Jun   Aug »
1234567
891011121314
15161718192021
22232425262728
293031  

CS Teaching Tips