JavaScript Isn't Scheme

http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/

by munificent • 13 years ago

197 108 13 years ago

journal.stuffwithstuff.com

skyhvr• 13 years ago

Beautiful.

jliechti1• 13 years ago

Part 1 of Douglas Crockford's On JavaScript gives a really nice history of the many programming languages leading up to JavaScript.

Chapter 1: The Early Years: http://www.youtube.com/watch?v=JxAXlJEmNMg

Chapter 2: And Then There Was JavaScript: http://www.youtube.com/watch?v=RO1Wnu-xKoY

scrabble• 13 years ago

I was thinking the same thing while reading the article.

JS has inherited from both Scheme and Self.

dschiptsov7• 13 years ago

JS might look like Scheme (can't imagine what shall I smoke) only to those, who never managed to learn the later.)

But people like to repeat slogans without understanding. This is how everyone is calling Clojure a Lisp, for example, while it is a language of its own, which happen to use parenthesized syntax.)

It is not parenthesis that makes a language Lisp. It is not first class functions that makes it Scheme.) Lisp/Scheme is a set of conventions/features, and when some are broken and other are missing that means it is something else.

TeMPOraL• 13 years ago

This is how everyone is calling Clojure a Lisp, for example, while it is a language of its own, which happen to use parenthesized syntax.

Well, the official website doesn't help much by itself calling Clojure a (dialect of) Lisp.

http://clojure.org/

The only other time I heard someone saying "Clojure is not Lisp" it wasn't in order to say something nice about the former.

hkolek5• 13 years ago

I agree, but I'm wondering what you think is missing or broken in Clojure to prevent it from being a Lisp? Sure, it sits on top of the Java type system and one major thing I can think of that is lacking is the condition system (although, isn't this a only Common Lisp thing?). I don't think it has to be Lisp all the way down to be a Lisp dialect, if that's what you're getting at.

anonymoushn2• 13 years ago

Every other Lisp happens to have TCO, so if you try to port other Lisp programs to Clojure you generally get stack overflows.

dschiptsov7• 13 years ago

http://karma-engineering.com/lab/wiki/Clojure but, this is only quick review.

It is possible, for example, to go through some books, especially "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code, and make explicit commentaries on all the subtle differences, but I'm not going to perform such a tedious task for free.)

ddellacosta• 13 years ago

At the risk of feeding a troll, a bit of reading comprehension and critical thinking 101: regardless of whether or not you personally consider Clojure to be a Lisp, this is outside the discussion of the article. The home page for Clojure explicitly states "Clojure is a dialect of Lisp."

This is in contrast to JavaScript, whose creators never claimed it was Scheme or even a dialect, although the author of the article suggests it was influenced Scheme. In addition, he has perceived that lately, many people claim JavaScript is Scheme, and he rejects that claim.

Disputing the validity of Clojure as a Lisp is orthogonal to the subject of the article.

bwy• 13 years ago

This is absolutely insane. I don't even know how it got to the point that an article was necessary to explain this.

pjmlp• 13 years ago

I started coding in a Timex 2068, back in 1986, I keep getting surprised with one needs to explain nowadays to youth generations, given the amount of available information about computing in general.

danielparks5• 13 years ago

I asked on the author’s site as well, but I don’t understand the argument that JavaScript doesn’t have lexical scoping.

http://c2.com/cgi/wiki?LexicalScoping

cobbal• 13 years ago

It probably refers to the fact that variables by default are global. If you prefix them with var they're function scoped, but there's no way to make them local to the curly braces of an "if" statement.

In scheme, lexical scoping is easily accomplished through the let form, and it's pretty hard to make a variable global by mistake.

So yes it does have lexical scoping in the sense that function arguments are lexically scoped, but that's the only scoping environment, and you can't hide that fact behind macros like you could in scheme if it was needed.

hayksaakian• 13 years ago

Did you notice that "let" is coming in through ecmascript?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

mistercow4• 13 years ago

