count_to_ten(n) ->
count_to_ten(n+1);
count_to_ten(10) ->
done.
which is much cleaner than how the same code is presented in 99% of functional programming languages. countToTen n = countToTen (n + 1)
countToTen 10 = doneThe fold/or Foldable interface factors out the mechanism of the traversal of the relevant data-structure - list, vector, tree etc.
Functional languages are an improvement in this respect over C/C++/Java etc with their explicit loop iteration statements.
So does an iterable/enumerable in anything else (writing a red-black tree that supported the Iterable interface in Java was something I did in college). Certainly not a material improvement over explicitness that, unless you have a rather particular shop, your fellow programmers won't have to scratch their heads about three weeks after you commit it.
I have been the too-clever-by-half developer before. It was a bad idea. The principles of functional purity as a design goal do not have to have the baggage of "look at this neat thing I know about," yanno?
Not to put too fine a point on it, but Smalltalk had folding way back when (inject:into:). Higher order functions are not a specialty of functional programming; technically, even C has higher order functions, they're just more verbose because C doesn't support inline closure literals.
Agree strongly with this. Long complex for-loops in imperative languages that are mutating a counter along the way, building up a list along the way, have "if (...) { continue; })" parts, have nested loops etc. make me cringe now.
Break your code up into a series of folds, maps and filters and it's miles more readable. I find a lot of imperative programmers just don't think in this way and mangle folds, maps and filters into one big confusing ball.
I'm genuinely curious why you think that it's worse in functional languages than, eg Python or C.
It's not like you don't specify all of those variables when using a loop in C -- you just have a special syntax to. I was outlining the actual recursion mechanism, not showing what you'd have to code....
You can make it look basically the same, with a signature like...
loop (idx test update) fn acc
...which in practice will look like... loop (0 (\ x -> x < 5) (+1)) fn 0
The only annoyance is the slightly verbose lambda syntax for the test, but if you're using a function as a test, it becomes a smaller issue.And, frankly, the idea that you have to soft-pedal it as "you could do this" should be a red flag for you. I could meditate about a `loop` function or I could write the code I actually care about.
Looking at how human languages work, it's hard to see how it could be otherwise. Your own language is always going to be easier to use than an unfamiliar one.
And this is why language debates can't be settled via logic alone.