Ethics in K-8 Computer Science

I’m sure you’ve seen them. New headlines related to ethics and computer science seem to appear daily.

What does all this have to do with teaching computer science to 5-14 year-olds? Ethics should be integral to teaching computer science, regardless of the age of students.

With great power comes great responsibility

Our students are creating with computer science which gives them great power. We need to make sure that they also understand the great responsibility of that power. How can we do this? My first resource when I ask myself this question is the CSTA K–12 Computer Science Standards.

Ages 5-7
Yes, even our youngest students need to be aware of the ethics of computing. At this level, the focus is on ownership. Just as our students learn to protect their possessions and respect the property of others off-line, they need to learn to do this online, as well.

  • 1A-NI-04 Explain what passwords are and why we use them, and use strong passwords to protect devices and information from unauthorized access.
  • 1A-AP-13 Give attribution when using the ideas and creations of others while developing programs.
  • 1A-IC-18 Keep login information private, and log off of devices appropriately.

Ages 8-11
As students mature, they are able to recognize and consider others’ viewpoints which provides opportunities to explore the ethics of computing more deeply. We can use current events, like some of those mentioned above, to bring ethical discussions into the classroom. Students create and often share computational artifacts at this level. They should think about the users who will use what they create and the impact it can have on those users.

  • 1B-NI-05 Discuss real-world cybersecurity problems and how personal information can be protected.
  • 1B-AP-14 Observe intellectual property rights and give appropriate attribution when creating or remixing programs.
  • 1B-IC-19 Brainstorm ways to improve the accessibility and usability of technology products for the diverse needs and wants of users.
  • 1B-IC-20 Seek diverse perspectives for the purpose of improving computational artifacts.
  • 1B-IC-21 Use public domain or creative commons media, and refrain from copying or using material created by others without permission.

Ages 11-14
Students at this level can explore bigger ethical questions because they can better understand the perspective of others as well as the perspective of society. This lets them grapple with ethical questions like: Who is collecting data on them and what are they doing with it? What should the students do with data they are collecting through programs they have created? Are the technologies they are creating accessible by all?

  • 2-IC-20 Compare tradeoffs associated with computing technologies that affect people’s everyday activities and career options.
  • 2-IC-21 Discuss issues of bias and accessibility in the design of existing technologies.
  • 2-IC-23 Describe tradeoffs between allowing information to be public and keeping information private and secure.

Interested in continuing discussions on teaching ethics in the computer science classroom? Join us on Twitter for #csk8 chat where ethics often enters into the discussion and check out #ethicalCS.

Vicky Sedgwick
K-8 Teacher Representative

A Call to Celebrate Diversity in Computer Science

A primary goal for our #CSforAll initiative should be to develop positive computational identities among all students. This requires that students not only build strong foundational knowledge and skills; they must also understand how CS connects to their interests and, perhaps most importantly, believe that they can succeed in CS.

This is challenging because a small subset of the population has dominated the field of computer science, and our society has crafted a pervasive and narrow stereotype for who has access to and can achieve in CS. Even though the field is actually more diverse, these stereotypes are not surprising given the mostly homogenous population of the tech industry (see the Kapor Center’s Leaky Tech Pipeline report, 2018).

It is critical that we disrupt this narrative. We must highlight how people of all backgrounds have positively contributed to computing in diverse ways.

Describing the problem

Students as young as elementary school begin to adopt stereotypical beliefs in STEM. Research has shown the negative impact on students traditionally underrepresented in CS, namely women and people of color (e.g., Cheryan, Master, & Meltzoff, 2015). Professor Sapna Cheryan notes:

“People use these images to decide where they fit, where they’re going to be successful and what’s appropriate for them to pursue.”

Stereotypes negatively affect students’ interest, self-efficacy, career aspirations in STEM (e.g., Shapiro & Williams, 2011). If students do not fit those stereotypes and they don’t have role models that suggest otherwise, they are less likely to pursue CS.

What can we do about this?

Such a wicked problem cannot be fixed quickly, but we can make substantive impacts in our local schools. One strategy is to connect students to role models and mentors with whom they can identify, to provide inspiration and guidance. Exposure to role models of similar race and gender backgrounds leads to increased identification, self-efficacy and aspirations in STEM fields (Stout et al., 2011; Scott et al., 2018).

How to celebrate diversity in CS

