Skip to content

Instantly share code, notes, and snippets.

@ar5had
Forked from rtoal/JSFirst.md
Created May 11, 2017 15:51
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ar5had/dd1a4d4925489833cc48f00dfb1e9c2a to your computer and use it in GitHub Desktop.
Save ar5had/dd1a4d4925489833cc48f00dfb1e9c2a to your computer and use it in GitHub Desktop.
JSFirst

JS First

About This Manifesto

Have you ever argued for or against teaching language X as the first language in a university computer science curriculum? If so, I hope that your arguments:

  • were first and foremost about students, not about your personal language preferences (in other words, you should answer the question “What do we want students to gain from their experience with a first language?”, not “Is language X better than language Y?” because people hate that latter question);
  • kept in mind that ultimately we want to train polyglots, so the first language is never the only language; and
  • took into account previous work from computing educators, and education theorists and practitioners in general.

I've taught introductory programming courses at the university level on and off since 1986 and have used Pascal, Modula 2, Ada, C++, Java, and, since 2009, JavaScript. Colleagues at my university have also used Python, Racket, and MATLAB as first languages. My first programming language was HP-65 machine language (I was 11 years old and didn’t know any better); as far as I know it did not cause me brain damage.

Why JavaScript FIRST?

We want students to learn and love computer science. Acquiring programming skills helps the field become alive for them, and allows them to make their own contributions to the wealth of human knowledge. To give them this enjoyment, we have to kindle their interest early and keep them from getting discouraged. I’ve found that starting with JavaScript (at least as opposed to Java or C++) helps. In no particular order, here are things I consider to be in JavaScript’s favor as a first (CS1) language:

  • No batteries required. There’s nothing to install to write JavaScript: no compilers, no IDEs. Visit CodePen or JSFiddle, or even open up a browser’s console, and just start programming!

  • Students can follow along with you. On sites like JSFiddle you can code a little and share a URL, then students can add their own changes at a fresh URL which you can then project to the class. When a nice solution to a seemingly hard problem comes up, students have been known to clap for each other.

  • You can write “fun” code, with graphics and animation, on day one (with no special tooling). In my own CS1 course, we make simple pictures and animations with Khan Academy Computer Programming. Students grow the examples into a solution to their first assignment that says only "Make the plane land." I’m often amazed with students’ creativity here. Sometimes the plane comes in from the side, sometimes head on, and once the plane looked like a character from a Mario Brothers game. But everyone solves the problem. And they feel good for doing something interesting on their very first day of class. Confidence!

  • It’s NOT the language of high school AP Computer Science. A Java-based introductory computer science course with a mix of first-time programmers and AP CS veterans risks some of the first-timers feeling intimidated by the veterans, and risks veterans being overconfident. Granted, a JS first class may have incoming freshmen with previous JavaScript experience; if so, you might want to take an approach like Harvey Mudd College’s Green-Gold-Black courses.

  • You can show localized numbers and dates with one line of code, also on day one!. Here’s something I’ve shown in class, that had the nice effect of giving Arabic, Chinese, and Hindi speakers, as well as students from countries with differing date formats, warm feelings of familiarity. Run this in a browser:

    const x = 16529385600.75;
    alert(["en-US", "es-ES", "es-MX", "ar-EG", "hi-IN"].map(locale =>
      `${locale}: ${x.toLocaleString(locale)}`).join('\n'));
    const date = new Date(2016, 08, 15);
    alert(["en-US", "zh-SG", "en-GB", "zh-CN", "ar-EG", "hi-IN"].map(locale =>
      `${locale}: ${date.toLocaleString(locale)}`).join('\n'));
  • No(t much) magic to hand-wave away. Here I am picking on Java again, because Python and Ruby can do a nice Hello World, but really, what beginner wants to look at public static void main(String[] args)?

  • It is one of the most popular programming languages in the world, and it runs on every device: laptop, Android, iOS. You can write lovely JavaScript programs on Android (you don’t need Java) and lovely JavaScript programs on iOS (you don’t need Swift). Will the native programs look better? Uh, have you remmbered that we are only talking about a first language? You can learn plenty of other languages soon enough. With JavaScript, though, students will know they are learning a real-world language, which often makes their parents happy. It’s one of those languages that helps them get a job.

  • It has first-class functions and closures for Chrissake. No explanation needed for this one! (Of course, you need to know how to teach this stuff to beginners, so use care if you take a recursion-first approach). With a little practice, you can learn to program (and teach) JavaScript in a predominately immutable way. Do you think that languages-that-help-you-get-a-job are mutually exclusive from languages-that-provide-a-good-CS-foundation? Provided you stick to the good parts of JavaScript, you get some good overlap.

  • Asynchronicity and Events! Back to putting all students on a somewhat equal footing in CS1: My favorite first-week experience is when, introducing animation, I ask the students “how do we move this airplane (or balloon) across the screen?” and some will shout out “For loop” or “While loop” and I get to say ”Actually, that’s a nice idea, but that’s not how we do it.” This is one of the hot shots’ first experiences in things being done in a radically different way from what they were previously taught. In JavaScript the system (the animation engine) calls your code at the right times. This mindblowing insight (for many students) is just beautifully, natively, wired into JavaScript. No listener or observer interfaces required.

  • It’s Flexible. Just write array literals and object literals; you don’t need a schema. Did I just say I prefer dynamic typing? Of course not. What am I getting at? I want the static things to come later! I want them to experience the fun of making an object or a list (and perhaps animating something), and only after they have done that, generalize. Where is the fun of building, or designing, up-front, a class (with getters and setters, ugh!) before being able to do anything? Doing such a design first does a disservice to the bricoleurs in your class. What is a bricoleur? You need to read Turkle and Papert’s Epistemological Plurarlism to find out.

  • Unit Testing is Probably Much Easier to do than You Think. Check out what I did here?

  • It naturally teaches separation of concerns. Computing educators know about computing principles. One is separation of concerns. When you do JavaScript in the browser, you naturally, almost necessarily, show students how to separate content (HTML), presentation (CSS), and interactivity (JavaScript). And oh guess what, the first two are declarative. How nice to teach beginners the ease and importance of what is essentially modeling.

