angusC

If anyone wants to add Vonnegut or anyone else please feel free to fork my original code. No reasonable pull request refused :-)

https://github.com/angus-c/literaryJavaScript

Mine is up and running - thanks! http://javascriptweblog.wordpress.com

Hi Swizec - maybe the article could have been clearer - the real point was this: now that our standard iteration pattern has made obsolete by higher order functions (forEach, filter, map etc. - which are available natively as well as github :-)) lets see if we can re-purpose it for fun and learning.

It wasn't supposed to be taken too seriously.

BTW for-loops are not exactly the same in C, because JavaScript has no block scope.

Hi Daniel - I wrote the article. You reference some excellent high order functions, we now also get pretty much the same functions for free in every browser except IE8. We get them with jQuery and Prototype.js too.

But the point of the article was: now that for-loops are gaining obsolescence as conventional array iterators, what can we use them for (and how do we have fun with them). A bit like a "what to do with those old LPs" discussion - except I still love listening to LPs :-)

You said "I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code"

In addition to talking about ternaries, guards and defaults, the article discusses myriad techniques aimed at replacing conditional logic with entirely non-conditional approaches (both functional and oop).These include function dispatching, function delegation, use of high order functions, functions as data and polymorphism.

These techniques aren't going to work for everyone and it would be very cool if you chimed in with your own experiences. What's not cool is misrepresenting the article.

Did you read the entire article?

Hi - I 'm the author of this post. A few comments:

1) It wasn't my intention to create a holy war. There are good arguments on both sides. I use ifs and fors in my own code and will continue to do so.

2) Over the years I have developed a distaste for the overuse of statement branching - I find it distracting and I feel it works against readability.

3) I wanted to catalog a bunch of (mostly well known) alternatives to present as a coding strategy

4) I realize that not everyone likes such terseness of style and what is clear syntax to one person can be undecipherable to the next.

5) Use what ever works best for you and your team

(Notice how procedural this comment was :-) )