Teachers can provide exposure to diverse role models through books, videos, and magazines and also through direct interactions including classroom visits, field trips, career fairs, and mentorship programs. These efforts should happen throughout the year. In addition, during cultural awareness months, we can use the opportunity to highlight people of specific backgrounds. March is Women’s History Month. This presents a great opportunity to connect students to female role models and showcase the incredible contributions of women in CS. Below are some suggestions from the #CSinSF team:

  1. Invite guest speakers to your class. If you don’t have connections through friends and family, try finding a local volunteer or a Skype connection. Here are some tips for classroom volunteers and a list of suggested questions to ask about their careers.
  2. Explore careers. Great videos featuring diverse professionals are available from Made w/ Code, Technolochicas, and Code.org. You can also have students read articles from the Careers with Code magazine, designed for teens to understand how computer science can help them create a dream career in any field, including health, sports, business, fashion, and virtual reality. The site features both profiles and videos of diverse people in diverse industries.
  3. Showcase influential figures in CS. Read books, watch videos, and lead activities that showcase influential figures in computing. For example, during Women’s History Month, hang these posters of seven incredible women in CS and lead related activities (e.g., matching activity, Bee-Bot challenges, Kahoot). Elementary teachers could read story books like Ada Lovelace: Poet of Science and Grace Hopper: Queen of Computer Code and show videos like Happy Birthday, Ada. Additionally, teachers of all levels can use Hidden Figures (original text, young readers’ edition, story book, or the film adaptation) and challenge students to retell stories of these incredible women (e.g., through Scratch animations).

Bryan Twarek, School District Representative

Reading Stories in Computer Science Class

Stories are an entertaining way to introduce or reinforce computer science concepts and help students to understand abstract concepts in a more concrete way. Do you read picture books, chapter books, or short stories to your students in computer science classes? I do. The easiest way to get started is with books that are specifically written to teach CS concepts.
For 5-8-year-olds, Hello Ruby: Adventures in Coding by Linda Liukas is a wonderful place to start. Written to introduce young children to computing, it is a picture book about a “small girl with a huge imagination.” As Ruby goes on adventures, students learn about planning, sequences, algorithms, collaboration, conditionals, loops, and more. The book includes activities that go along with the story, and the official website has resources for educators. Linda Liukas has also written a second book, Hello Ruby: Journey Inside the Computer, which includes activities about the internal parts of a computer.
A graphic novel for 8-12-year-olds that covers multiple CS concepts is Secret Coders by Gene Luen Yang and Mike Holmes. It is the first in a series of books that combine logic puzzles and coding (in Logo) wrapped up in a mystery storyline. The official website has downloadable activities and Logo instruction videos so your students can code along with the characters if desired. Check out the excerpt on the website for a fun introduction to binary. The concepts in the book can easily be applied to any programming language you are using with your students.

The comic book, The Cynja, by Chase Cunningham,‎ Heather C. Dahl, and Shirow Di Rosso was written for younger children, but I like it for introducing Networks and Cybersecurity for Middle School students. The Cynja is a story of a battle between the evil forces of cyberspace and the Cynsei and his apprentice, the Cynja. Code of the Cynja, the second comic in the series, has a female lead character. These are difficult to get in print, but digital versions are available on Amazon and in the Google Play Store.

Don’t limit yourself just to books written about computer science concepts. Working on decomposition skills? Read a “Choose Your Own Adventure” book. Then work with students to decompose it and build a decision tree. Talk about how conditionals allow it to work and have students create their own “Choose Your Own Adventure” program. The Fly on the Ceiling by Julie Glass is a fun book to introduce the coordinate plane. After reading it, students could create a Scratch project to draw their initials using glide commands with x and y coordinates. Read The Very Hungry Caterpillar by Eric Carle and have students retell the story with Bee-Bot or write a ScratchJr project about the life cycle of the butterfly. Look around and see what books are available at your school and find ways to use them in your computer science classes.

Are you reading stories to students in your computer science classroom? We would love to hear about it!

Vicky Sedgwick K-8 Teacher Representative

Use the SCRIPT to Develop Your District’s Own #CSforAll Plans

Individual teacher and school champions have enabled participation in K-12 computer science education to soar to new highs in recent years. However, true systemic change will occur when school districts across the nation create their own #CSforALL goals and implementation strategies. There is a need for districts across the nation to develop comprehensive and equity-minded plans to ensure that all students across all schools can access and achieve in computer science.