If you prefix them with var they're function scoped, but there's no way to make them local to the curly braces of an "if" statement.

There is; it's just ugly. You just have to use an immediate function as the body of the if statement.

danielparks5• 13 years ago

That’s roughly what I was thinking, but it seemed a little ridiculous to me — Javascript has lexical scoping, it’s just not required.

It seems like this argument conflates lexical scoping with the requirement that variables be lexically scoped. Lexical scoping (even if optional) is extremely useful for closures. Requiring lexical scoping would very useful for safety.

anonymoushn2• 13 years ago

I assume he means that Javascript has lexical scope at the function level, rather than at the block level. It is much nicer at the block level, both for human users of the language and for optimizing JITs.

danielparks5• 13 years ago

Ah, right, cobbal mentioned this, too. I hadn’t thought of that — I’m used to languages without that feature.

(To be strict, that seems to be more a matter of what a scope is, rather than if the scoping is lexical or dynamic.)

ufo2• 13 years ago

Javascript has C syntax but does not follow the C tradition of having one scope per block, instead having one scope per function. This is really unintuitive if you are used to how lexical scoping is done in other C-like languages and is the source of many common annoyances, like the closures-in-for-loops bug or needing to wrap your code in IIFEs[1] if you want to create a local scope or prevent variables from being global.

[1] - Immediately Invoked Function Expressions: (function(){ ... }())

munificent7• 13 years ago

Lexical block scope is broken in (at least) three ways in JS: the global object and with() break lexical scoping, and hoisting breaks block scoping.

Strict mode in ES 5 does address the first two, and "let" in ES 6 addresses the latter, so that's good. But at that point, you're talking about the future and not JavaScript as it is today.

jrochkind1• 13 years ago

It's true because it's funny.

kragen15• 13 years ago

On one hand, it's true that Scheme has a lot of things JS doesn't, and vice versa; and the feel of the languages is very different. On the other hand, it's completely clueless to claim JS doesn't have lexical scoping. Only someone who didn't understand what the alternatives to lexical scoping were could claim that.

mistercow4• 13 years ago

In particular I was bothered by the author's separation of scoping and closures. For example, if you look at what Objective-C has in terms of closures, and what JS has, then you're practically looking at completely different animals. But if you just say "closures ✓", "perfect lexical scoping ✗", you completely miss that point.

zeckalpha• 13 years ago

Take a look at the author's toy language for the rationale for the separation: http://magpie-lang.org/

gsg4• 13 years ago

Quite the contrary. Javascript has a strange, ugly hybrid of lexical and function scope that is not that of Scheme, which I suspect that Bob understands very well given his interest in languages (and that he works on a language that compiles to JS).

This is not lexical scoping:

    function example(k) {
        function ugly() {return i};
        for (var i = 0; i < k; i++) {}
        return ugly;
    }
    example(4)() // => 4

danielparks5• 13 years ago

What is it that you don’t like about this. Is it that the var is hoisted?

http://www.adequatelygood.com/JavaScript-Scoping-and-Hoistin...

Hoisting generally seems ugly to me.

Edit: I think there is some confusion here about scoping. One axis is dynamic versus lexical scoping (are there other options?). Another axis is function, block, global, etc. scope. They seem orthogonal to me.

kragen15• 13 years ago

Yes, the scoping in your example is lexical. That's why ugly returns k regardless of where you call it from; we can reason lexically to show that.

The i in ugly is lexically resolved to refer to a particular declaration, the one on the line below it. Scheme's lexical scoping rules are not the only possible lexical scoping rules. A lexical scoping system does not cease to be lexical simply because it is not the same as Scheme's lexical scoping. For it to be non-lexical, the scoping would have to depend on something other than the lexical structure of the program. For example, you could just as well have a dynamically-scoped JS in which ugly's return value would depend on its caller's binding for i, and in which calling a function with a free i from within example would make example's binding for i visible to that other function, but that isn't the way JS works.

