I disagree with this statement. Arrays are mutable, it's easy to make global mutable state, for the longest time for loops required a mutating index, etc.

Yes, but JavaScript is flexible enough to allow persistent data structures, and a value-semantics API for working with them, to be implemented in terms of a library:

http://swannodette.github.io/mori/

Just to avoid confusion: mori the library, as distributed by npm, is already compiled. Building the library itself requires a compile step, but an end-user just needs to load it with a script tag or require("mori").

To be fair it's implemented in Clojurescript I'm pretty sure.

It is, but pre-distribution it is compiled down to 100% JavaScript as a stand-alone JS lib that you can load with a script tag or NodeJS require(...).

The ClojureScript compiler only gets involved if you want to hack on mori yourself, as opposed to consuming it as a library.

If the point you're making is that it's implemented with ClojureScript as opposed to JavaScript, the fact is that everything that ClojureScript "does" you can do with hand-written JavaScript, but your hand-rolled solution might not be as generic or efficient (depending on your JS chops).

> for the longest time for loops required a mutating index

Well, at least one mutating index is convenient:

  function forEach (a,f) {  
    for(var i=0;i<a.length;i++) f(a[i],i,a);
  }

After that, you generally wouldn't need more indexes.

But does it really require a mutating index?

  function forEach (a,f,i) {
    var n = i || 0;
    f(a[0],n,a);
    if(a.length > 1)
      forEach(a.slice(1),f,n+1);
  }

Array copies aren't particularly efficient, of course, and there are languages with data structures backing arrays for which some similar approach might be efficient, but there it is.

I guess the thing I'm harping on is shawnz saying that javascript is INHERENTLY functional. I think it's possible to write javascript in a functional way: Underscore.js is a perfect example of that. But I wouldn't say it's INHERENT of javascript.

I think javascript is INHERENTLY object oriented/imperative but can be functional if you put some effort into it.

Javascript, like other scripting languages (Ruby comes to mind), is both functional, imperative and OO. It has mutable state, imperative loops, first class functions, closures, etc...

Which for loops don't require a mutating index? (apart from the object property "for __ in __" iterator)

Those ones. But what I meant was that it is idiomatic to use for loops vs recursion.

That's true, and may be reinforced somewhat by the fact that JavaScript doesn't eliminiate tail calls. In other words, there are situations where a recursive algorithm would be clean and compact, but might result in the call stack being blown inadvertently.

I ran into this recently while building a "practical" monads library for JavaScript. Each monad and transformer has sync and async variants. The sync variants can't use straight recursion because "deep" monadic binds will result in a blown call stack. The solution was/is to allocate on the heap in terms of an array that acts as a manually operated call stack (I think I essentially implemented a "trampoline" but I'm not 100% certain).

Considering that recursive loop with bounds is a sort of for loop, recursive for.