3 ms·
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.
by tieTYT 13y ago
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.
- Torn 13y agoWhich for loops don't require a mutating index? (apart from the object property "for __ in __" iterator)
- tieTYT 13y agoThose ones. But what I meant was that it is idiomatic to use for loops vs recursion.
- michaelsbradley 13y agoThat'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).
- mackwic 13y agoConsidering that recursive loop with bounds is a sort of for loop, recursive for.
- deleted 13y ago[deleted]
- wwweston 13y ago> 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.
- tieTYT 13y agoI 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.
- nijk 13y agoJS isn't inherenttly OO. Crockford wrote a whole book chapter on twisting JS into make it OO. JavaScript is inherently a blurry mess, and intentional but hacky hybrid of Scheme and C-style.
- michaelsbradley 13y agoYes, 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/ 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").
- cgag 13y agoTo be fair it's implemented in Clojurescript I'm pretty sure.
- michaelsbradley 13y agoIt 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).
- Mikeb85 13y agoJavascript, 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...