How to choose programming languages for learners: Reviewing JavaScript and Ready
June 20, 2016 at 7:46 am 23 comments
My Blog@CACM post for June is Five Principles for Programming Languages for Learners. The five principles I identify are:
- Connect to what learners know
- Keep cognitive load low
- Be honest
- Be generative and productive
- Test, don’t trust
I wrote the essay in response to Idit Harel’s influential essay American schools are teaching our kids how to code all wrong. There were many responses to Idit’s essay, on social media and in other blogs. Much of the discussion focused on text programming languages vs. drag-and-drop, blocks-based languages, which I don’t think is the most critical distinction.
In this post, I respond to two of the suggestions that came up in some of these discussions. I use the five principles to review the suggestions in a kind of heuristic evaluation.
JavaScript
If we were going to teach a professional language to students, JavaScript is attractive. It’s free and ubiquitous, available in every Web browser. There are many jobs for JavaScript programmers. Because so much is built on top of it, it’s likely to remain around for many years in a compatible form. I argue in the Blog@CACM post that there are many dimensions to “real” when it comes to programming languages. “Use by professionals” is not the most important one when we talk about learners.
I recommend considering each of these five principles before choosing a programming language like JavaScript for learners.
- Connect to what learners know – You could teach JavaScript as a connection to what children already know. The notation of JavaScript doesn’t look like anything that children are likely to have seen before, in contrast to Logo’s emphasis on words and sentences, Squeak eToys’ “Drive the Car,” Boxer’s simple UI boxes (what diSessa calls naive realism), and Racket/Bootstrap’s connections between algebra and S-expressions. However, JavaScript is the language of the Web today, so one could probably relate the programming activities to Web pages. Most learners are familiar with parts of a Web page, animations in a Web page, and other Web features that JavaScript can control. That might serve as a connection point for children.
- Keep cognitive load low – JavaScript has a high cognitive load. I’m a JavaScript learner and am just meeting some of its weirder features. I was shocked when I first read that
=is assignment,==is type-insensitive equality, and===is type sensitive equality/equivalence. So,"5"==5is true, but"5"===5is false. Counting the number of=and remembering what 1 vs 2 vs. 3 means is an excellent example of extraneous cognitive load. My bet is that JavaScript overwhelms children and is probably inefficient for adult learners. This means that learners are spending so much time making sense of the syntax, it takes them longer and more effort to get to the concepts (and they may lose interest before they get to the good stuff). - Be honest – JavaScript is authentic, it’s real for most senses of the term.
- Be generative and productive – I don’t know if JavaScript would be generative and productive for students. I don’t know anyone teaching JavaScript as a way to teach significant ideas in CS or other STEM disciplines. My worry is that the cognitive load would be so overwhelming that you couldn’t get to the interdisciplinary or complex ideas. Students would spend too much effort counting
=and fightingforloops. - Test, don’t trust – The only study that I know comparing JavaScript to a blocks-based language had JavaScript losing. JavaScript conditionals and loop structures were far harder for students than the equivalent block-based structures.
We should experiment more with JavaScript, but I suspect that students would do better (struggle less with syntax, learn more, connect to other disciplines more) with a different syntax. If I were trying to get the advantages of JavaScript without the syntax cost, I’d try something like ClojureScript — freely available, as fast as JavaScript, as ubiquitous as JavaScript, used professionally, can be used to control Web pages like JavaScript (so connectable for learners), and with the syntactic similarities to mathematics that Racket enjoys.
Ready
Baker Franke of Code.org is promoting the essay Coding snobs are not helping our children prepare for the future as a response to Idit’s essay. The essay is about the application-building tool, Ready. Media theorist Dough Rushkoff has also been promoting Ready, What happens when anyone can code? We’re about to find out.
I disagree with Rushkoff’s description of Ready, even in the title. As the first essay by David Bennahum (a “Ready Maker and Venture Partner) points out, it’s explicitly not about using a programming language.
Our efforts at Ready, a platform that enables kids to make games, apps, whatever they want, without knowing a computer language, are designed to offer a new approach to broadening access to code literacy.
Bennahum’s essay means to be provocative — and even insulting, especially to all the teachers, developers, and researchers who have been creating successful contextualized computing education:
In this new world, learning coding is about moving away from computer languages, syntax, and academic exercises towards real world connections: game design and building projects that tie into other subjects like science and social studies… This is the inverse of how computer science has been taught, as an impersonal, disconnected, abstracted, mathematical exercise.
I can see how Rushkoff could be confused. These two quotes from the Ready team seem contradictory. It’s not clear how Ready can be both about “learning coding” and “code literacy” while also allowing kids to make “without knowing a computer language.” There is no programming language in Ready. What is coding then? Is it just making stuff? I agree with Rushkoff’s concerns about Ready.
True, if people don’t have to code, they may never find out how this stuff really works. They will be limited to the programming possibilities offered by the makers of the platforms, through which they assemble ready-made components into applications and other digital experiences.
Let’s consider Ready against the five principles I propose.
- Connect to what learners know – the components of Ready are the icons and sliders and text areas of any app or game. That part is probably recognizable to children.
- Keep cognitive load low – Ready is all about dragging and dropping pieces to put them together. My guess is that the cognitive load is low.
- Be honest – Ready is not “real” in most sense of authenticity. Yes, students build things that look like apps or games, but that’s not what motivates all students. More of Betsy DiSalvo’s “Glitch” students preferred Python over Alice (see blog post). Alice looked better (which appealed to students interested in media), but students knew that Python was closer to how professional programmers worked. Authenticity in terms of practice matters to students. No professional programmer solely drags and drops components. Programmers use programming languages.
- Be generative and productive – Ready completely fails this goal. There is no language, no notation. There is no tool to think with. It’s an app/game builder without any affordances for thinking about mathematics, science, economics, ecology, or any other STEM discipline. There’s a physics engine, but it’s a black box (see Hmelo and Guzdial on black box vs glass box scaffolding) — you can’t see inside it, you can’t learn from it. They build “models” with Ready (see this neurobiology example), but I have a hard time seeing the science and mathematics in what they’re building.
- Test, don’t trust – Ready offers us promises and quotes from experts, but no data, no results from use with students.
Ready is likely successful at helping students to make apps and games. It’s likely a bad choice for learners. I don’t see affordances in Ready for computational literacy.
Entry filed under: Uncategorized. Tags: computational literacy, computing for all, K12, programming languages.
Computing Ed Research - Guzdial's Take 
1.
Dorian Love | June 20, 2016 at 8:07 am
Reblogged this on The DigiTeacher.
2.
alfredtwo | June 20, 2016 at 8:37 am
This seems like a great lens to evaluate languages for teaching. I just wish there were research on more languages as teaching tools to help us.
3.
Austin Cory Bart | June 20, 2016 at 11:10 am
Regarding “Be Honest”: How do students perceive the authenticity of a language? How do students perceive the authenticity of a class context? How accurate are these perceptions? To what extent can we affect these perceptions, and to what extent SHOULD we affect them?
I think many non-CS major students have little domain-identification. When they do, they may not understand how computing connects to their future potential career. As instructors, part of our teaching should be about the benefit of what we teach, even if students don’t recognize it initially. They may have some ideas about the authenticity of blocks vs. text, and the authenticity of games vs. financial software, but I don’t think there’s much nuance there. What does this mean for environments like GP, which push authenticity in different ways?
I’ve been working on a SIGCSE paper that touches on Context vs Content, and one of our survey results that surprised me was that students intent to continue learning CS seemed to be highly correlated with their sense of the usefulness of learning to program, but not with their sense of the usefulness of the context of the course (data science, in our case). I am very curious about whether that result is replicated this fall with a bigger student population, and the bigger question of how students feel about the authenticity of what they’re learning. Definitely reminds me of your Imagineering paper.
4.
Mark Guzdial | June 20, 2016 at 12:49 pm
Agreed, Austin — the issues you’re exploring are related to our Imagineering paper, and also Lana Yarosh’s paper about our follow-up Media Computation data structures course. My book explores these issues and tries to explain them in term of Lave & Wenger’s communities of practice.
5.
Andy Ko | June 20, 2016 at 1:57 pm
The other factor behind cognitive load and libraries are the tools available to reduce the cognitive load inherent in the language. For example, there are many JavaScript linters that will warn learners about confusing and error-prone parts of the language. If these were built in to an editor, some of these issues are mitigated. The same is true for libraries that remove the need for looping. For example, lodash and underscore are widely used libraries that encapsulate loops, instead allowing learners to reason about lists and list operations, in ways very similar to Lisp. The larger point here is that some languages can be used in certain ways that reduce load.
6.
Mark Guzdial | June 20, 2016 at 2:08 pm
I agree that libraries and tools can reduce cognitive load. There’s a trade-off with authenticity. One of the common complaints that I get about the use of Jython in our Media Computation class is that (a) we’re not using CPython and (b) we’re using add-on libraries. Many CS teachers want students to learn Python as God or Guido intended. Python and its standard libraries are taken as gospel truth, and anything in addition (e.g., implementing Python in Java, building on media libraries) is no longer teaching the “real” thing.
7.
Kathi Fisler | June 20, 2016 at 2:32 pm
The textual-vs-blocks argument is clearly about syntax. The Ready vs “standard” coding argument (for lack of a better term right now) is much more about which learning objectives to target, but those objectives aren’t being articulated. To make sense of something like Ready as a pedagogic tool, we have to think about what concepts students might learn from using it.
For “standard” coding, there’s a fairly common set of objectives,
based around “selection, iteration, and branching” (this is narrow,
but reflects the baseline that I hear many people articulate). If we
give students higher-level components and connections, they
potentially learn different-but-also-useful skills.
For example, what if students learned how to think about a
recognizable (smartphone) app, figure out what the database would do, what a UI would do, and so on. There are still very useful CS-oriented lessons in understanding this sort of system
decomposition. We just haven’t articulated more concretely what those lessons might be (or how they compare to the objectives from standard coding education in terms of suitability for students, load, authenticity, etc).
We shouldn’t frame any of these discussions only in syntax, whether
explicitly or implicitly. Being explicit about the learning objectives in more component-level system design would help shift the discussion to a more useful level.
Kathi
8.
Mark Guzdial | June 20, 2016 at 2:40 pm
Kathi, did you read Ben Shapiro’s CACM Viewpoints piece, where he argues that blocks-vs-text is about more than syntax?
I don’t see that these five principles are only about syntax. Honesty/authenticity is about far more than syntax. Being generative and productive has nothing to do with syntax. I’m not sure how you got to that reading.
Absolutely, understanding how the UI and database work together in an app is super useful. It’s not programming, though. I totally see that Ready is useful for highlighting those issues. I’m explicitly interested in the learning objectives related to computational literacy and using programming as a medium. Ready doesn’t help with those.
9.
Kathi Fisler | June 20, 2016 at 4:40 pm
I never said that your 5 principles are focused on syntax — they aren’t, and that’s terrific. Ben’s work in general is a nice example of how we need to think about the abstractions and what students can learn from them. I read the Ready piece as framing itself around syntax rather than abstractions, but the abstractions are actually where the interesting pedagogic discussions lie.
There’s a spectrum from lower-level coding (variables and loops) to higher-level composition and configuration (ala Ready). I don’t know where we cross the “computational literacy” line within that spectrum, but that’s something I’m certainly confronting in thinking about planning and (de)composition. I expect most would agree that expressing a program as a composition of expressions and library functions counts as programming — that is, until the abstractions get rich enough.
As Ben’s work illustrates, the right abstractions enable students to do some pretty interesting and authentic things. So clearly, the abstractions matter as we evaluate languages with respect to learning. But they can also go farther than some would like, thus removing “programming” from what’s left. Where’s the boundary? How does it play into your (all solid and valuable) principles?
10.
Mark Guzdial | June 20, 2016 at 7:27 pm
Thanks, Kathi — these are great questions. I don’t have a great answer. My hunch is that the answer is related to the big questions that started our field. What Alan Turing (and Bertrand Russell and others) were asking was, “What is computable? What is the core set of ideas that are generative and productive across the rest of mathematics?” We should hope to teach students a notional machine or a set of abstractions (whether procedural, functional, or higher-level abstractions) that are generative and productive in a similar way.
11.
gflint | June 20, 2016 at 2:36 pm
I really like your 5 principles. I am building an introductory game programming course for high school Freshman thru Juniors. There were so many options out there that I was a bit over whelmed at first. My first though was teach Unity but after trying to learn it myself the cognitive load was a bit high. I eventually decided on GameMaker and it fits your 5 nicely. Although it is a pure game making platform the Gamemaker Language (GML) is very C/Java/Python like. To get kids interested and still teach something relevant is a fine edge. Industrial languages are almost guaranteed to turn beginners away for CS and programming. Languages like Logo, Small Basic and Gamemaker can temp kids that would normally shy away from CS into taking a chance with a course. Too many CS teacher want only to attract the top 1%-ers into their CS/programming courses. The 5 principles sort of bring things into focus for building a course or a curriculum to suit all levels of kids.
12.
astrachano | June 20, 2016 at 4:22 pm
Mark — in my opinion your lens may be reasonable, but you’ve employed it with your own, necessarily biased lens. You’ve got a mea culpa in the phrasing below, but it’s not really enough. You use “I don’t know” twice, but perhaps your readers might interpret this as “I’m one of the world’s experts here, and I don’t know, so it’s highly unlikely that”… (just sayin’)
Be generative and productive – I don’t know if JavaScript would be generative and productive for students. I don’t know anyone teaching JavaScript as a way to teach significant ideas in CS or other STEM disciplines.
Nick Parlante has been using JavaScript as part of his Mediacomp version of CS 101, e.g., see http://cs101.class.stanford.edu/ for many years. We modified his JavaScript libraries to create the first course of our specialization on Coursera: https://www.coursera.org/learn/duke-programming-web and the Code.org AppLab environment uses JavaScript https://code.org/educate/applab
That’s at least three programs that I think are each trying to teach significant CS ideas using JavaScript.
13.
Mark Guzdial | June 20, 2016 at 7:38 pm
The type of analysis I’m using here is heuristic evaluation (https://en.m.wikipedia.org/wiki/Heuristic_evaluation). I’ve offered a set of principles, and used my own biased perspective in evaluating the programming languages against those perspectives. All heuristic evaluations are biased.
That you can teach significant CS concepts is important for Principle #3, “Be honest.” I agree that JavaScript is good for that. You’re quoting from the discussion on Principle #4, “Be generative and productive.” Do students use JavaScript in these classes to explore ideas in mathematics, statistics, physics, biology, economics, or any other STEM discipline? Do students use JavaScript in these classes in order to answer questions that the students have that aren’t about computer science? That’s what I mean by generative and productive. I would be interested to hear about efforts to use JavaScript in that way, where it’s being used as a notation to express and explore ideas — I’d appreciate any pointers you could share.
14.
techielit | June 20, 2016 at 9:26 pm
I’m excited to use Code.org’s AppLab with my students next year. It blends the best of block-based coding with Javascript. Students can flip back and forth between blocks and text with a simple click. I found while using it that students are weaned from the controlled block-based editor naturally, as they eventually find working in the text editor easier to tweak. It’s really the best of both worlds.
15.
Guy Haas | June 21, 2016 at 2:15 pm
JavaScript has a few weaknesses for use as an introductory text-based language. I’ve been converting a bunch of Java applets (that no longer run in Chrome) to JavaScript. In the back of my mind I was thinking about writing a lesson about converting a Logo program into its JavaScript equivalent. In addition to the equality thing mentioned, it’s scope rules are a bit odd – would be hard to teach. Also, I think the quality of error messages is important for early learners. I’ve found that many times, especially when doing graphics in a web page , programs with errors often don’t get any error messages – the program just doesn’t work. So, my experience so far does not support its use as an introductory language, which is sad because of its ubiquity.
16.
Kathi Fisler | June 21, 2016 at 3:00 pm
Pedagogically-aware error messages are definitely an issue that should make Mark’s list of principles (2nd edition?). Error messages should be reported within the concepts/notional machine that students already know. This is an issue when people try to subset a professional language for use with beginners — the errors often leak outside the subset, thus breaking the limited language that the instructor sought to provide.
Kathi
17.
Mark Guzdial | June 21, 2016 at 3:48 pm
We could make error messages their own principle. I think of them as being part of cognitive load. If your program doesn’t work and you’re not given a useful error message, that increases cognitive load. If your program doesn’t work and you get an error message that speaks to you in the notional machine that you know, then your load is decreased.
18.
Kathi Fisler | June 21, 2016 at 5:15 pm
I agree that cognitive load is a useful lens through which to think of error messages. I called them out as potentially a separate topic because of the potential notional machine mismatch between languages and error messages, which goes beyond load. Errors span both load and notional machine issues.
19.
OTR Links 06/26/2016 | doug --- off the record | June 26, 2016 at 1:31 am
[…] How to choose programming languages for learners: Reviewing JavaScript and Ready | Computing Educati… […]
20.
Baker Franke | July 1, 2016 at 11:30 am
Would just like the record to show I wasn’t really “promoting” the essay about coding snobs 🙂
I happened across it and thought I’d inform the CS Ed Forum on FB of its existence and as a counterpoint to Idit’s essay.
I do agree with the germ of the idea though: that often our (CS Educators’) enthusiasm for “hard core” coding is a turn off to new learners.
21.
Kylie Docherty | July 11, 2016 at 6:01 pm
I use JavaScript for teaching CS to seniors but the simplified version I use for juniors is Processing2 (free download from processing.org). Processing is a java like language with lots of in-built libraries that reduce the cognitive load. it is also very similar to the Arduino programming interface. The main problem my students have with JavaScript is getting the hang of the debugging tools. Without the compile step to weed out errors, it is very frustrating when one syntax error makes the whole script stop working. Processing2 however does have a compile step with sensible error messages.
All the kids want to learn JavaScript because they know it has relevance in the workplace and many have already started their learning journey with some of the free online JavaScript courses available. I can teach basic generic programming principles and structures with an algorithms unit and then provide code snippets for students to adapt and integrate. This scaffolding is another way of reducing the cognitive load. Other schools use colour coded algorithms to help students see connections between the algorithm and the syntax. I think this is a good idea and plan to introduce this to junior programming classes.
22.
How do we move forward in CS Ed and not just retrace the past? | Computing Education Blog | January 11, 2017 at 7:01 am
[…] (Yes, I have a license for Livecode, but it’s not the same interface as HyperCard.) Etoys still runs on everything, but it’s a rare exception. It’s important to make progress that we build on the past, […]
23.
Why do so few schools try LiveCode? We let industry dictate our tools | Computing Education Blog | November 10, 2017 at 7:01 am
[…] I’m an old HyperCard programmer, so I like LiveCode. LiveCode does very well on the five principles I suggest for picking an educational programming language. The language is highly readable, and was actually designed drawing on research on how novices best understand programming. It’s easy to put together something that looks authentic and that runs on virtually any platform — much easier than Python, Java, Scratch, Blockly, or any of the other top five most popular teaching languages. Authenticity is often engaging for students. […]