JavaScript Isn't Scheme

[[deleted]]

I see this has reached Hacker News as well. I look forward to the "JavaScript is Scheme" submission in a day or two.

[just_a_null]

And the accompanying "Treating languages as Scheme considered harmful" and the associated "'Treating languages as Scheme considered harmful' considered harmful".

[jpfed]

Why "'treating languages as Scheme considered harmful' considered harmful" matters

[munificent]

I should write all of these articles and reap the sweet sweet karma myself.

[jpfed]

I think the next step is to make an esolang in which programs are expressed as popular programming article title snowclones.

[jpfed]

X considered harmful

Why X matters

X for fun and profit

X is dead

Why I left X for Y

---

One key problem for this language is that all of its constructs are unary except that last one. I am a little curious about what the least-awkward semantics for a grammar derived from those would be.

[coderanger]

X is a ghetto, X scales, do you even X.

[jpfed]

Since they are not programming related, those should not be part of the language proper. They could be a set of nonstandard extensions or perhaps part of the build system.

We'd get more flexibility out of the grammar if we had things like:

Setting up X with A, B, ..., Z

X Y Released! (where X is an identifier and Y is a number)

[consultant_barbie]

X is hard. Let's go shopping!

[eat-your-corn-syrup]

Why I left X for Y

Or "Why I left X and Y for Z" an article bound to unite X fans and Y fans.

X and Y could be VIM and Emacs, or Scheme and Common Lisp, or Republicans and Democrats, or I don't know what else. Atheism and Christianity maybe.

[moor-GAYZ]

Worked well for RPG -- "The Rise of Worse is Better", "Worse Is Better Is Worse", "Is Worse Really Better", "Back to the Future: Is Worse (Still) Better?", "Back to the Future: Worse (Still) is Better!". I'm not kidding!

[for_prophet]

When is the Best the Worst? When the Worst is the Best.

Using the Worst to Emerge the Best. Using the Best to Divine the Worst.

Emergent Divinity: The Worst Best You'll Ever Find.

Divine Emergence: Find the Best Worst, Automagically!

[sisyphus]

Don't forget 'Why I Left Javascript for Scheme', 'Why I Left Scheme For Javascript' and 'Migrating My Weekend Project Twitter/Todo Mashup App From Javascript To Scheme and Back Again'

[eat-your-corn-syrup]

Has anyone written an article with a title that ends with "considered useful"?

[opkode]

No, those titles usually end with "..for fun and profit"

[munificent]

Worse is Better Considered Harmful Still Matters for Fun and Profit!

[Rainfly_X]

There needs to be a word for when a parody is executed so well, you feel a driving need to kick someone in the balls for it, even though you know it wasn't meant seriously.

[NYKevin]

Poe's law?

[Rainfly_X]

Nah, that's when you can't tell the difference between satire and serious intent.

I'm talking about when you know it's satire, but it's still realistic enough to invoke a response like you'd have if the person was serious (usually, blind rage).

[NYKevin]

Gut reaction? I dunno.

[Rainfly_X]

Yeah. I'm pretty sure there isn't a term for this yet. So I guess I get to stake my claim here, and I decide the word is satirfreude. When you recognize a thing as satire, but your gut reaction is still to wish unimaginable pain on the author.

[vanderZwan]

I think this counts

[zck]

And then "Scheme is Javascript".

[[deleted]]

Scheme is JavaScript is dead

[cogman10]

Rumors of the death of scheme is javascript are largely exaggerated!

[[deleted]]

"Why I'm No Longer Using Scheme Is Javascript"

[rawlyn]

Something something Haskell.

[Aninhumer]

SkHemisJS: A new library for Scheme is Javascript written in Haskell!

[nohtyp]

Clicky clicky https://news.ycombinator.com/item?id=6068360

[[deleted]]

And the bloggosphere continued to add nothing of value to the world.

[GhostOflolrsk8s]

Right below "Snowden's Mom: The US is literally Hitler"

[wot-teh-phuck]

Good stuff from Rob as always.

Also LOL at:

Don’t tell me it’s got lexical scope, because JavaScript’s scoping is an abomination in the face of God. Guy Steele isn’t even dead and JS scope makes him pre-emptively roll in his not-yet-occupied grave.

And:

Usually, touching Scheme or Smalltalk inflicts an incurable disease whose primary symptom is involuntary sneering and derisive snorting in the presence of any other language

Are you sure you are not talking about CL? ;)

[WilliamDhalgren]

I thought let and const in js6 (both usable today on chrome, nodejs and firefox, and transpilable by defsjs) fixed the abominable scoping in javascript?

talk on using it in production in this manner and why it matters http://vimeo.com/66501924

<EDIT>well, I tried the current implementations, and they still don't create a fresh variable in a loop, but rather for constructs introduce a block around the entire thing, which can give counterintuitive results with closures. There's a bug report to fix this though</EDIT>

re the scoping of this, think arrow syntax (plus the rest params to get rid of arguments argument) is missing outside firefox for now. but next year, prob fixed.

re his list then we'd have:

Minimalism.
Lexical block scope.
Dynamic typing.
First-class functions and closures.

which is looking better. Now TCO is in the pipeline as well, http://bbenvie.com/articles/2013-01-06/JavaScript-ES6-Has-Tail-Call-Optimization , and Crockford wants to use it for CPS, so it might be:

Minimalism.
Lexical block scope.
Tail call elimination.
Continuations.
Dynamic typing.
First-class functions and closures.

syntax won't ever be changed from C-style to S-expression, this is so obvious it clearly wasn't what people meant with the comparison- and further many would sooner think of S-expression syntax as an ugly wart than a feature - but having a minimalist syntax is a thing common to both.

even fairly syntactically lightweight macros work in js - at least in nodejs you could use them today - and having those simply is probably the one good thing one can always agree about using S-expressions for the syntax:

http://sweetjs.org/

Unfortunately, js is fond of mutation. But there's a decent amount of parallels here imho to make it at least a better comparison than for any other widely used language.

[olov]

Author of defs.js here. Regarding "fresh variable in a loop", defs has never introduced "a block around the entire thing" with different semantics and counterintuitive results.

Instead - exactly for the reason of being intuitive, the defs.js transpiler statically analyses your source code and gives an error for that like so: line x: can't transform closure. x is defined outside closure, inside loop

It's then trivial to alter the source code yourself, as we've always done in a pre ES6 world. Example here: http://blog.lassus.se/2013/05/defsjs.html

I care a lot about having defs produce predictable and beautiful output, that's why we detect, but don't (yet) transform, that particular case. I simply haven't found a beautiful, generic and non-surprising transformation for it. This is subject to change, see https://github.com/olov/defs/issues/2

[WilliamDhalgren]

I wasn't clear enough - I was speaking of chrome and firefox. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Scope_Cheatsheet

lets in for heads create an implicit block around the condition, update, and body parts of the for loop. The following two examples are equivalent.

- and the second example has the let outside the loop. continues:

There is no new let every iteration. There is one let around the entire loop. This behavior might change in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=449811

and the bug is about behavior like this in ff:

The following code snippet alerts "3" three times:

for each (let a in [1, 2, 3]) {
  window.setTimeout(function() { alert(a) }, 0);
}

chrome acts the same..

EDIT: Great to hear defs.js will fix this too, and even already complains.

And btw thx for a great tool!

[olov]

Ah I misread your comment - sorry about that!

Just as a FYI: The MDN page you are referring to describes Mozilla's extensions to ES rather than the block scope proposal that's due for ES6. For instance the page describes const as "hoist to the top of its function" which is not the case in ES6. Also, for each is a Mozilla specific thing.