Creating these plans can be daunting, especially at early stages of implementation and when there are important competing priorities. It can be tempting to simply replicate plans that other districts have adopted, yet contexts may vary greatly from one district to another, making a single correct answer difficult. Districts should leverage local strengths and consider their unique contexts when developing their plans.

The CSforALL Consortium, a key partner of the CSTA, recently developed a tool to help with this challenge. The new tool is called the SCRIPT: School CSforALL Resource and Implementation Planning Tool. The SCRIPT engages school districts in reflection, review of examples, and goal setting related to six areas: (1) Leadership, (2) Technology Infrastructure, (3) Teacher Capacity, (4) Curriculum and Materials, Selection and Refinement, (5) Partners, and (6) Community.

The SCRIPT is still under development; however CSforALL has released rubrics for Leadership, Teacher Capacity, and Curriculum & Materials, Selection and Refinement. Recently, I helped facilitate a breakout session at a SCRIPT workshop held at the CSforALL Summit in St. Louis. Based on this experience, I believe the SCRIPT is useful for districts that are just getting started, as well as those that have already implemented their comprehensive plans, as there are many distinct elements and a wide continuum of success. The tools promote excellent reflection and conversation and help guide teams towards meaningful next steps.

Here is a suggestion for how to use the SCRIPT:

  1. Convene a leadership team from your local district to develop or update plans to support #CSforALL. Include teachers, principals, curriculum leaders, and district administration; where possible, include representatives from both early-adopting schools and schools that have yet to begin to implement.
  2. Together, focus on each of the six SCRIPT categories one at a time. Use the rubric to reflect on the current status, identify priority areas, and set goals. Consider setting three goals for each area of the rubric: one 3-month goal, one 6-month goal, and one long-term goal.
  3. Use the tools and examples in the SCRIPT, as well as other CSTA resources and CSforALL members, to help plan how you will meet these goals. Feel free to reach out to your local CSTA chapter to ask for advice and support.
  4. Reconvene periodically to monitor progress and update goals.

Creating meaningful and systemic change certainly does not come easily. Accordingly, you won’t find a list of answers within the SCRIPT. However, you will find many thought-provoking questions and topics for conversation. Use these to consider the big picture and develop plans for rigorous, inclusive, and sustainable K-12 computer science education in your local school district.

SCRIPT Cover

Bryan Twarek
School District Representative

Designing Computer Science Classrooms

Computer science is being taught in all kinds of classrooms across the country, not just in computer labs. As more schools increase their computer science offerings and look to dedicate space to those classes, teachers are faced with the question: What should a computer science classroom look like?

In CS teacher professional development, we discuss how to make sure that all students feel welcome in the classroom, including the physical environment itself. NCWIT has a great resource, How Does the Physical Environment Affect Women’s Entry and Persistence in Computing?, that identifies how underrepresented students are impacted by posters and other images that reinforce stereotypes about computing. For example, images that associate “geek” with CS (Star Trek, a lone coder in the dark, etc.) or that call attention to the need for more women, can have a negative impact. Instead, consider using imagery like the new set of posters from NCWIT and Careers With Code, which show a variety of role models using computer science to pursue a personal passion or change their world. The goal should be to select images that appeal to all students and showcase a variety of people.

Working with K-12 teachers, I’ve had the opportunity to see many different types of CS classrooms. Sometimes the computers line the perimeter of the room, facing the wall but making it difficult for some students to see the teacher and their computer at the same time. Some rooms have rows of computers where it’s easier to see the teacher but often difficult to walk around easily. And some are regular classrooms that rely on a laptop cart. All of them have their advantages and disadvantages; the goal is to have a physical space that supports effective teaching.

The college I teach at is also looking to redesign one of our computer labs dedicated to CS courses, with a focus on supporting student collaboration. As more and more of our teaching relies on collaborative and cooperative learning activities such as pair programming, POGIL, debate team carousels, etc. the traditional classroom with rows of computers does not work well. So, we are examining ways to implement flexible classroom arrangements with tables and chairs on wheels that can be easily switched into another configuration. With these types of activities we move from a “guide on the side” model of teaching to more of a “sage of the stage” model and have less need for a large, central area with whiteboards and projection screen.

