5 ms·
As it says on the site, Fogus is "a core contributor to Clojure and ClojureScript". I wonder why he didn't just write a book on ClojureScript instead. Isn't C
by tieTYT 13y ago
As it says on the site, Fogus is "a core contributor to Clojure and ClojureScript". I wonder why he didn't just write a book on ClojureScript instead. Isn't ClojureScript already a way to write functional javascript?
- fogus 13y agoI am writing a book on ClojureScript. http://joyofclojure.com/2nd http://joyofclojure.com/2nd
- owenjones 13y agoHa! Thanks for the new book fogus, love TJoC 1 and am eagerly awaiting the sequel.
- zura 13y agoNice! I hope "Thinking code" and "Data-orientation" parts will get more attention (and space), versus ClojureScript and "weby" stuff, in case there will be a trade-off.
- sivam 13y agoThank you for your contributions to Clojure, it's a great step forward among all the other procedural languages around.
- shawnz 13y agoJavascript is inherently functional on its own! I can't speak for the author, but I suspect he titled it this way because of how few javascript users there are that actually understand this fact.
- Fistandantilus 13y agoJavascript is inherently dis-functional (hehe) as it relies heavily on mutation and side-effects, rather than immutability and functional purity. First-class functions do not mean the language is functional.
- tieTYT 13y agoI 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.