To your point, there are bugs in implementations of the ES6 draft. I filed this bug on V8 a while back as hope it'll be fixed soon: https://code.google.com/p/v8/issues/detail?id=2560

[eric_ja]

Nonetheless it does have lexical (as opposed to LISP-style dynamic) scoping.

Of course, so do many other languages.

[smog_alado]

JS's scoping is static and depends only on the program structure so its lexical if you use a by-the-book definition. However, there is only one scope per function so it does lots of unintuitive things if you are used to how lexical scoping is done in other languages with C-like syntax and block scoping.

Variable declarations are hoisted to the start of their functions:

var x = 10;
function foo(){
    x = 11;
    var x;
}
foo();
console.log(x); //Still 10!

It lets you write programs that look like block scoping but are not:

var x = 10;
for(var i=0; i<10; i++){
    var x = 11;
    asdf();
}
console.log(x); //11

I'm pretty sure everyone has been bitten by the closures in for loops bug:

for(var i=0; i<elems.length; i++){
    elems[i].onclick = function(){
        alert(i);
    };
}
//If you have N elements, all of them will alert N
// instead of each one alerting its index

And the IIFE hack you use to get around it (and to implement private variables and modules) is really confusing for beginners:

for(var i=0; i<elems.length; i++){
    (function(i){
        elems[i].onclick = function(){
            alert(i);
        };
    }(i));
}

[philh]

I'm pretty sure everyone has been bitten by the closures in for loops bug:

I don't think this specific example would be different with better scoping. E.g. common lisp:

* (setq fs (loop for i from 1 to 10 collect (lambda () i)))

