The book is on sale here: http://shop.oreilly.com/category/deals/velocity-celebration.... (50% discount)

That seems to be the ebook.

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?

I am writing a book on ClojureScript. http://joyofclojure.com/2nd

Nice! 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.

Ha!

Thanks for the new book fogus, love TJoC 1 and am eagerly awaiting the sequel.

Thank you for your contributions to Clojure, it's a great step forward among all the other procedural languages around.

Javascript 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.

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.

$12 is cheap. I also made sure it went through your Amazon referral link fogus, thank you for writing it. :)

I did the same thing. I have been waiting for this book. For a variety of reasons, I have been spending more time coding in Javascript and a little less in Clojure, and I hope this book helps make that a happier experience.

The Joy of Clojure is my favorite programming book, so this is a no brainer for me.

So far I've been disappointed by the "functional X" books.. Probably because I've read SICP and much of the "functional" books just repeat the same patterns over and over.. i.e. memoization, closures, map, reduce, etc. Still, I'm a sucker for these books and I'll gladly buy it. Hopefully I'll learn a thing or two.. and if I do so, I'll be more then happy to share the word about it! : )

Thoroughly enjoying your book, thanks for writing it! It was also great to get a DRM-free copy through O'Reilly. Please write more :)

I'm a back end java guy who's getting more into JS. Bought. Thx, Fogus.

I'm currently reading it and enjoying it a lot. Congrats!

Congrats, I have been waiting a while for this!

The otherwise beautiful 'official site' has a very curious 'feature' right at the bottom: a glossary of choice words which, on click, pop open a window alert with their 'definition'. It gets even more bizarre: at least two of those items return "glossary entry for [xyz] not yet available".

And? Actually one definition, 'recursion' reloads the page and the other 'laziness' has no definition... yet.

Thank you for creating this book!

How does this book compare to Doug Crawfords book?