These types of considerations for the physical design of CS classrooms also directly support practices described in the CSTA K-12 CS Standards, specifically the practices of Collaborating Around Computing and Fostering an Inclusive Computing Culture. So, what would your ideal classroom to teach computer science in look like? How will it support collaboration and make sure that all students feel like they belong?

Jennifer Rosato


Jennifer Rosato
Teacher Education Representative

Learning computing with metaphors

Don’t think of an elephant!

Now what are you thinking about? Of course, it’s an elephant.

This sentence is the title of a book by George Lakoff, a contemporary linguist who makes that case that we frame our thinking with the words and metaphors we use. By consciously recognizing this, we can understand our own thinking better and become more persuasive.

Inspired by Lakoff’s work, Alvaro Videla published an essay Metaphors We Compute By in the October 2017 Communications of the ACM. As a computer scientist and software engineer, Videla recognized the extent to which we make sense of concepts in computing via metaphors. He gives this example:

Say you could program a computer to command other computers to perform tasks, respecting their arrival order. This description is already difficult to understand. On the other hand, you could describe the solution by describing a queue server that assigns jobs to workers based on a first-come, first-served queue discipline.

Consider all the examples from daily life in the description of the solution: A “queue” is something with which all of us are familiar—that’s a “line” for those of us speaking American English! “First-come, first-served” is how most everyday lines operate, “workers” and “jobs” are people and roles from our daily lives.

With this metaphor, it makes sense. The everyday concepts translate into computational artifacts. A worker becomes an operating-systems process. A job becomes an algorithm carried out by that process on some particular data. The line becomes a FIFO queue.

This idea of using metaphors goes back far in our field. Some of the early CS education research focused on how the names of words chosen to be language commands helped (or hindered) students’ understanding. For example, in the 1987 article The Buggy Path to Development of Programming Expertise, Pea, Soloway and Spohrer reported on how students expected parallelism in BASIC code with “IF… THEN” statements. They thought the computer could evaluate any statement as needed, firing when a condition became true—as it might be in daily life.

I’ve used metaphors to explain function application—a concept in functional programming. It’s similar to how parameters or arguments are supplied to C or Java functions. I brought a rubber mallet to class, and described function application as the mallet “pounding the parameters on the head.” So if you have a function increment, which adds one to its parameter, then increment sees a 3, pounds it, and produces a 4. Then “functional mapping” is walking down a list, pounding each parameter in turn. In Scheme: (map increment (list 1 2 3 4)) produces the list (2 3 4 5).

Later during the semester, I could just pretend I was holding the mallet to bring back the idea of function application.

What metaphors have you introduced to your students to help them understand computing concepts? Did they work? Have you changed them over time? Please share with your colleagues!

head shot of Fred Martin, chair of board of directors

Fred Martin, chair of board of directors

Choosing a computing major

Teachers are an important resource for students when it comes to their college decisions. Indeed, undergraduates students often state that a high school teacher influenced their decision to become a computer science major. This blogpost includes a number of  for CS teachers to help their students learn about computing related majors. It might also help teachers recruit students in their computer science courses and highlight the breadth of majors available for students. Along with my colleague Susanne Hambrusch, we have developed the following list of resources for computer science teachers as a part of our NSF-funded PD4CS project.

There exists a range of four-year computing and computing-related degrees a student can pursue. It can be daunting to determine differences and commonalities.

Four-year Liberal Arts Colleges will typically offer one degree, most likely in Computer Science. The simplicity may have a drawback: the number of courses offered may be small and few opportunities for specialization may exist. On the other hand, many liberal arts colleges provide a strong computer science education that is often combined with flexibility, allowing students to take diverse courses in other areas.

Large, research-oriented schools tend to offer multiple computing degrees. The types of degrees and specializations offered are often influenced by whether Computer Science is in a College of Science, a College of Engineering, or in its own College (e.g., College of Computing, School of Information).

Most schools provide information and guidance for incoming students. For example,

Many rankings of computer science programs exist. No ranking is perfect and many schools not ranked or not ranked highly can provide an excellent undergraduate education. The US News and World Report rankings have a good reputation and are respected by universities and colleges. They rank different types of institutions, different research areas, different geographical regions, and more.