It's quite reasonable to argue about whether that scoping is sane, and indeed with "let", the ES folks are giving us a saner binding construct; but it is certainly the case that the relationship between the declaration and the use of a variable is established by the lexical structure of the program text, not the dynamic structure of the executing program.

munificent7• 13 years ago

I'm pretty sure I understand lexical scoping, and this ain't it:

    function foo() {
      window.c = "really?"
      d = {};
      function bar() {
        var a = "var";
        {
          with (d) {
            var a = b;
          }
        }

        console.log(a);
      }

      d.b = c;
      bar();
    }

    foo();

kragen15• 13 years ago

You are of course correct about with() being dynamically scoped; thank you. I had forgotten about with() when I wrote what I wrote. I must weaken my claim to "JS is lexically scoped, except for the with() construct."

Homunculiheaded2• 13 years ago

I learned JavaScript before "The Good Parts" was printed and more importantly after I had been writing a lot of Common Lisp. I remember being really shocked and excited when I realized how much JS had in common with lisp given that my expectation when learning it was that I was in for an awful time.

I think the origins of the "JavaScript is Scheme!" meme have more to do with the fact that you can pretty trivially re-implement all of the code from the Little Schemer (including the applicative order y-combinator) in JavaScript, than any of the reasons mentioned here. JavaScript still, imho, has nicer closures and lambdas than most mainstream programming languages.

Actually, thinking back on it, I remember having a conversation with Prof. Daniel Friedman about how similar the two language are and I believe his response was something along the lines of: if you have the lambda calculus, what else do you need?

Final nitpick: most of the "Y isn't really a lisp!" (another meme) articles I've read always miss what I think is the biggest thing missing from all languages compared to any lisp: symbolic expressions. To me this is the single most underrated feature of lisp that almost no other programming languages offer.

why-el• 13 years ago

The points in the article are still not addressed in your comment. The exercises in TLS can be programmed in pretty much any one of the mainstream, dynamically-typed and lexically scoped languages (beginning with Ruby, which I have partially done). The author is right; the hype around the phrase is unjustified and js programmers should focus on the true merits of Javascript alone.

Homunculiheaded2• 13 years ago

I actually agree that the "JavaScript is Scheme!" meme is over used today. My comment was more pointing out where I felt the meme's origins had come from. It really wasn't that long ago that mentioning dynamic programming languages would get scoffed at by "real" programmers. Today, with underscore.js being pretty standard, it's trite to say "Hey! JavaScript has lambdas, closures and first class functions!" But that was not always the case.

voyou• 13 years ago

That's true, but that any "dynamically-typed and lexically scoped languages" with closures and first-class functions could be considered mainstream is fairly new. Crockford wrote "JavaScript: The World's Most Misunderstood Programming Language", which I think is the source of the idea that JavaScript is like Scheme, back in 2001. At that point, Ruby was almost unknown, Python was fairly minor, PHP didn't have closures or first-class functions; the other major programming languages were statically-typed things like C++ and Java.

So I think it's worth remembering that it's really a very recent development that we can now treat it as obvious that a language like JavaScript would contain the things it has in common with Scheme.

mistercow4• 13 years ago

The exercises in TLS can be programmed in pretty much any one of the mainstream, dynamically-typed and lexically scoped languages (beginning with Ruby, which I have partially done).

That's spurious. Anything that can be implemented in one Turing complete language can be implemented in any Turing complete language. The question is how easy it is.

danielparks5• 13 years ago

I learned Lisp after I learned Javascript, so I had the opposite experience of discovering that a bunch of Lisp-y things worked just as I expected them to.

I would never claim that Javascript is scheme (and it doesn’t sound like that’s what you’re claiming), but the things I love about Javscript are also things I love about scheme.

Is it the homoiconic-ness of the s-expressions you like?

Personally, I'd love to see continuations in Javascript, despite the potential for horrible abuse. Deeply nested callbacks are a pain in the ass. Of course, promises are a pretty decent solution.

bhashkarsharma• 13 years ago

Very well and funnily written, among other things. Thoroughly enjoyed :)

