["args", "one", "two", "three].join(“, “)

or

args.reverse.join(“, “)

[5, 4, 2, 1].map { |n| n**2 }

How do you guarantee at compile time that, inside your “indexed for” loop, you did not accidentally walk out of your data structure (array, dom tree, whatever…)? Such an error will never occur with the new for syntax!

But this is complete besides the point of adding closures to a programming language …

Loop constructs are simply a basic example to demonstrate closures. Closures are much deeper and more powerful than that.

And in these cases you’ll use a construct that guarantees order of execution

> String concatenation is not commutative, and it’s really important that we add the strings in the proper order.

Wrong, that’s not what you want, what you want is to have the final string in the correct order, the order of concatenation does not matter, the computer could join the last two strings of the list first for all you care, as long as the final string is the one you wanted _it does not matter_ and saying otherwise is a fallacy. Not to mention, of course, the fact that this example is a strawman since most languages handle string-concatenation via native constructs, which means that you don’t need to use `for` loops anyway.

Now since you went through so many efforts to build that strawman we’re going to refute it shall we? And we’re going to refute it using the tools that fits your fallacy the most: a functional, lazy-evaluating (which means that it _really_ doesn’t guarantee order of evaluation) language: Haskell

  > let s = foldl1 (++) array

Well, it wasn’t that complex was it?

It shall of course be noted that most people would use the function built in the standard prelude and write `let s = concat array`.

And in most case you don’t care about the order of execution, the only thing you care about is the order of the result (note: for the cases when you do care about OOE, the languages that may break it all offer constructs that allow you to fix it however you want). Case in point: the `map` construct.

`map` is really simple: it applies a function each value of a collection, and returns a collection of the results _where the order of the results is the same as the order of the initial value_.

Does this mean that it can’t be parallelized? Of course not, it just mean that you have to resync the final collection of all the values, you can see how to do that via Joe Armstrong’s implementation of a simple `pmap` (Parallel Map): http://www.erlang.org/ml-archive/erlang-questions/200606/msg00187.html

The order of execution is unspecified, the mapping is completely parallelized, yet the result collection is ordered which is exactly what we wanted.

> Thus the closure syntax and the for syntax really aren’t equivalent and closures can’t replace for loops.
Actually they can, they’re just an example of inner iteration versus Java’s or Python’s “outer iteration” (via iteration objects) or — worse — Java’s or C’s “manual iteration” (via regular for loops). Smalltalk showed more than 20 years ago that inner iteration worked, Ruby merely took from Smalltalk’s experience.

And you also forgot another information, or you didn’t realize it: closures, or anonymous functions in general, can do much more than just iteration:

Want transactions? In Java, you have to setup and acquire your transaction manually, then remember to commit or rollback it at the end. How could you do that in Ruby? Well something along the lines of:

db_object.transaction do |db|
     # do stuff
end

You’re done, the transaction method takes a block and will handle all the low-level gritty stuff such as starting the transaction and committing or rollbacking it when then block has been executed.

Reading a file?

File.open “myfile.txt” do |f|
     # do stuff with your file
end

Once you reach the end of the block the file will be neatly closed, _always_, if an exception is thrown from the block the file will still be cleanly closed. No need to muck around with nested levels of trys and excepts and finallys just to be sure that you can’t leave a file open.

People usually show the iterative advantage of blocks via inner iteration, but that’s only because it’s the lowest level of simplicity, the one that shocks the most, and the one that _everyone_ will use first.

But blocks/anonymous functions/first class functions are not limited to iteration, far from that.

> In functional systems, this works because there are no side-effects. Thread safety is almost free. However, this isn’t true in Java. In Java you have to think very carefully about thread safety, and typical closure code doesn’t do that.

Guess what? Smalltalk and Ruby are not functional either. And most functional languages aren’t “pure”, meaning they’re not side-effects free (they nearly all use the single-assignment principle though) hence thread safety wouldn’t be “almost free” if they did indeed use threads (advanced concurrent functional languages don’t).

Correction.
The filter function is useful – and yes without the blubby (is that a word Paul?) looping constructs.
filter (<10) [1..20]
[1,2,3,4,5,6,7,8,9]

Prefer a higher-order function over loops – think about it some more.