5 ms·

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 rele

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.

eropple 9y ago
> 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?
rbehrends 9y ago
> 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.
seanwilson 9y ago
> 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.

eropple 9y ago

> 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?

rbehrends 9y ago

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

seanwilson 9y ago

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