Hacker News Reader

Comment by SomeStupidPoint | Hacker News Reader

Isn't it trivial to implement a loop via recursion?

    loop fn cond update i acc:
        if (cond i):
            return acc
        else:
            return loop fn cond update (update i) (fn i acc)

I'm not sure how using such a loop wouldn't be "functional", since you're not updating anything. (I believe you get TCO, so it shouldn't be that bad performance wise.)

View on HN

That's "functional", but I sure don't want to read it.

One of the things that I really love about Erlang, is that it unrolls loops and recursion like:

  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.

That's just a combination of pattern matching and tail call optimization. That code would look exactly this same in Haskell:

    countToTen n = countToTen (n + 1)
    countToTen 10 = done

The 10 case would have to be first, or that's an infinite loop. Cases are checked in order. That said, the compiler will give you a warning about it.

Why?

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.

Python (well, sort of) and C (despite its numerous other flaws) have a special syntax that doesn't read poorly, yes. The code you just described reads awfully. It's line noise. One of the most important aspects of a programming language is encouraging code that can be trivially read by someone who is familiar-but-not-reflexive with the language and does not necessarily understand the domain well enough to be managing both application state and syntactic state. If I have to think about what the code's syntax means, I'm not thinking about the problem.

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.

Are you sure you've got it the right way around? For-loops in C are syntactic garbage. "This is what I'm used to" is not the same as "this is good."

Why not? "What I'm used to" will tend to win in most usability studies. Weird and unfamiliar are harder to use.

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.

For readability and conciseness you would most likely use a fold instead.

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

> The fold/or Foldable interface factors out the mechanism of the traversal of the relevant data-structure - list, vector, tree etc.

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?

> Functional languages are an improvement in this respect over C/C++/Java etc with their explicit loop iteration statements.

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.

> For readability and conciseness you would most likely use a fold instead.

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.

Reply on news.ycombinator.com