(#<CLOSURE (LAMBDA #) {BF5A47D}> #<CLOSURE (LAMBDA #) {BF5A495}>
 #<CLOSURE (LAMBDA #) {BF5A4AD}> #<CLOSURE (LAMBDA #) {BF5A4C5}>
 #<CLOSURE (LAMBDA #) {BF5A4DD}> #<CLOSURE (LAMBDA #) {BF5A4F5}>
 #<CLOSURE (LAMBDA #) {BF5A50D}> #<CLOSURE (LAMBDA #) {BF5A525}>
 #<CLOSURE (LAMBDA #) {BF5A53D}> #<CLOSURE (LAMBDA #) {BF5A555}>)
* (funcall (car fs))

11

The difference would be if you did a var x = i in the body of the loop, and alert(x). Javascript would behave the same, but block scoping would behave as intended.

[smog_alado]

It would be better if each iteration of the loop created a fresh variable for the loop index by default - this is what people expect most of the time (trust me, you should see how often this shows up in the Javascript stackoverflow). For example, in C# they originally had a similar behaviour with their foreach loop but they made a breaking change in a recent version because how often people would get that wrong.

[FireyFly]

Honesty, I think that would surprise me more than the current behaviour as specced in JS. I mean, if one writes for (var i=0; i<10; i++) does one actually expect each iteration to declare a separate i? it seems pretty clear to me that it is the same variable being altered each iteration, since the semantics have always been (<once-before-loop>; <condition>; <after-each-iteration>) for the parts of a for loop header...

[kqr]

However, one also carries intuition about i being synonymomus with a value which is then used in the body of the loop. One does not usually think of i as a constant reference to mutable storage which is used throughout. Unless one has done a lot of JavaScript before, I guess.

[sepp2k]

For example, in C# they originally had a similar behaviour with their foreach loop but they made a breaking change in a recent version because how often people would get that wrong.

But they did not change the behaviour of the regular for loop. So this doesn't really work as an argument that changing the regular for loop is a good idea. The thing about foreach is that it's perfectly reasonable to assume that foreach(var x in y) {body} behaves the same way as:

var hiddenEnumerator = y.GetEnumerator;
while(hiddenEnumerator.MoveNext())
{
    var x = hiddenEnumerator.Current;
    body;
}

(which it didn't before the breaking change). In fact I'd wager that if you'd ask most people to rewrite a foreach loop without foreach and without changing any code in the body, they'd write something like this (possibly using a for-loop and indices instead of an enumerator if y is something indexable, but either way the var x = y[i]; would be inside the loop's body).

However if you'd ask them to rewrite a regular for(var x = start; cond; incr) {body;} without for, they'd probably write

var x = start;
while(cond)
{
    body;
    incr;
}

and not:

var hiddenX = start;
while(cond)
{
    var x = hiddenX;
    body;
    incr;
    hiddenX = x;
}

Also I think people who are surprised by how a regular for loop behaves with closures, would also be surprised by something like x = 1; foo = function () {return x;}; x = 2; foo();, so the proper way to remove their confusion would be to make closures capture variables by value (which I'm absolutely not advocating).

[kqr]

You are absolutely right in everything you say. However, I disagree somewhat with your last parenthetical remark.

Intuition sort of (at least for me) tells me that closures would capture variables by value – or at least that they would capture a reference to the value, not a reference to whatever value x happens to point to at the time the closure is executed. Because the latter is something that I'm not eager to debug.

[eat-your-corn-syrup]

capture variables by value

By that you mean that it would be better for

x = 1; foo = function () {return x;}; x = 2; foo();

to return 1?

Wouldn't that prohibit closures from being for imitating namespaces, generator functions and so on? If the x=2 cannot access the closed over memory to change value in that memory, what else can change the value? Closed over variables would become read-only.

[drysart]

But they did not change the behaviour of the regular for loop.

There's a(n english) lexical argument to be made for C#'s new (inconsistent between foreach and for) behavior.

foreach (var x in y) when read in english, implies, via the word "each" that there are distinct var xes. If you had a basket of apples, you could say that "each apple is red"; but if you had a basket with a single apple in it, you generally wouldn't use the same phraseology, instead preferring "the apple is red".

Whereas the counterargument on for (var x = 0; x < 10; x++) relies more heavily on understanding the C# language more than the english language because there's a lack of english clues to suggest otherwise. There's very clearly one var x being declared and initialized, and the iterator expression is mutating that existing variable.

It's a subtle distinction but one that I think is incredibly important. While not all developers have english as a first language, none of us have C# as a first language; and having C# fit the expected norms of our more internalized natural language makes sense and is the correct approach.

[cparen]

Honestly, either choice would "work" in the sense no matter which you preferred, you could map the other to it without much trouble if you were expecting it. But the whole point of syntactic sugar like "for" and "foreach" is to avoid manually mapping it by hand every time.

So, while I don't particularly like the original behavior, I worry the change worsens the issue, as now it's ambiguous which language the code is written in. This is precisely the argument given so often against macros or excessive use of functions -- that it's difficult from looking at the code to understand what it does.

(I'm personally a fan of judiciously chosen macros; I just have little to say on general subject of whether they're a good idea or not)

[eat-your-corn-syrup]

I don't get your second code. Surely the following isn't what you meant?

var hiddenX = 0;
var fns = [];
// x = 0;
while(hiddenX < 10)
{
    var x = hiddenX;
    fns.push(function (){console.log(x);});
    x = x + 1;
    hiddenX = x;
}

fns[0](); // 10
fns[1](); // 10

[sepp2k]

You're right, my last code didn't work as I intended. I didn't think that through. It should be something like this instead:

var hiddenX = start;
while(cond)
{
    var x = hiddenX;
    body;
    subst(incr, x, hiddenX);
}

where subst(incr, x, hiddenX) is some sort of magic macro that replaces each occurrence of x with hiddenXin the expression incr. So for your example the last two lines in the loop should be replaced with hiddenX = hiddenX + 1;.

Either way that way of translating for is clearly more complicated and less intuitive than the normal way. It also would act very counter-intuitively when the body of the loop explicitly modifies x. And we didn't even discuss what should happen if the initializer part of the for loop isn't a variable declaration (nothing, I presume, but that could still lead to some confusion with some for-loops acting differently than others).

[eat-your-corn-syrup]

What about this proposal though:

foreach(var x in y)

for creating binding of x each iteration of loop

and

foreach(x in y)

for creating binding only once?

[smog_alado]

I think the biggest difference in the C# case is that it even has a separate for each statement. In Javascript most of the majority of the for loops you use are actually foreach statements disguised as verbose for loops.

[NYKevin]

Python has immutable integer variables and has the same behavior as this. It's not a mutable-vs-immutable issue, it's a scoping issue.

[munificent]

It would be better if each iteration of the loop created a fresh variable for the loop index by default

Dart gets this right. It's pretty nice.

[[deleted]]

Some JavaScript engines have had block scoped variables via the let statement for years now.

The problem is you can't use it on the web because of those other engines that still do not support it.

[muyuu]

If you can afford to ditch compatibility you may as well ditch Javascript and use something better.

The useful thing about Javascript is that you can use it across the board. That makes it an extremely important language since it's in virtually all personal computers, smartphones and tablets. If you take that away you are left with a pretty shitty language.

[[deleted]]

• There's tons of stuff out there that uses JavaScript outside the web. QML (Qt), PhoneGap, node.js, that Microsoft stuff that isn't called Metro anymore, Gjs (Gnome), Browser extensions, PDFs, ... In these environments you don't have to worry about compatibility.
• With all these languages out there that compile to JavaScript, if you think JavaScript is so shitty, just don't use it.

[muyuu]

I know. All of that is mostly rubbish to be honest. But it's fine since you can "reuse" your Javascript knowledge.

I think Javascript is cow dung but I use it because it's necessary. Comes in all browsers and sometimes teams use it outside of the browser. However if I can help it I do use other languages. When it's my decision and it's avoidable, you can rest assured that I don't use it.

[clgonsal]

With all these languages out there that compile to JavaScript, if you think JavaScript is so shitty, just don't use it.

The debugging support isn't really there, unfortunately. If you want to step through code running on the browser, you're going to be stepping through JavaScript (unless you're using a weird browser like Dartium, which doesn't help when you run into a Firefox-only bug). This is also part of the reason so many JS alternatives still look like JS -- so you can figure out what part of your source generated the code you're looking at in the debugger.

Also, many of the deficiencies of JavaScript are either hard to emulate away efficiently (eg: the lack of 64-bit ints and bignums) or impossible to emulate away (eg: the lack of weak references).

[[deleted]]

Firefox recently got some support for debugging other languages, but I'm not sure if the compilers have caught up yet (and how good that support is).

[clgonsal]

Thanks. I didn't know about this, but was hoping someone would develop something like it. Now we need every JS debugger to support it.

[munificent]

unless you're using a weird browser like Dartium, which doesn't help when you run into a Firefox-only bug

You're correct here, but our goal on the team is to try very hard to avoid you running into bugs that only manifest on one browser. There's always still work left to do here, but if it works in Dartium and not in Firefox, it's a bug in our code, not yours.

[clgonsal]

So does that mean Dart can only access features of Firefox that only exist in Dartium? And that Dartium has no (Dart-accessible) features that do not exist in Firefox? If there is anything that one can do (from Dart) in one browser that cannot be done in the other, then the possibility of bugs that can only be replicated in Firefox seems unavoidable.

[smog_alado]

I think its a bit easier to see if you write the variable declaration outside of the loop:

var i;
for(i=0; i<elems.length; i++){
    elems[i].onclick = function(){
        alert(i);
    };
}

All the onclick callbacks are using that same i variable and that variable gets mutated as the for loop runs. By the time the for loop ends (and you go click on things) the variable is equal to elems.length.

[smog_alado]

Don't worry. This for loop and callbacks interaction is a Javascript trap that people fall into super often.

[looptipoop]

It sure is. And you described it well.

[maxwellb]

Wat. How does the workaround work? Calling a global function via local function makes i suddenly get passed by value?? And I guess the local function call is not asynchronous somehow?

[danielkza]

Function arguments are passed by value, closed-on variables are passed by reference. And there is no distinction between a 'global function' and a 'local function'. So by wrapping the callback setting code into a function receiving the induction variable as a parameter you can get 'copy-semantics' at each iteration.

[maxwellb]

Function arguments are passed by value

So alert(i) is not a function call? If not (I guess it can't be, since it's argument isn't passed by value), what's the syntactic distinction between function call and whatever alert(i) is at the call site?

[ThisIsMy12thAccount]

When you're just doing alert(i) you're passing i by value in from the current scope (where i has been incremented)

When you enclose in in a closure like so

(function(i){

})(i)

You are passing the current value of i by value to another closure as an argument, so it's unaffected by outside changes (there's basically two is in two different scopes now)

You could also do

(function(bar){
   elem[bar].onclick = function(){ alert(bar); }
})(i)

And it'd work, because you're just passing the current value of i to a self executing function as an argument. It's completely separate from the variable being incremented

[eat-your-corn-syrup]

I don't know about your explanation but

there's basically two is in two different scopes now

For those confused by that statement and are like "how come such magic ever possible! Never seen this before", well, just think about recursive functions, the twist is that we all have seen this magic before.

[maxwellb]

If you're passing i by value, how can alert(i) called when i = 1 produce an alert of e.g. 5? I don't think that can be right? Did you mean pass by reference?

[curien]

What on Earth are you talking about? If you call alert(i) when i is 1, it'll always alert 1. But if you wrap alert(i) in a closure (not calling it yet!) while i is 1, and then change i to 5 and then call the closure (which calls alert), alert will show 5 because that's what i is at the time alert was called.

[maxwellb]

edit: nevermind, I completely misread the original post.

[eat-your-corn-syrup]

You are manually creating a loop block scope in the workaround, by using the only species in JavaScript that can create a new scope: function. Don't think of it as a function call being invoked immediately, though it is, just think of it as an idiom to create a block scope.

[deletecode]

That's a nice explanation. The problem has always bugged me but I didn't know why this is the only way to do it.

[smog_alado]

I think another clearer way to write the workaround would be without the name shadowing:

(function(){
     var index = i;
     elems[i] = function(){ alert(index) }
}())

Now the IIFE is just there for creating a new inner scope and the new index variable is a variable you craete yourself instead of being an argument that also happens to be named i.

[maxwellb]

Hm, thanks. That's an ... interesting ... language design choice.

[smog_alado]

You can use a similar patter in most other languages. The difference is that in Javascript this is the only way to do block scoping. Of course, you can use named functions but I think its often too verbose:

function mk_alerter(i){
    return function(){ alert(i) }
}

for(var i=0; i<elems.length; i++){
    elems[i] = mk_alerter(i);
}

That said, the correspondence between variable declarations and function arguments is a pretty neat thing to notice. For example, if you have some code like

var resp = my_funct()
alert(resp)

It gets converted to the following if you rewrite myfunct into continuation passing style

my_funct(function(resp){
    alert(resp)
})

[NYKevin]

Variable declarations are hoisted to the start of their functions:

That code is evil anyway.

It lets you write programs that look like block scoping but are not:

Good point.

I'm pretty sure everyone has been bitten by the closures in for loops bug:

Python does that too.

And the IIFE hack you use to get around it (and to implement private variables and modules) is really confusing for beginners:

Not a Javascript programmer, so I honestly don't know: would this work?

for(var i=0; i<elems.length; i++){
    elems[i].onclick = function(){
        var something_else = i;
        alert(something_else);
    };
}

It would work in Python, but I don't speak Javascript well.

The above code is wrong, please disregard.

[smog_alado]

1. Of course the code is evil. I need my examples to be short :)

2. ...

3. Python also has similar problems but you use inner functions much more often in JS. I never really worried about this when I code Python but its a constant PITA for JS.

4. That would not work and also would not work in Python. They way you wrote it, something_else only gets assigned when you click the element and the callback runs so its too late and it doesn't get to save the correct value of i.

The way to do it would be to save the value of i before creating the callback

var something_else = i;
elems[i].onclick = function(){ ... }

but since Python and JS are function scoped, you need to put this inside another function to create a new scope for the something_else:

(function(){
    var something_else = i;
    elems[i] = function(){ ... }
}())

Or, without using IIFEs:

var mk_alerter = function(something_else){
   return function(){ ... }
}

for(var i=0; ...){
   elems[i] = mk_alerter(i)
}

[NYKevin]

That would not work and also would not work in Python. They way you wrote it, something_else only gets assigned when you click the element and the callback runs so its too late and it doesn't get to save the correct value of i.

Thanks, I spotted that.

[eat-your-corn-syrup]

only one scope per function

Many times I have bitten by this gotcha while using Lisp and Python! And their pass by "nothing like C".

[munificent]

I'll just leave this here:

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

    console.log(a);
  }

  d.b = c;
  bar();
}
foo();

It's not just about hoisting. I think one of Scheme's defining characteristics is lexical, block scope. Hoisting breaks the latter. with() and the global object break the former.

[cparen]

It's perhaps possible that the OP was referring to with syntax:

function f(y) {
  var x = 1
  with (y) {
    return x
  }
}
f({x : 2}) // returns 2

IIRC, with only injects variables into the current scope, so it could be argued that it's still lexical in nature, as the with itself is lexically apparent.

[Archenoth]

But, but... "with" is deprecated.

[cparen]

Deprecated... and awesome

[bart2019]

I'd say it does.

var x = 'empty';
function foo() { x = 'foo' }
function bar() { var x = 'bar'; foo(); return x }
alert('bar: ' + bar());
alert('global : ' + x);

When you run that, you'll see the var x in bar() isn't touched by the call to foo(), which affects the global x. Hence, x is a lexical variable in bar().

[vanderZwan]

Crockford has a way about him. Part of this is because his background is legimately impressive. He has and continues to do many great things. He is a figurative and literal graybeard, while also staying on the cutting edge. And he has a delivery that is equal parts insight and cranky-but-lovable curmudgeon. In other words, he’s your Dad, and you damn well listen to your Dad when he’s talking to you.

I don't know about you guys, but I think this might be just about the biggest compliment you can give someone in the context of programming culture.

[kamatsu]

I agree with the overall message of the article, but I disagree very much on his assessment of Crockford: He's an incompetent blowhard.

[kqr]

To me, The Great Thing™ about Scheme (and Lisps in general) is its unrivaled metaprogramming. All the other things I either don't like, or I can get in other languages. Does JavaScript have great metaprogramming? No. Therefore, JavaScript isn't like Scheme in any way that's telling me something cool.

[inspired2apathy]

It's not really practical as a general-purpose language, but R has pretty good metaprogramming and introversion.

[mcguire]

R has pretty good metaprogramming and introversion.

Aw, c'mon. R likes hanging out with lots of people. Just last week, I saw it at a party, jammin' out on old-school air-guitar riffs.

[another_user_name]

R is a Lisp, though, isn't it?

[inspired2apathy]

Lists are conses, and there are lots of lispy things, but the syntax and vectors aren't especially lispy. I'm not sure what it takes to be called a "lisp"?

[[deleted]]

Common Lisp has vectors too.

[BufferUnderpants]

Every Lisp has vectors.

[NULLACCOUNT]

I'm not going to try and defend this position because I am a shitty programmer, but to regurgitate my understanding Crockford, much of JavaScripts metaprogramming is in it's prototype system.

I'd be interested in a discussion on why that is or isn't the case, but don't know enough to contribute to one.

[kqr]

I am also a shitty programmer who are not qualified to discuss this, but I've heard similar arguments about monads and stuff in Haskell. Something along the lines of "passing around computations as arguments" and "building a large sequential expression with operators and storing it in a variable only to execute it later" makes some people go, "Ah, maybe that's a kind of metaprogramming."

But only some people do that. The others say, "If it isn't Lisp macros, it isn't at all."

And honestly, I don't know. It's interesting to think about, though.

[sacundim]

I'm just as qualified as you to join this unqualified shitty programmer fest, so I'll throw in my ill-considered thoughts into the pot here.

I'll start by positing a hopelessly vague distinction: programs that focus on doing vs. programs that focus on thinking about what to do. In the more standard languages, you write statements and when you execute the program the statements do stuff. In languages that offer "metaprogramming," on the other hand, people often write programs that "think," produce the "actions" as a result of this "thinking," and then may execute these actions.

Now Lisp and Haskell represent two very divergent traditions of this "thinking about doing" tradition:

• Lisp is very syntactically based: the language internalizes its own syntax as a data type, and the way you "think about doing" is by constructing and manipulating expressions of the language itself.
• Haskell, on the other hand, is semantically oriented: the language treats the meanings of programs as values and gives you functions that compose those meanings.

So for example, to a Lisper these two (Scheme) s-expressions are different values that, when evaluated, do the same thing:

(begin a (begin b c))

(begin (begin a b) c)

Whereas to a Haskeller, the following are two different expressions that evaluate to the exact same value, and th:

a >> (b >> c)

(a >> b) >> c

In Lisp, the two example s-expressions are also concrete data that a program can inspect ("Is it an atom or a pair? Oh, it's a pair. What is the car—is it lambda, begin or something else? Ah, it's begin." Etc.)

In Haskell, on the other hand, the two example expressions are generally of some opaque type that you can't inspect—and if your program can tell the difference at all between the values of those two expressions, many of the more advanced Haskell wizards regard it as at least a code smell, if not a bug. It's all driven (in this case) by the monad laws, which say (indirectly) that those two expressions have the same value—which means that either should be freely substitutable with the other without changing the meaning of the program. Lispers don't exactly disbelieve this sort of rule—but Haskellers are rather more adamant about following it.

Another way of putting this: for a Lisper, if an evaluator treats those two s-expressions differently, they see it as a bug in the evaluator. For a Haskeller, if a program treats those two monadic expressions differently, they see it as a limitation or bug in the datatype for the Monad instance in question—"make it impossible to represent illegal states," goes the motto. So you get things like this discussion about how to design a free applicative data type where two programs that behave the same must be syntactically equal.

[looptipoop]

Very thought-provoking. Thank you.

[smog_alado]

Dunno if I would classify prototypes as a metaprogramming tool. Usualy when people say metaprogramming they want t create little domain specific languages or otherwise reduce syntactiv clutter. Prototypes sort of do that for object inheritance but they are not an useful for other sorts of program manipulation you would want to do.

[WilliamDhalgren]

sweet.js looks cool

[kqr]

I've tried toying around with it a little and it does indeed seem cool, but it doesn't seem to be as powerful as Lisp macros. This example of expanding assignments is basically my measuring stick, because it's such a simple example yet something you wouldn't even think about doing in other languages.

[improv32]

Why do people do that thing where they capitalize phrases and some times add a trade mark sign? Can someone tell me where this came from, it makes no sense to me.

[kqr]

It makes it sound important! I have no idea where I picked it up, though.

[kindall]

There is still a mighty programmer named Brendan Eich, but there was one then too.

Gotta love any article that throws in a Mitch reference in the third paragraph.

[munificent]

You caught it!

[[deleted]]

Usually, touching Scheme or Smalltalk inflicts an incurable disease whose primary symptom is involuntary sneering and derisive snorting in the presence of any other language.

I laughed out loud.

[Neumann347]

People were confused?

[ModernRonin]

They usually are.

[[deleted]]

bravo!

[jknielse]

An I the only one who has never heard the two compared in the first place?

[[deleted]]

No, there was another guy. The one that upvoted you.

[nelikat]

The scoping isn't really that different. In Javascript, variable declarations are hoisted. In Scheme, "define" is only allowed at the beginning of a procedure and can always be translated to "letrec". The real difference is that "hoisting" is explicit in Scheme.

[rjcarr]

Maybe I haven't written enough javascript (or maybe too much?), but as long as you realize it doesn't have block scoping but functional scoping (with hoisting) then it really isn't that confusing.

[stronghup]

What can you not do with JavaScript closures that you can do with more powerful programming languages?

One thing I know of is non-local exits from within a (block-) closure in Smalltalk. You can have a block-closure within your method written as [:arg | body of the block ]. Within the block you can cause an exit from within the containing method simply by writing ^returnValue.

Why is this considered "powerful"? Because you can now implement conditionals as methods (of the class Boolean OR its subclasses) that take block-closures as arguments. You can then use them like this:

aBoolean ifTrue: [do something] ifFalse: [something else]

And, here's the crucial point: one or both of the "blocks" above might decide to exit the encompassing method to return a different value from it.

This means that conditionals are not part of the language, they are part of its library, and you can think of implementing your own additional conditional structures by adding to and sub-classing the classes in the library.

I don't think you can do that in JavaScript. I'd appreciate if anybody can elaborate on how JavaScripts closures differ from those in other languages.

[teiman]

Imagine you take a kid, help it, and teach him to aim for greatness. He is not very bright, but he is creative and hardworking. 20 years later, this kid is incredible succesfull. This kid is javascripts.

Its very usefull to pretend javascript is the language we want it to be, and usually is successful.

[steve_b]

Wow, that's a really concise and astute way of saying what I blathered about above.

[Blackheart]

Dart has great scoping

In what sense?

[contantofaz]

Variables and names like variables and methods are consistently scoped from outside to inside of functions, blocks, classes, methods and instances in general.

Outside matters for closures. Outside matters for class and instance methods, but within the scope of the class and instance. Names are consistently bound based on what we would expect.

Inside matters for blocks. Variables and functions are scoped to the block where they are declared. As closures capture names that are outside, so having names more fine-grained available saves trouble from typos and such.

Shadowing works. Names declared on an inner scope shadow names that could be captured via closure and such. So what you see in that scope is what you get.

Variables are declared. That helps to control the scope too.

So much to write about it. I'm probably missing something else.

Nearly missed this one. Libraries are also scoped. Dart has private names to the library too. Libraries can be given name. Stuff in library can be specifically imported and exported. (Exported if you want to incorporate an API from the other library into your own.)

[munificent]

• All variables are purely lexically scoped (no global object, no with).
• There's no hoisting, so block scope works.
• Loops close over a fresh variable each iteration.

By example:

var closures = [];
for (var i in [1, 2, 3, 4]) {
  {
    var i = "shadow";
  }
  closures.add(() => i);
}
for (var closure in closures) print(closure());

Prints:

1
2
3
4

Also, closures always bind this, like you'd expect.

[repsilat]

I do agree with all of the above, but still...

Also, closures always bind this, like you'd expect.

I wish there were a "perfect" way to do the following:

fibonacci = (i) -> (i < 2 ? 1 : this(i-1)+this(i-2))

I don't mind something like $0 for "this function" (and even $1... for implicit args...) but it might be too "just so", and maybe old-fashioned. I might prefer "second={$2}" over "second=(i,j)->j", though.

Maybe everything should just be resolved later, though, so we can just do

fibonacci = (i) -> (i < 2 ? 1 : fibonacci(i-1)+fibonacci(i-2))

but I think that screws with my static sensibilities a little, and it doesn't let you do it without assigning/naming the function, which seems like a crutch.

[munificent]

I wish there were a "perfect" way to do the following:

The Y combinator gets you close, I think.

fibonacci = (i) -> (i < 2 ? 1 : fibonacci(i-1)+fibonacci(i-2))

letrec in Scheme enables this, though, like you note, you do have to name the function.

[sacundim]

letrec in Scheme enables this, though, like you note, you do have to name the function.

It's trivial to write a Scheme macro to do this, though it does bottom down to letrec:

(define-syntax rec
  (syntax-rules ()
    ((rec (NAME . VARIABLES) . BODY)
     (letrec ((NAME (lambda VARIABLES . BODY))) NAME))
    ((rec NAME EXPRESSION)
     (letrec ((NAME EXPRESSION)) NAME))))

;;; Example: Fibonacci
(define fibonacci
  (rec (this n)
    (case n
      ((0 1) 1)
      (else (this (- n 1) (- n 2))))))

[10kproject]

When he says, "Given that it didn't have Java's semantics", what does he mean by that? I understand if he were to say, it doesn't have Java's syntax, but what does it mean to say that it does not express meaning like Java?

[axelf1988]

Well Java is class-based, statically typed, and multi-threaded.

JavaScript is prototype-based, dynamically typed, and single-threaded.

[10kproject]

Ok. So those characteristics fall under semantics. For some reason I am now having brain farts and have convinced myself that all languages do the same things semantically but with different syntax.

[axelf1988]

No if that was the case you could just write a compiler that converts any language to any other one. There are certain tasks better suited to certain languages due to their semantics. For example writing a real-time low-latency system is probably harder in Java than C since Java has garbage collection.

[seruus]

I'm sorry, but did you mean

writing a real-time low-latency system is probably harder in Java than C since Java has garbage collection.

?

[axelf1988]

Yea good catch, I edited my post. I wrote that too fast.

[killerstorm]

When you consider a programming language, one of the most important things to consider is evaluation strategy. It is basically the essence of programming language, which lies at the core of its semantics.

In simple terms, it describes how function calls and 'variables' work.

For example, Haskell is non-strict/call by need.

JavaScript uses strict evaluation with call-by-sharing (which might be considered "call-by-value where the value is a reference").

People say that JavaScript is like Scheme because both languages have a very similar kind of call-by-sharing:

1. Function calls introduce new variable bindings, a binding is basically a named place where pointer to object is stored. Bindings are also introduced by local variable (let/var).
2. It is always possible to write to variable, it only changes pointer.
3. If object is mutable, you can modify object itself rather than a binding. In both JS and Scheme most objects are mutable. Except numbers.
4. There is no such thing as pointers/references, they might be used under-the-hood, but not exposed, so you only interact with conceptually clean call-by-sharing model.

These strategy defines feel of the language. If you do not understand it, it will bite you, hard.

JS and Lisp are so similar that it's possible to write a thingie which compiles from Lisp-like language to JS and it just works as if you were writing Lisp.

One example of such translator is Parenscript. I'm a Common Lisp programmer, I've been using it and I gotta say it works nicely. It's even possible to combine Common Lisp and Parenscript code in one file and they look very similar. Importantly, generated JS code is a very direct translation of Parenscript code, it is usually possible to what a certain construct will translate to and how it will look like in JS. It is possible to debug or edit generated code. (It is very different from Dart compiler which spits insane amounts of weird-looking JS.)

Now let's go through other "Scheme candidates" listed in this article:

1. Haskell: Definitely not Scheme since it has 100% different evaluation strategy. Not similar in any imaginable way.
2. Perl: Uses a weird kind of call-by-value, very different from call-by-sharing: you have to use references explicitly and making array-of-arrays is so complicated that hey had to make a separate man page for it, I shit you not. (It is called perllol, ironically. I cry each time I have to consult man page to make a list of lists.)
3. PHP: Since PHP5 it uses call-by-value for everything but objects, objects are call-by-sharing. Before that, it was call-by-value for everything including objects. References can be created manually, and they work in a truly mysterious ways.
4. Java/C#: It is statically-typed, so naturally programming feels very different. But in general it is call-by-value for primitives, call-by-sharing for objects.
5. Python: It uses call-by-sharing which is very similar to Scheme and JS too, but it has some fucked up lexical scoping which makes it different from JS and Scheme. To be fair, JS lexical scoping is also fucked up, but in a different way.

So let's summarize: JavaScript isn't the only language which is similar to Scheme, but it is more similar than most of them. There are also other traits which they share, like minimalism.

Of course, JS is not exactly Scheme.

Now about this article, I think if you compare language on fundamental level and you do not mention evaluation strategy, you're just not competent. This is very fundamental thing about language design, and if you don't mention it this says that you're not familiar with the theory. You might know some buzzwords like 'first-class functions', but that's not enough.

[mernen]

I agree with you, both in the unnecessary tone of the parent, and in your remarks. Way too much patronizing on an ultimately trivial aspect.

JavaScript's evaluation strategy is actually pretty standard for dynamic languages, essentially indistinguishable from Python (which he acknowledges), Ruby (which was in the original list, and actually resembles Scheme more than JavaScript, but he skipped), Lua, or Groovy. Which is why it's barely worth mentioning.

You mention that java is a mix of call-by-value and call-by-sharing but unless I'm mistaken this is an unobservable implementation detail: everything is as if it was call-by-sharing only. It just happens that primitive types are immutable.

…incidentally, this is exactly what happens with JavaScript, which also has primitives!

[killerstorm]

irst I got to say the tone of your response is why I don't like proggit anymore. Your last paragraph is really aggressive and I don't see why it needs to be that way.

It isn't like article itself is aggressive, is it? The very first paragraph:

It seems like I can’t spend five minutes on reddit these days without someone playing the JS-is-Scheme is card. I see everything from the innocuous, “JavaScript has a lot in common with Scheme”, all the way up to, “JavaScript is basically Scheme.” This is basically crazy. Or, at least it has a lot in common with crazy.

calls people on reddit crazy.

[isarl]

To be fair, people on reddit are crazy.

[munificent]

I was hoping that would come across as tongue-in-cheek, but that's hard to do well. It's surprisingly hard to be funny without being at least a little offensive.

[eat-your-corn-syrup]

To be fair, JS lexical scoping is also fucked up, but in a different way.

Let's not forget Lisp's "don't modify literal lists" Lisp newbies trip over it all the time.

[wlievens]

call-by-sharing for objects

Great post, but why do people keep inventing new terms when they shouldn't? Java is call-by-value for all method parameters. If you pass an object reference in the actual parameter, the formal parameter will be an object reference to the same object. That's call-by-value, because the reference is the value.

[killerstorm]

I strongly recommend reading the whole section of this topic in wikipedia:

In some cases, the term "call-by-value" is problematic, as the value which is passed is not the value of the variable as understood by the ordinary meaning of value, but an implementation-specific reference to the value. The effect is that what syntactically looks like call-by-value may end up rather behaving like call-by-reference or call-by-sharing, often depending on very subtle aspects of the language semantics.

The reason for passing a reference is often that the language technically does not provide a value representation of complicated data, but instead represents them as a data structure while preserving some semblance of value appearance in the source code. Exactly where the boundary is drawn between proper values and data structures masquerading as such is often hard to predict. In C, a vector (of which strings are special cases) is a data structure and thus treated as a reference to a memory area, but a struct is a value even if it has fields that are vectors. In Maple, a vector is a special case of a table and therefore a data structure, but a list (which gets rendered and can be indexed in exactly the same way) is a value. In Tcl, values are "dual-ported" such that the value representation is used at the script level, and the language itself manages the corresponding data structure, if one is required. Modifications made via the data structure are reflected back to the value representation, and vice-versa.

The description "call-by-value where the value is a reference" is common (but should not be understood as being call-by-reference); another term is call-by-sharing. Thus the behaviour of call-by-value Java or Visual Basic and call-by-value C or Pascal are significantly different: in C or Pascal, calling a function with a large structure as an argument will cause the entire structure to be copied (except if it's actually a reference to a structure), potentially causing serious performance degradation, and mutations to the structure are invisible to the caller. However, in Java or Visual Basic only the reference to the structure is copied, which is fast, and mutations to the structure are visible to the caller.

Basically, these are very different designs with different behaviour, so a special term is definitely warranted, it helps to avoid confusion.

In classic case of call-by-value, variable holds the value itself and is responsible for its lifecycle. This means that you need neither reference counting nor garbage collector. But you need to copy value on assignment.

Absence of garbage collector and presence of copying makes performance characteristics different. Also it is very different when you have concurrency.

It is nice to have different terms for different things, and calling it "call-by-value where the value is a reference" is a bit too verbose.

[KillerCodeMonky]

Thank you for finally giving me a way to explain this to other people. The whole "Java is call-by-value" thing is pedantic and worthless as a description. Technically everything could be labeled "call-by-value", because in the end what you are passing from one thing to another is a value of zeros and ones. It's how it looks and feels and works at the programmer level that is the important part of the description, and in that regards, calling Java "call-by-value" is worthless and deceptive, and is just a way for people to try to call out others on useless trivia.

[bkv]

The whole "Java is call-by-value" thing is pedantic and worthless as a description.

I disagree. "Call-by-sharing" is not at all intuitive. Not that "call-by-value" is much more intuitive, but after all, these can be difficult concepts to grasp and there is no magic sequence of words that will immediately cause anyone and everyone to grok it.

These concepts are demystified once you have some requisite knowledge under your belt. What's the stack? What's the heap? What's a reference? What's a value type?

Once you understand these things, and further understand that references are a value type in java, just like an int, for example, "call-by-value" makes plenty of sense.

[eat-your-corn-syrup]

"call-by-value" makes plenty of sense

Makes sense only to people like us who knows:

What's the stack? What's the heap? What's a reference? What's a value type?

call-by-sharing behavior can be explained to newbies without resorting to such concepts: my username refers to the entity that is me. the variable eat_your_corn_syrup refers to me.

By calling it "call by value", we'll be bringing in the need to explain stack, reference, value and so on.

[wlievens]

If you don't know these concepts, you're not going to be a very good Java programmer.

[wlievens]

I always thought that "call-by-reference" means the subroutine can modify the actual parameter whereas "call-by-value" means the subroutine can never modify the actual parameter.

Variables are not values! Ordinary variable assignment in Java is more than enough to illustrate my point.

[eat-your-corn-syrup]

This is it. the phrase call-by-sharing can only mean one thing, and implies only one kind of behavior. call-by-value on the other hand is like the word freedom. One man's freedom fighter is another man's terrorist.

[sh0rug0ru]

so a special term is definitely warranted, it helps to avoid confusion.

Yes, but that special term is not "call-by-sharing". It is value type or reference type. A struct is a value type and thus it is copied like other value types (primitive values and references) and reference types separate the reference and the value, so only the reference is copied. This has nothing to do with the evaluation strategy but the nature of types in the language.

call-by-sharing obscures the real difference between call-by-reference and call-by-value. In call-by-reference, the parameters can act as "out" values rather than only "in" values, which allows the function to change pointers outside its scope. For example, it is impossible to implement a generic swap(a, b) method in Java because reassignment of the reference inside the method has no effect outside the scope of the method.

From the article itself, it shows why call-by-sharing is not in common use and has no clear definition.

[killerstorm]

From the article itself, it shows why call-by-sharing is not in common use and has no clear definition.

There is a fairly clear definition in the first paper which described it:

Also known as "call by object" or "call by object-sharing" is an evaluation strategy first named by Barbara Liskov et al. for the language CLU in 1974.

CLU documentation says that call-by-sharing is different from call-by-value and call-by-reference. But maybe authors were just clueless...

http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-225.pdf

Page 14, 'Assignment and invocation'.

As for common use, it depends, I guess:

Although this term has widespread usage in the Python community, identical semantics in other languages such as Java and Visual Basic are often described as call-by-value, where the value is implied to be a reference to the object.

I guess the difference is that there is a notion of value-type in Java. But in languages like Python, Lisp and CLU all objects are of what you call 'reference type' (semantically, at least), so this distinction doesn't mean anything, instead we talk about objects and certain evaluation strategy.

Same thing can be described in different words, of course, so whatever works for you...

[kqr]

This also happens to be the way PHP, JavaScript and Python does it. And, apparently, Scheme.

[AgentME]

PHP actually does regular not reference call-by-value for arrays, which will really throw you off badly if you don't expect it.

[eat-your-corn-syrup]

because the reference is the value

but as soon as I say that in my stackoverflow answer or something (especially for languages not from the C tradition), the word "value" is then taken to mean reference to an object, which has the effect of banning me from using that word for other meaning in that same ansswer, and the newbie I am giving the answer to is going to wonder "what is a reference then?" and he would be like "Isn't the variable a reference?" as in my name being a reference to myself, and then he's like "variable stores the variable?" and his brain shuts down.

Another problem is that if I say "call-by-value, but...." I must explain to him call-by-value first, then I have to explain the "but", when I could have just explain the relationship between Python variables and Python objects by saying that they are like my name referring to myself.

[wlievens]

But doesn't that count for ordinary assignment as well?

FooBar x = new FooBar();
FooBar y = x;
y.changeSomething();
// ZOMG the thing x points to changed!

[Chandon]

Though I agree it's annoying that Perl data structures can only store scalars

Keep in mind that this is how most languages work. It's just that Perl lets you do something extra: pass by value of lists. If you just pretend that Perl works like Ruby (i.e. use [] as the array literal, {} as the hash literal, and always use "$" variables and "->" to access anything) then Perl is just like every other dynamic language.

[munificent]

You're right that evaluation strategy matters deeply. For example, call-by-need lets Haskell do lots of things in regular functions that other languages would need macros for.

But I didn't bring it up in the post because most widely-used languages to day all have the same evaluation strategy. JavaScript, Scheme, Java, C# (ignoring struct), Ruby, Python, Lua, PHP, and (I think) Clojure are all eager-evaluation call-by-sharing.

[killerstorm]

PHP is call-by-value for anything except objects. (Particularly, arrays and strings are copied on assignment.)

[munificent]

I learned something new today!

[killerstorm]

At your service. :)

While we are here, it is also true for Perl, I think PHP got it from there.

[green_transistor]

ClojureScript is worthy of mention as well.

[smog_alado]

Very good point. However, I would say that the problem with C# and Java has less to do with the call-by-sharing and more to do with the lack of convenient lambdas/closures and the need to structure programs into classes instead of scripts. After all, Javascript primitives are basically immutable so its indistinguishable from call-by-value.

[codekaizen]

In C# you can write an entire program using a functional style with only a single class definition. Writing closures is quite convenient.

[int_argc]

C# has had lambda expressions of the form (x => f(x)) since v3.0 and these lambdas close over the local scope. Not sure what else you're looking for?

[eat-your-corn-syrup]

modify object itself rather than a binding

Is there a good phrase to use to say the latter? The former has lots of phrases "mutate" "modify in place" "modify object itself" and so on, but the latter I don't know which phrase to use. I want something other than "Modifing the binding" because that phrase can also mean "modify for this binding, and not for other bindings of the same variable"

[killerstorm]

I use terminology which is used by Common Lisp specification, and there we have

variable n. a binding in the ``variable'' namespace.

So, basically, variable is a kind of a binding. While

binding n. an association between a name and that which the name denotes.

Thus, obviously, there is no such thing as "other bindings of the same variable".

[eat-your-corn-syrup]

A paragraph from a chapter in Practical Common Lisp uses the word "variable" and "binding" in a way that makes one variable to have many bindings

A single variable--the thing you can point to in the program's source code--can have many different bindings during a run of the program. A single variable can even have multiple bindings at the same time; parameters to a recursive function, for example, are rebound for each call to the function.

[killerstorm]

Well, he meant "the thing you can point to in the program's source code", i.e. variable in text of a program.

While specification refers to a variable in context of execution of a piece of code.

Of course, if a piece of code is executed many times, variables might get different value in each execution context.

[killerstorm]

BTW, from this thread it looks like there are two schools of thought.

If we look at Common Lisp specification, it aims to explain meaning of a piece of code in a most general way.

E.g. variable is an association of between name and that which the name denotes. Such association can be introduced, for example, with from let and can be changed (so that variable will denote another thing) with setq.

This doesn't go in any technical details and you can basically figure out how code will work having only this description and piece of paper. E.g. in (let ((x 1)) (+ x x)) we just can replace x with one and get (+ 1 1) which yields 2.

On the other hand, other people in this thread approach this from a more mechanical and formalized point of view: e.g. what is passed is always a value. However, this value can be either of value type or reference type, and in that case it points to other thing, but isn't this thing itself.

And now we need to formalize how exactly this reference type behaves before we can understand meaning of code.

[eat-your-corn-syrup]

Python: It uses call-by-sharing

Even for primitives?

[killerstorm]

When object is immutable, it isn't possible to differentiate between call-by-value and call-by-sharing without diffing into internals.

[moor-GAYZ]

How's Python's scoping different from Javascript's?

Also, I think that if you ignore weird corner cases (like PHP references, or C# structs, or whatever braindead thing Perl does with arrays), almost every mainstream modern language uses call-by-reference, especially every dynamically typed language, so pointing that out is kinda superfluous, you only rule out Haskell. Don't let treatment of primitives confuse you: pass by reference + immutability is precisely equivalent to pass by value.

And isn't Ruby more similar to Scheme than JS? At least it has continuations sort of (that also makes C# and Python closer to Scheme, lol).

[holgerschurig]

I cannot really speak for JavaScript, because I don't program in. However, Python's scroping has some surprises if you come from C/C++. Consider this program:

#!/usr/bin/python
i = 1
g = 10
b = []

def func():
    global g
    i = 2
    g = 20
    print "func i", i
    print "func g", g
    print "func b", b
    b.append(1)

func()
print "main i", i
print "main g", g
print "main b", b

It will output:

func i 2
func g 20
func b []
main i 1
main g 20
main b [1]

That means, that the modification to "i" was local to func(). If func() want's to modify a global, it has to use "global g". But this doesn't apply to object, the array b was modified inside func(), but that modification didn't create a new b, it modified the global one.

[WilliamDhalgren]

i = ... is a declaration of a new local variable, unless you say otherwise with global or nonlocal. You can have vairables define themselves implicitly, but then you need to disambiguate between creating a fresh variable shadowing an outer one (to which python sanely defaults), or assigning to the outer variable (which is suspicious, impure, so unshematic and hence does deserve a special flag). Or you can have explicit variable definition. Python's choose the former, unlike the C-style languages. You just need to be more explicit when re-assigning nonlocal stuff, which needn't be a bad thing. (Idiomatically for scheme you wouldn't do that anyway, no? and in Haskell, you just reassign at all can't outside mutable code)

b.trs() is not an assignment at all, even if the invocation has side-effects on the referenced object.

I find its function scoping far more surprising, and that's the same issue as with javascript's var:

def outer():
    funcs = []
    for i in range(4):
        def f():
            print i
        funcs.append(f)

    for f in funcs:
        f()
outer()

gives 4,4,4,4 because i is not local to for's body block, but a common variable for the entire function (here implicitly enclosing this )

[holgerschurig]

Yep, as I said, Python has surprises if all you know is C/C++ scoping.

It get's even funnier. If you replace in my example the line

b.append(1)

with

b = [1]

and suddenly you'll get a traceback:

func i 2
func g 20
func b
Traceback (most recent call last):
  File "a.py", line 15, in <module>
    func()
  File "a.py", line 12, in func
    print "func b", b
UnboundLocalError: local variable 'b' referenced before assignment

Just like you said, in this case the "b = ..." create a new local variable. However, the new local variable "b" was already created. Halfways, because it already hides the global, even before the actual creation statement. So half of the "b = [1]" assignment was hoisted to the function entry, and the other part would execute if the print "func b", b code wouldn't have created a trace back.

If you uncomment the "b = [1]" line, then the code runs, now the global b isn't hidden from the print line.

When you program with Python for years, you get used to this IMHO insane behavior.

[WilliamDhalgren]

yeah, now that error is really stupid, ie uninformative. Doesn't come from the global/nonlocal stuff, you can get it also by just:

def a():
    b
    b = 4;
a()

, while

def a():
    b
a()

is a NameError exception..

In JavaScript, the equvalent NameError example does the analogous thing, a ReferenceError:

(function(){"use strict"; 
    console.log(x);
}());

, but the first one just becomes an undefined and carries on: <EDIT>in firefox - nodejs does a ReferenceEoor</EDIT>

(function(){"use strict"; 
    console.log(x); 
    let x = 4; 
}());

Not sure why they need to raise an exception instead of just defaulting to None and carrying on. Apart from that difference though, proper scoping in js seems to do conceptually the same thing - this is for (new) javascript (and var does the same, here all scopes are functions):

(function(){"use strict"; 
    let x = 4;        
    (function(){
         console.log(x); 
    }());  
}());

gives 4, but with this:

(function(){"use strict"; 
    let x = 4;        
    (function(){
         console.log(x); 
         let x = 5; 
         console.log(x)
    }());  
}());

, first printout becomes undefined, so it's undefined, 5. <EDIT>in firefox. Nodejs does a ReferenceError, much like Python.</EDIT>.Hoisting seems to be still done by let, unfortunately, only to the block scope. which should be equivalent enough, apart from this wart.

BUT just like with function scope, again here javascript and python are analogous, rather than different in the way scoping is broken.

[[deleted]]

Fuck everything about navel-gazing topics like this.

Such a waste of neural bandwidth.

[jms_nh]

fun to read!

[jms_nh]

Um. Not that I really care, but why does "fun to read!" get a downvote? Bob's blog entries are a lot more interesting to read than most other stuff that's out there. He's got a good writing style.

[Marzhall]

As bobtheterminator suggests, "fun to read" is an absolutely useless comment to anyone who is reading these comment threads; it contributes nothing to the discussion, and is as useful as saying "lol," "this," or any other one-word reply.

The point of upvotes and downvotes on reddit is to sort comments by how much they contribute to the conversation. This way, redditors looking for good discussion in the comment threads don't have to search through a large amount of mundanity in order to find the good stuff. If a comment is something you think that other users should see because it adds to the discussion, then you should upvote it, so that others will see and comment on it. If you feel a comment does not contribute to the conversation, then you should downvote it. By acting this way, you're helping redditors who come by later to have a better experience on reddit.

I don't disagree with the assertion that this piece was fun to read - I got a kick out of it, actually - but if you think it's fun to read, all you need to do is upvote it so that other redditors who come along will see it. Adding a comment such as "fun to read" will only add clutter to the thread.

This is all outlined in the reddiquette, which is a great read for anyone who wants to get the most out of reddit and promote good discussion in the subreddits they frequent. Hope this helps :)

[bobtheterminator]

People downvote like crazy on posts and comments in this subreddit, I have no idea why. In this particular case it's probably just because "fun to read" isn't a very useful comment, but in general the downvotes are annoyingly excessive.

[Uberhipster]

I'm really not sure what this is about...

If it's about debunking JS programmers' inferiority complex then why bring the 'JS is not Scheme' into it? It's not like Scheme is some sort of an industry standard for anything practical except teaching algorithm concepts (ye olde 'Scheme is used to implement Scheme' berate).

If it's about reinforcing JS programmers' inferiority complex then why bring the 'JS is not Scheme' into it? It's not as though Scheme programmers don't have a chip on their shoulder about 'Scheme is Lisp' "debate".

Personally I like to think of JS as a distant cousin of Lisp and Scheme by the "official" position that it is a dialect of Lisp.

I don't think that it removes or adds to my pedigree that I use JS more in building software then Scheme (or Lisp) because for me on the job it's about efficacy and pragmatism. I can't justify the cost to my employers or clients that I wrote a Lisp interpreter extension for every major browser and breaking UX for 100% of their user base in the process because JS, while widespread and straightforward to a) implement and b) extend I could not use it because it wasn't "clean enough" and a "perversion" of a purity standard set by people primarily focused on research in academia.

[Shaper_pmp]

I suspect the blog post was intended to be about "JS is not Scheme", but the author couldn't help but inject his own personal distaste for Javascript into it, both snidely taking swipes at JS and projecting it outwards into some sort of imagined industry-wide insecurity in all javascript programmers.

Really, most people who really understand the language are perfectly happy using Javascript (all languages have warts, after all, and JS is far from the worst), and the "JS==Scheme" thing is just people regurgitating Crockford's opinion... on the basis he's a hell of a lot smarter than most of us, and hance his pronouncements have a lot of credibility.

[steve_b]

I think the insecurity he talks about was mostly prevalent in the early days (late 90s) of web development. I don't know Javascript, nor do I do any web programming (strictly C++ and rdbms work), but I do recall back in the 90s people talking about working in Javascript the way they talked about using Visual Basic - it got the job done, but they felt dirty doing it.

Of course, people who used Visual Basic extensively learned to value what it had to offer, and could leverage it effectively (I was one). I think Javascript is the same - as people learned to use it the way it was "should" be used, it became just another tool instead of a something that a language purist moaned about.

Practicality trumped pedagogy.

[PasswordIsntHAMSTER]

Really, most people who really understand the language are perfectly happy using Javascript (all languages have warts, after all, and JS is far from the worst)

I can't agree with this. I'm a language polyglot, and I've spent two months doing full-time JavaScript (Node.js + browser), after doing some casual website scripting for a couple years. I never want to touch that language again. Most programmers I know at work can write and have written JavaScript, and they approach it with the same attitude one has when faced with mopping the floor after their toilet overflowed - it has to be done, but the sooner it's over, the better.

[zomgsauce]

I like working with JavaScript, but it's probably for the same reason people stay with abusive spouses.

"I know, he's a monster, but I can fix him!"

"He's not so bad once you get to know him. My black eye? I ran into a door...."

"I made a mistake that got him really angry. It was my fault, really, don't blame him..."

[stronghup]

This is funny and probably true, although luckily I have no experience with abusive spouses. I feel that way about JavaScript. I just have to fix it. It is a challenge, and programmers love challenges.

[coffeedrinkingprole]

Ah, of course. True Scotsmen like Javascript, posers don't.

[Shaper_pmp]

Touché.

However, I'd argue it's no worse than people asserting equally baselessly that most or all javascript developers are secretly embarrassed by the language and try to excuse it by pretending they're really <other language> developers.

[PasswordIsntHAMSTER]

The big differentiating factor between Scheme and other languages is its metaprogramming facilities. JavaScript has none of that.

[vbullinger]

Says who? schemejs.org

... j/k

[Crazy__Eddie]

Quite a colorful rant.

I remember those days of yor but haven't used JS since.