Students majoring in a STEM field often consider getting a minor in Computer Science. Having a CS minor will give them additional and often attractive job opportunities after graduation. A minor typically consists of 5-6 CS courses (the student is expected to have the appropriate math courses).  Students majoring in math or physics can often double count courses and may be able to complete a minor with less effort.  Guidelines and expectations differ and a student needs to find out the details for the particular program.

************************************************************************************************************
Aman Yadav is an associate professor in the College of Education at Michigan State University. He serves as the teacher education representative on the CSTA board of directors. Follow Aman on Twitter @yadavaman

Creating Games in ScratchJr without Variables

Written by Aung Nay & Aye Thuzar

ScratchJr is a popular graphical programming language that allows children from age five to seven to create “interactive and animated scenes and stories” [1]. It addresses the lack of programming tools that focus on “content creating or higher level thinking” [1] for kindergarten to second grade students. ScratchJr software deployment comes with the curriculum and online community, and the design goal of the ScratchJr software is to “provide young children with a powerful new educational tool as well as guidance for teachers and parents to implement it to the benefit of diverse areas of early learning, from math and literacy to interdisciplinary knowledge structures” [1].

Even though ScratchJr is great at making interactive and animated stories, creating games was a challenge since ScratchJr does not have variables. Because of this, we developed the idea of a sprite moving towards a goal as an ongoing visual tracker/indicator of the player’s progress [2], which allowed us to create a variety of games. The game creation allowed us to move beyond the interactive storytelling phase and pump excitement beyond. For the purposes of this blog, we would like to introduce one of the sample projects, Safari Animals. For this game, the players will have to tap on only the safari animals to win the game. There will be various animals that will be shown but not all will be safari animals. When a non-safari animal is tapped, the game will be over. Please view the game video at https://youtu.be/OkVoS_3lnbU

grid

Fig 1. Safari Animal game with visual progress tracker

Fig 1 shows a sample project of a game that has the progress dot which starts at row 15 and column 16 and has a red bars at row 15 and column 20. As the game progresses, the red dot moves towards the red bar. When the red dot reaches the red bar, the player is greeted by a “You Win” scene. Along with the achievement tracking, this game also tells a story about animals, particularly the taxonomy of the animal kingdom. The storytelling aspect of the games always draws students in, motivates, and inspires them to create their own games with storyline. And this creativity has to be integrated into the lesson plan. Please see and download the Safari Animal lesson plan at http://scratchjr.zatna.com.

ScrachJr is a great platform for younger kids because you can create exciting games with the progress tracker using fewer code blocks than Scratch or other block programming environments. We hope that ScratchJr team maintains and updates it regularly and more K-2 teachers as well as Pre-K environments will adopt ScratchJr.

Our paper, “Teaching and Learning through Creating Games in ScratchJr: Who needs variables anyway!” will be published in this month as part of the proceedings of the Blocks and Beyond Lessons and Directions for First Programming Environments A VL/HCC 2015.

Reference:

[1] Flannery, Louise P., Elizabeth R. Kazakoff, Paula Bontá, Brian Silverman, Marina Umaschi Bers, and Mitchel Resnick. “Designing ScratchJr: Support for Early Childhood Learning through Computer Programming.” DevTech Research Group. Proc. of 12th International Conference on Interaction Design and Children, ACM, New York, NY. Tufts University, n.d. Web. 29 Aug. 2015

[2] Thuzar, Aye, and Aung Nay. “Teaching and Learning through Creating Games in ScratchJr.” Proc. of Blocks and Beyond Lessons and Directions for First Programming Environments A VL/HCC 2015 Workshop, Atlanta, GA (To be published in Oct. 2015)

AccessCS10k: An Introduction to the Quorum Programming Language and Evidence-Oriented Programming

By:
Andreas Stefik, Ph.D.
Assistant Professor, Department of Computer Science
University of Nevada, Las Vegas

Computer programming in K-12 education has become increasingly mainstream in the U.S., especially with the excellent work being conducted by groups like code.org, Project Lead the Way, CSTA, and many others. These trends have been happening for many reasons, not the least of which being a growing awareness of competition from abroad and the well known shortage of professionals in the field (a problem we are acutely aware of in Las Vegas). In this blog post, I will discuss work on the Quorum programming language, the first, so-called, evidence-oriented programming language. By our current count, Quorum is taught in approximately 34 K-12 schools in the U.S. From surveys, we estimate over 1,800 students will be taught Quorum next year.