But What About...?

As one of the most popular programming languages in the world, JavaScript has passionate lovers and haters. Its creator, Brendan Eich, freely admits some less-than-good design choices. There is much to poke fun at. Yes, JavaScript is featured in the famous WAT Video. Douglas Crockford’s JavaScript: The Good Parts has sections of JavaScript’s Bad Parts and Awful Parts. You can take a rigid, intolerant view and claim the language’s shortcomings disqualify it from consideration for your curriculum lest it poison your young student’s minds. Or you can be a reasonable, pragmatic, citizen of the world, and use these flaws as teaching moments. Consider:

  • Weak typing is error prone, yes, but use its potential pitfalls to talk about implicit conversion, and its dangers.

  • Dynamic langauge flexibility comes with serious tradeoffs. I’ve seen multiple students misspell constructor (as contructor) and somewhere down the line they see undefined. Have a discussion with the students to see how to prevent these errors. (Unit testing will come up!)

  • Yeah, yeah "2" + "2" === "22". Hang on, why are you concatenating strings anyway? Protip: students don’t mind string interpolation. This brings up a general point. The students will be ready, at some point, for a linter. Most of the silly WAT stuff can be caught by a linter.

  • The with statement? eval? Types-as-strings? == vs. ===? You can avoid the first three in normal code. As far as the last one goes, you can call == the similarity operator, and === the equality operator. a == b means a and b are similar to each other, not necessarily equal. Again, a good place to talk about types.

  • Speaking of types, have you heard of TypeScript?

Of course, language-flaws-as-teaching-moments are not unique to JavaScript. You would bring these up with your students in other langauges, too. But ask yourself: are any of these flaws so severe they are unable to be adressed at all? Can you not help your students recognize and address them? Are you giving up too easily?

Can’t Other Languages Do What JavaScript Can Do?

In 2006, Joel Spolsky wrote Can Your Programming Language do This? While certainly not intended as a treatise in favor of JavaScript for CS1, he does use JavaScript as an example of a language in which functional abstraction is easy to do (not to mention important), and links to another article of his on the danger of “Java schools” so he’s got a couple thoughts on education here: (1) A given language might make some things much easier to express than in others, and (2) Please don’t box students in with a single language.

What about JavaScript’s competitors? If you want simplicity and ubiquity, and ease of expression, Python can assist you. It’s not a bad CS1 language. But we don’t quite get the HTML and the CSS separation of concerns, we don’t get the just-get-started-in-the-browswer (Tk isn’t quite the same). We get async and await and other goodies but we need Python 3.5 and up, not to mention a bit of Python preparation. Python gives us ubuiquity on the server side, but not the client side. If we want safety and security, we have Java and C#, but these are a bit verbose: some students will not mind this but others might get overwhelmed (remember, we are talking about an intro language). Type inference to the rescue? Haskell, Standard ML, OCaml? I think we lost ubiquity.

JavaScript has a lot in its favor.

We’ll Never All Agree

I’ve just laid out a few things I like about JavaScript as a CS1 language. I’m not trying to convince anyone that it’s the best language for this purpose. I don’t even want to convince you of anything, really. Some people will agree with me and some will not. Speaking of agreement, even if we all agree that setting a good foundation for further study is a good CS1 goal, some people will say that foundation is the lambda calculus and functional abstraction (a la SICP), and others might say it is an appreciation for memory management and the connection to the underlying machine. Some will want students to learn design-first, abstraction-first; others will want students to prototype first, and work from the concrete to the abstract. Should we design experiments (with control groups) to see which of these is best? Have such experiments been done?

Here’s what we will find: that some students prefer prototyping to planning, while others prefer the exact opposite. Some students will gravitate to and love functional programming; others will prefer state-based imperative computation. One size does not, and never will, fit all.

It doesn’t have to. I’m suggesting only that JavaScript is, IMHO, a good vehicle for CS1---JavaScript + HTML + CSS, setting students on the road to becoming polygot computer scientists. Teaching JavaScript FIRST or Python FIRST or Java FIRST or OCaml FIRST or Racket FIRST or Scratch FIRST does not mean we ignore other languages. We want to choose a first language that gets students hooked rather than discouraged. We’ve seen this happen in the past with Smalltalk, LOGO, and eToys. It happens today with JavaScript: I’ve had students tell me they were glad to see JavaScript first because the early animated programs and the in-browser feedback was helpful.

Again, there are other choices besides JavaScript for CS1. While you may have a different favorite, make sure it is for the right reasons. Because if your argument is that your students are so weak that the first language they see will be forever burned into their mind, that all the bad habits and weaknesses of that first language will instill in them bad habits for the rest of their lives, then ask yourself or your colleagues how you might serve your students by preventing such a poor approach to lifelong learning taking hold in them.

(Image credit: Brendan Eich, creator of JavaScript, who often ends talks with this slide.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment