Javascript is not Scheme

Nor is it Logo. Logo also isn’t Scheme.

Scheme’s recursive logo.
(display (list 'foo 1 true)) ;; prints (foo 1 #t) to the screen
  • In Scheme, the function definition and invocation have nearly the same basic form. Technically, define is a “special form” (as is cond), but for our purposes here that’s not really an issue; that means a semantic, not a syntactic, difference. The definition of a function effectively looks like a call to a function. And the conditional construct cond is also syntactically identical to a function invocation. The test for equality is a normal function, and looks identical in its invocation, with the exception that the function name is a symbol instead of a word: (= n 1). Basically, there are only S-expressions that are all syntactically identical. The complexity of the behavior comes from combining them by nesting them in interesting ways. But the nesting is deep! The define expression ends with six (!!!!!!) close parens.
  • In the ES6* version, the code is a lot shorter. It’s a single line! But it’s a long line full of punctuation. This is a fairly common coding style in JS these days, and it reads really nicely if you know what you’re looking at. (It is also the style in which I am most comfortable.) But you’ve got all these glyphs (=>, ===, ?, :) doing basically all of the work: function definition, argument-passing, testing for equality, and conditionally returning a particular value. For parentheses, we have substituted a whole gobbledigook of ASCII.
  • In the ES5* version, we still have some strange punctuation (two forms of brackets: () and {}; JS also uses []). But more than anything else, we have language keywords — function, if, else, return—that don’t work like user-defined functions. This might be easier to read since it’s closer to English (maybe) but it also means developing different mental models for the different “parts of speech” of the language (and which brackets belong to them). This version reasonably closely resembles function definitions in languages like Java and C.
We’ve been making subsets of JS for a long time. Uncle Doug leads the way. And this was *before* the ES6 additions to the language.
  • Those two JS versions look almost nothing alike, but they’re part of the same language and do (almost) exactly the same thing. There are no fewer than five ways to define a function in JS, and they’re not all semantically equivalent. It’s way too much to handle for students early in coding. Hell, it’s enough that people are complaining that the language is becoming too big for professional developers and can we please stop adding things to the language already. One of the most important questions a teacher of JS or almost any other mainstream programming language must ask is: what subset of the language will we use? Why? (Often the answer is: the stuff that looks most like Java and C, because that the part of the language the teacher learned first, and so has a mental model, if only an implicit one, of how to teach and learn it.)
Ludwig Wittgenstein, fellow traveler of Alan Turing and destroyer of the concept of private languages.



A research blog on media theory, the history of Logo, and teaching programming to kids and university-level humanities students

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store