In this blog, I’ll outline the origins of the Quorum project and evidence-oriented programming in general. More information can be found about Quorum at our website
(http://quorumlanguage.com/). Quorum has, to our knowledge, the first Hour of Code that is accessible through a screen reading device and a talk on the language was recently presented at Strange Loop and is available here: https://www.youtube.com/watch?v=uEFrE6cgVNY&feature=youtu.be&list=PLcGKfGEEONaCIl5eU53uPBnRJ9rbIH32R

Research on blindness and the origin of Evidence-Oriented Programming

The Quorum project began in approximately 2006 with an exploration I was conducting into the experiences of computer programmers who are blind or visually impaired. Initial interviews and discussions with professional blind programmers made it relatively obvious how many challenges the community faced. In many cases, mainstream tools (e.g., Visual Studio, NetBeans) were not particularly well suited, or in some cases did not work, for this community. More crucially, after discussing the issue with blind professionals, I suspected the challenges for K-12 students were likely worse, as learning Braille or a screen reader can be challenging for blind children. Consider for a moment why learning a programming language like C, on top of learning screen reading skills, might be difficult. While most individuals might see syntax like: for(int i = 0; i < 10; i++) {}

and be fine with it, this is typically translated into speech for the blind. While there is no perfect way to write this, readers are encouraged to say out loud “for left paren int i equals zero semicolon i less than ten semicolon i plus plus right paren left brace right brace.” Similarly, compiler errors when translated to audio can be difficult to understand. A trivial error (e.g., missing a variable definition in C++), might take a minute or two to “listen” to. Mainstream students have difficulty with these things too, but they are exacerbated in students with disabilities.

After making these observations, I concluded that one obvious way to approach making programming easier was to improve the tools (e.g., talking debuggers, accessible editor hints, accessible completion, accessible code folding). I invented all of those things (most are in Sodbeans, a tool for the blind used throughout the U.S. today), and they do seem to help, but C itself is still hard to “listen to.” Ultimately I couldn’t get this nagging question out of my head, “What was the evidence for the design of C to begin with?” So I began to investigate, but weirdly … I could find little human factors evidence in the academic literature.

Historical Context on Evidence Standards:

A slight detour is necessary to help readers who are not familiar with historical evidence gathering techniques. Giving credit where due, I highly recommend reading a paper by Ted Kaptchuk on the history of blind assessment, which influenced my thinking: http://media.virbcdn.com/files/5f/FileItem-260254-Kaptchuk_IntentIgnor_BulHisMed1998.pdf

Let’s briefly discuss this history. First, it was not always the case that medical practitioners, psychologists, and others used experiments in science. In medicine, the techniques started largely in the late 18th century after Louis XVI created a commission to study the bogus theory of animal magnetism (mesmerism). Benjamin Franklin, the head of the commission, used the idea of “sham treatments” to uncover problems with this (bogus) theory.

As science progressed, techniques became increasingly rigorous. Scientists used primitive placebo tests as early as 1834, although they still had no concept of experimental design. By the late 19th century, psychology was developing and we start to see the use of randomization, at first to explore sensory perception and to evaluate (bogus) supernatural claims like those made by psychics (e.g., talking to the dead).

Experimentation moved forward again in pharmacology, in part because of Charles Edouard Brown-Sequard’s claims that testicular extract from guinea pigs would “rejuvenate mental and physical health.” The scientific community, now increasingly skeptical of claims made without evidence, started still rather primitive assessments within a few months. Finally, by the mid-1930s, we obtained what many scientists think of today as the randomized controlled trial, made possible largely by Ronald Fisher in his famous, “The Design of Experiments.” While not mentioned by Kaptchuk, experimental design today has made other important leaps forward, most of which are unfortunately not internalized in computer science like they are in other disciplines (e.g., studies on replication, registered randomized controlled trials). Walter Tichy has probably discussed this more than most.

Evidence-Oriented Programming

Back to blindness and programming, consider observations that children who are blind had extraordinary difficulties with programming languages, and also that the academic literature was sparse with human factors data on programming languages. Certainly, there exists some papers on the topic (e.g., ESP, PPIG, Plateau, a small number of trials in the 70s and 80s), but the number of randomized controlled trials is small. Programming languages make up the entire foundation of modern software — effectively every computing device that everyone owns is built with one. Yet, the top conferences in programming languages used rigorous proofs to determine if features worked, and had significant empirical data to evaluate performance, but used anecdotes for human factors. I didn’t understand why this would be (yet), but by 2009, we started investigating ourselves, largely in this paper:

Stefik and E. Gellenbeck. Empirical studies on programming language stimuli. Software Quality Journal, 19(1):65-99, 2011. 10.1007/s11219-010-9106-7.

Some problems became obvious. Surveys showed words like “for, while, or foreach” were, in a bizarre and unexpected twist of irony, the three least intuitive choices for people in our sample (which we later replicated). This is ironic because these choices are common across a large number of programming languages.

Surveys only tell us so much though, so we went further, which is to take from the medical playbook, using sham (or dummy) treatments. In the first test, we used what I called a “Placebo Language,” basically a randomly designed programming language where symbols are chosen from the ASCII table (one could imagine other placebo languages). We sent the first of these tests to a small workshop called Plateau in 2011:

Andreas Stefik, Susanna Siebert, Melissa Stefik, Kim Slattery. An Empirical Comparison of the Accuracy Rates of Novices using the Quorum, Perl, and Randomo Programming Languages. Workshop on the Evaluation and Usability of Programming Languages and Tools (PLATEAU 2011). Portland, OR, October 24th, 2011.

The result, at least to me, was an eye opener. Perl, despite the fact that it was a very popular programming language with significant community support, was apparently not detectably easier to use for novices than a language that my student at the time, Susanna Kiwala (formerly Siebert), created by essentially rolling dice and picking (ridiculous) symbols at random. That result was astonishing and I frankly wasn’t sure I believed it. So, we ran a replication with three additional languages. The result was the same, replicating with extreme accuracy on a new sample (Perl within less than a percent). That work was published here:

Andreas Stefik and Susanna Siebert. 2013. An Empirical Investigation into Programming Language Syntax. ACM Transactions on Computing Education 13, 4, Article 19 (November 2013), 40 pages.

Interestingly, in this new study, the same result we saw with Perl we also observed with Java, a programming language so popular it is used in the Computer Science A – AP test in high school. Ultimately, using a technique we call Token Accuracy Mapping, which is basically a way to figure out which tokens may have caused the problems, it appeared that C-style syntax was plausibly the culprit. At the same time, using this new technique, we found a variety of problems with Quorum and borrowed from languages where the evidence showed they had a better design (e.g., Ruby’s if statement design, with the exception of the equality syntax ==, was integrated into Quorum 1.7).

Again, this finding surprised us. At this point, while there is a lot more to learn, we knew there was a problem and our strong suspicion was that the language community had not been gathering rigorous evidence on human factors, basically in its entire history, which we have since confirmed is an unfortunate truth. We hypothesize that this lack of evidence may be one of the leading causes of the so-called “programming language wars,” which we discuss at length in the literature:

Andreas Stefik and Stefan Hanenberg. 2014. The Programming Language Wars: Questions and Responsibilities for the Programming Language Community. In Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software (Onward! 2014). ACM, New York, NY, USA, 283-299.

In other words, if language designers are not even gathering evidence on human factors, then it’s not surprising that they seem to disagree about their designs or that students might needlessly struggle. In essence, language designers prove that their features work, and show evidence that they are “fast,” but they never seem to ask, in a scientifically defensible way, “What is the impact on various kinds of people?”

Creating Quorum:

As these studies progressed over time, and as we worked more with various communities, my wife and I decided that if we wanted to program using a language that used human factors evidence as a guide, we would have to build it ourselves. So, we developed the first Evidence-Oriented Programming language, which we called Quorum. Here are the basic ideas of this paradigm as I see it today:

  1. Design features of a language must have corresponding evidence from appropriately constructed randomized controlled trials for as much as is possible
  2. The language authors must allow the external community to suggest changes according to the scientific method, inspired by lessons from history
  3. Evidence from other techniques (e.g., software repository mining, educational data) if gathered from humans and rigorous is allowed

Now to be clear, Evidence-Oriented Programming is a paradigm, not a language, and the scholar Stefan Hanenberg in Germany thought it up at basically the same time. He came to the same conclusions I did for different reasons, with different experiments, on a different part of the globe (his story on the topic is very different from mine and fascinating). Others are fleshing it out better than I have, especially the scholar Antti-Juhani Kaijanaho, who has created what is perhaps the most systematic review of the history of the programming language wars ever.  

More crucially, it is a paradigm because the evidence on various design decisions (which I won’t get into here, but have written about extensively) is tricky to understand and requires significant statistical expertise to grasp. It also appears that some design decisions have trade-offs, the most well known of which to-date is that whether functions in programming contain type information (e.g., an integer, a number) appears to improve productivity of those past the third year of experience in college, but has a small, but non-zero, negative impact on novices at around a freshman year of college (depending on where in a program it is).

In other words, I can imagine one language designer using evidence to optimize human factors for one group, while another optimizing for another, with both taking all known controlled trials into account and therefore having some similarities in their design. As a simple example, a block language designer hypothetically designing for a child’s toy or learning might use the word “repeat” for iteration, which the evidence supports, yet a text-based language designer might use the same word when designing for industrial scale robotics or a NASA rocket where blocks might be impractical and where efficiency of the language is crucial (or some other reason). This type of thinking could provide increased consistency amongst language designs in the years to come, with an increasingly stronger foundation of evidence.

In any case, evidence-oriented programming is not a panacea, nor does it imply we will eventually get to the unlikely idea of “one language to rule them all.” Plausibly, what we are observing today is a paradigm shift in language design, going from next to no evidence at all on human factors toward an unwillingness of young scholars like myself to accept anecdotes or prestige as fact, for a basically similar reason Benjamin Franklin didn’t in the 18th century. No one knows where the evidence-oriented movement will end up, perhaps with some complex hybrid of blocks or visualization, or maybe with different domains having various kinds of approaches, or maybe even partial standardization of some aspects of language design within a century (or two). Wherever it ends up, the goal is to follow the evidence wherever it leads in order to make the next generation of programming technologies just as practical at industry scale, while also being easier to understand and use.

While Quorum began as a toy exclusively to help blind children learn computer science, it has grown in unexpected ways. While it is still used across the U.S. at around half of schools for the blind and visually impaired, about half of teachers that came to the 6th annual Experience Programming in Quorum workshop in Vancouver, WA represented mainstream schools. Quorum is a Java Virtual Machine Language, so it will run on most machines, and has a variety of libraries, including those for creating computer games, LEGO robotics support, and more. Quorum is accessible for people with disabilities, including those with visual impairments, and supports a robust and accessible development environment based on Oracle’s NetBeans. Since the language is built on industrial strength technologies, it can be used not just in K-12, but potentially in college or industry as well, for effectively any general purpose application. Finally, Quorum is under the BSD license (free for any use), and all curriculum is free under the Creative Commons License. Our curriculum goes through continuous improvement by dedicated K-12 teachers and is being mapped to Computer Science Principles and, hopefully soon, the common core. More information can be found at: http://quorumlanguage.com/

CS Principles and Creativity

Students will likely need exposure to, and practice with the CS Principles big Idea “Creativity” many, many times before a “creative – innovative – mindset” is comfortable and natural. You may have to undo years of “non-creativity conditioning.”

It is not enough to tell students that creativity is important; you must show students that you value creativity by actively engaging in it yourself. I don’t have to tell you that a unit exclusively “on creativity” is bound to fall flat!

So how can we build creativity and innovation into the very core of CS Principles? A few suggestions from a variety of experts:

  1. Let students know that there are usually multiple paths that lead to understanding.
  2. Arrange student collaborations that provide meaningful (to them) real-world, problem-solving opportunities.
  3. Provide lots of project and performance choices that employ a variety of “intelligences” whenever feasible.
  4. Encourage them to look for and experiment with new things and ideas.
  5. Encourage questioning.
  6. Be sure your grading does not penalize “less than successful” creativity. Students will not feel free to experiment if their grade hinges on some abstract measure of success. The true reward for being creative is purely intrinsic.
  7. Encourage them to mistakes as opportunities for learning rather than failures.
  8. Enable students to exchange, value, and build upon the ideas of others. Share interesting examples of technological creativity that you run across in the media.
  9. Make time for informal interactions between students.
  10. Offer a safe environment that encourages risk-taking. Avoid a competitive and extrinsically rewarding classroom, by providing a friendly, secure, and comfortable environment.

What do you do in your classroom to build the creative capacity of your students? Share with us!