hobs2• 13 years ago

Couldnt agree more, the writing style of the author is amazing(especially considering the topic). The use of humor to make what could be a dry subject pretty damn good is a rare talent.

munificent7• 13 years ago

Thank you! I try very hard to make it worth the reader's time to read it. Humor and interesting phrasing is a big part of that.

fsck--off• 13 years ago

Scheme is even more Lisp than Lisp

That's not true. In fact, there are some prominent people in the Lisp community who do not think that Scheme is a Lisp.

See this thread from 2002 on comp.lang.lisp (especially Pitman and Naggum's comments) for more. If you are too young to have posted on C.L.L when Usenet was still popular, and want to see what a full fledged flame war looks like, look at the end of the thread.

Some people who posted there (including the OP) are on HN.

https://groups.google.com/forum/#!topic/comp.lang.lisp/Bj8Hx...

markus2012• 13 years ago

Holy smoke...

I started posting on Usenet ~1989. I've seen a number of flame fests that I considered epic but this moved the bar exponentially.

saurabh• 13 years ago

And he started it with this.

I hesitate to ask this question because I really don't want to start a flame war.

untothebreach2• 13 years ago

I got to the end of the page and thought, "Well that wasn't so bad..." -- then I saw that I was at the end of page 1...of 22.

Epic.

6cxs2hd6• 13 years ago

Civil wars over distinctions without a difference are the ugliest kind.

kragen15• 13 years ago

There are people — like Pitman and Naggum — who argue for defining "Lisp" to mean "Common Lisp" for political rather than technical reasons, essentially because they want to stop the evolution of Lisp. (Those who haven't read the thread might think I'm exaggerating.) Fortunately, they are relatively irrelevant today, and Lisps like Clojure, Hy, and Racket are carrying on the further development of Lisp.

lispm6• 13 years ago

But languages like Clojure, Hy or Racket are not a Lisp. They are Lisp-derived/inspired/... languages. That's also why they don't have Lisp in their name.

OTOH Lisps like Emacs Lisp, Common Lisp, ISLisp, and some others are still carrying the core of the first Lisp. Basically you can run Lisp 1.5 code in those without many changes.

Just like Java is not the new C. OTOH languages like C++ and Objective C still support much of C. You can port C to C++ easily.

Over the history many other languages have been trying to replace Lisp: ML (functional programming), Dylan (object-oriented programming), Logo, Scheme, ... all tried to modernize/improve Lisp. Now it is Clojure and some other languages.

Still there are core Lisp languages which carry on the genes.

But not Clojure:

    Clojure 1.5.0-RC2
    user=> (car '(1 2))
    CompilerException java.lang.RuntimeException: Unable to resolve symbol: car in \
    this context, compiling:(NO_SOURCE_PATH:3:1)

What?

    user=> (append '(1 2) '(3 4))
    CompilerException java.lang.RuntimeException: Unable to resolve symbol: append \
    in this context, compiling:(NO_SOURCE_PATH:4:1)

What?

    user=> (assoc 'foo '((foo . 3)))
    ArityException Wrong number of args (2) passed to: core$assoc  clojure.lang.AFn\
    .throwArity (AFn.java:437)

    user=> (atom 'foo)
    #<Atom@2285af04: foo>

???

Does not look like it supports Lisp processing as defined by McCarthy:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91....

Additionally the Java error messages are especially irritating. I enter Clojure code and get Java error messages.

Compare that with a real Lisp:

    bash-3.2$ java -jar abcl.jar
    Armed Bear Common Lisp 1.1.1
    Java 1.7.0_25 Oracle Corporation
    Java HotSpot(TM) 64-Bit Server VM
    Low-level initialization completed in 0.628 seconds.
    Startup completed in 1.968 seconds.
    Type ":help" for a list of available commands.
    CL-USER(1): (car '(1 2))
    1
    CL-USER(2): (append '(1 2) '(3 4))
    (1 2 3 4)
    CL-USER(3): (assoc 'foo '((foo . 3)))
    (FOO . 3)
    CL-USER(4): (bar 10)
    #<THREAD "interpreter" {6EEE1E2}>: Debugger invoked on condition of type UNDEFINED-FUNCTI\
    ON
      The function BAR is undefined.
    Restarts:
      0: CONTINUE     Try again.
      1: USE-VALUE    Specify a function to call instead.
      2: RETURN-VALUE Return one or more values from the call to BAR.
      3: TOP-LEVEL    Return to top level.
    [1] CL-USER(5):

We even get Lisp error messages. The compiler is written in Lisp. http://svn.common-lisp.net/armedbear/trunk/abcl/src/org/arme...

Clojure may be a cool language, but the core of Lisp has been replaced in parts with something else. List processing is different. It's now based on 'persistent' lazy sequences...

DanWaterworth• 13 years ago

Haskell doesn't have first-class continuations, it has syntactic sugar that allows you to write continuation passing code in a direct style.

EzGraphs• 13 years ago

The main reason the comparison between JavaScript and Scheme is helpful is that it breaks the connection between JavaScript and Java. The first thing many Java programmers do when trying to write JavaScript is to try to create a class hierarchy (rather than using prototypical inheritance) using idioms from Java. Although possible, it ends up awkward and confusing in most cases. Understanding that functions are first-class and seeing functional idioms fall out from there is a big paradigm shift for Java devs.

Obviously JavaScript isn't Scheme using the author's "top 10 defining characteristics of Scheme." Crockford's analysis is on track - and John Resig and Bear Bibeault highlight the same idea by introducing functions are really fundamental to the languages more than objects (in "Secrets of a JavaScript Ninja").

The language's history does imply the comparison as well. Eich's original mandate was to "write Scheme for the browser" but he was later directed to give his language a C-like syntax and to ride on the coat-tails of the hype surrounding Java.

"JavaScript isn't Scheme" might not be accurate for folks schooled in the finer points of Scheme. It is very useful to those who cut their teeth learning Java.

dmpk2k• 13 years ago

We might just as well claim that Javascript is Perl then. Javascript has a lot more in common with Perl than it does Scheme; those things that both Javascript and Scheme have in common are also common in many other languages.

Anyone trying to draw parallels between Javascript and Scheme isn't crossing some pedantic line, they're off in crazyland. Or, more likely, they don't understand both languages as well as they're implying.

munificent7• 13 years ago

    it breaks the connection between JavaScript and Java.

This is a good point. The defining characteristic of Scheme in the minds of many is really just closures. Almost every modern language except Java has those, so "Scheme" has inadvertently turned into a weird shorthand for "inverse of Java".

I think that's too blunt of an instrument to help you reason about any of the languages in question, but I do appreciate encouraging people to think functionally.

mnemonicsloth• 13 years ago

Google "brendan eich javascript scheme". Result #1 is from Brendan Eich's website:

I was recruited to Netscape with the promise of “doing Scheme” in the browser...

I’m happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients.

https://brendaneich.com/2008/04/popularity/

So "JS=Scheme" is not very crazy. Maybe it oversimplifies. But it's not baseless. And it's short.

etler• 13 years ago

This article is based on the assertion that there are people that think Javascript is Scheme with an ugly makeover. But do those people exist? Most people who make the comparison aren't saying they they're equal to each other, but that they share similarities. Maybe some people hear that out of context and take it too far, but I don't think they're the majority.

I think the thing that makes the comparison is more the first class functions than the closures. The closures assist the first class functions, but the functions are the star.

Not a whole lot of non functional programming languages support first class functions with the simplicity and completeness of javascript.

http://en.wikipedia.org/wiki/First_class_function#Language_s...

In javascript, passing functions as parameters is a day to day thing, and that style of being able to pass around different functions as building blocks is what gets it compared to functional languages. Sure, that's not the only thing that functional languages have going for them, but it's the most important thing, and what they're even named after.

JavaScript Isn't Scheme

Related Stories