Basically you rewrite your recursive functions so that instead of calling another function they return a parameterless closure. Then you can iteratively call your first function, and the function it returns, and the function it returns etc until the return value is not a function.

It's like with lazy evaluation. It allows you to write novel kinds of algorithms and data structures, and you can emulate it with helper objects or structures, but it's tedious, muddles the essence of the code, and the implementation without them (the helper structures) would be simpler if the language provided you with lazy expressions.

In other words, repeat with me: loops don't compose. They're not first-class, they're not extensible, they're a syntactic construct.

Iterators do, though. Most of the languages that don't do TCO instead lean on those instead: C++, C#, Python, and eventually JavaScript.

  function fact(x) {
      return (function factIter(i, total){
          if(i<=1){ return total; }
          return factIter(i-1, total*i);
      })(x,1);
  }

  function fact(x) {
      if(i<=1) { return 1; }
      return _.range(1,x+1).reduce(
        function(sum, x) { return sum*x; }
      );
  }

I realize that JS is becoming more popular for various tasks -- not always relating to the web -- but still, I kind of doubt that 99% of the JS out there is going to run up against these types of problems. Perhaps something like Uglify.js or similar might, but then again, if you're implementing a parser (or any other static code analyzer/tool) then you're probably going to avoid most libs to start with.

There are lots of concepts that are still applicable even when using imperative loops.

Pulling apart the iteration over a collection of elements and behavior performed to each element is one of those insights that a functional style is good at communicating, and leads to better more testable code.

   function each(arr,fn,pos) {
	pos = pos || 0;
	fn(arr[pos++])
	if(pos < arr.length)
	   each(arr,fn,pos);
   }

right now i need to build my own stack, and "unstack" it manually.

In the last year, this guideline was removed from the guidelines page and mods have been renaming items "back" to the actual title of pages being linked to. So this item should be "fun.js" and now the useful title it is now. I'm surprised it hasn't happened yet because there have been a ton of examples in the past several months.

(If you couldn't guess, I think the change in policy is ridiculous.)

I have mixed feelings about it; on one hand, if an author titles a piece of work, then in the interest of honoring their creative expression (e.g. their work) then it'd be best to use their titles. Except, of course, when it's a poor title. On the other hand, authors aren't always the best about naming articles, and/or there's context that's present on their site that might produce a title that's out of context when lifted wholesale for use on another site.

For this article, I think "fun.js" is particularly poor, as it implies that it's about some coding project. Of course, the ecosystem has been tacking ".js" onto anything even remotely related to JS, and so it's not all the author's fault, but as a HN title it'd be misleading. IMO the 'best' title here would be akin to a reference, such as:

    "Functional Javascript: Introducing Functional Programming with Underscore.js" by Michael Fogus (O'Reilly)

I think that both of you are right, to some extent. Code reuse is a goal, because it's better than writing everything anew every time you need some functionality. But it's not a long term goal, because sooner or later, it turns out that the code you have is insufficiently abstract, and you have to replace it with something more generic. I don't think that the level of genericity and abstraction available in mainstream languages is up to the task of making long-time code reuse an appropriate goal. VPRI-style "'runnable math' specifications" seem like the way to go, but how many people program that way?

http://www.bramstein.com/projects/funcy/

It implements pattern matching in JS, with objects and closures. Not as convenient as first class support, but might be worth it.

https://github.com/bramstein/funcy

What I'm mostly struggling with is how to structure my code within this paradigm. While this struggle is not limited to FP, I'd be very curious to find resources that don't just show code snippets, but explain the greater architecture of FP implementation.

I have a code base, and I think my priority should be to remains as consistent with that code base as possible.

Am I wrong? Is this book just for entertainment? There's nothing wrong with that of course.

https://news.ycombinator.com/item?id=5409626

It covers first class and higher order functions, currying, partial application, composing functions, using operators as functions, comprehensions, and immutability.

This may be too political (as well as OT) a question for you to respond, but I see that this is an O'Reilly book. Does this mean that O'Reilly... um, "has some life left in them"?

I guess I'm hoping so, and looking for some encouraging words from your own experience doing this book with them. Or criticism, if it's justified and you are free to say. (There used to be some O'Reilly people on here, I've noticed, so keep that in mind...)

I like Tim and like the older books. Some more recent issues have given me pause.

P.S. Oh, I see the book isn't out, yet. Maybe I should ask this later.

Also, I didn't initially consider that this could start another "O'Reilly" conversation, in depth. Rather, I'm interested in first-hand experience.