He uses loops when he could use recursion

In many interpreted languages, recursion can use more memory and operate slower than looping through certain data structures. It simply depends.

recursion is slow.

itt: ppl who never use trees

Not every language has TCO, and you can't rely on it in languages like C, where you might get it when you turn on optimizations.
I wish browser developers took TCO in ECMAScript seriously, it would make the language a little bit better.

>he doesn't implement their own for loop
datatype for = to of int * int
| downto of int * int

infix to downto

val for =
fn lo to up =>
(fn f => let fun loop lo = if lo > up then ()
else (f lo; loop (lo+1))
in loop lo end)
| up downto lo =>
(fn f => let fun loop up = if up < lo then ()
else (f up; loop (up-1))
in loop up end)

>mlton.org/ForLoops
this can also be extended easily to implement for-loops with when-clauses, iterators over lists, or map-functions inside the loop.

proof?
Also, not sure if you're just a brainlet because you can do iterative recursion.

what in the name of fuck that isn't readable lol

Attached: 502.jpg (351x359, 19K)

>F# supports tail call optimization
>C# doesn't
sounds like a case for FFI if the optimization is a possibility

>He uses recursion instead of go-to statements

a definition of a for loop on integer ranges in SML using a custom datatype + recursion.
Can be used like this
for (1 to 9)
(fn i => print (Int.toString i))

That would print 123456789.

Loops and loop-like control flow always looks kind of like this when implemented in functional languages that don't have them built-in.
It's actually not that hard to get used to after programming like that for some time.

>he uses recursion when he could just copy paste the code a bunch of times

Attached: hysterically_laughing_emoj_classic_round_sticker-rd35dd53eb89e4d60adba09d75fbf8a6a_v9waf_8byvr_324.j (324x324, 18K)

>not using accumulator

Of course. Iterative solutions always have better performance and can't stack overflow.
The literal best case is that the language you use has tail call optimization and you happened to write your recursive function is such a way that the compiler was able to apply this optimization (And you usually don't even get a hint whether this occurred or not).

Recursive algorithms are a mistake. They only exist to please retards who think that what makes you a good programmer is being able to write hard to read code that even you won't be able to understand anymore in a few weeks, when it's actually the opposite.

>Recursive algorithms are a mistake
you know some algorithms require recursion right?

>The literal best case is that the language you use has tail call optimization and you happened to write your recursive function is such a way that the compiler was able to apply this optimization (And you usually don't even get a hint whether this occurred or not).
Some languages such as Scheme have implementations that require that the final expression in any function is always a tail call. In such cases it's trivial to find whether this optimization applies. A function like this
(define (rev lst)
(define (iter lst acc)
(if (null? lst)
acc
(iter (cdr lst) (cons (car lst) acc))))
(iter lst '()))
provably runs in bounded stack space.

Write a efficient fibonacci sequence in recursion and iteration, you'll see that iteration is always faster

Which? The Ackermann function?
Oh gee, that one sure is terrible useful.

Any tree algorithms.

As far as I know, there's none that can't be implemented iteratively.

Wrong, memoize using a linked list which you traverse recursively.

With an explicit stack, at which point you're just doing recursion but with more room for error.

>recursion implies hard to read code
>others are retards
Things like parsers are tremendously simpler to read/write with recursion.

You can implement any recursive algorithm iteratively, but when you have to manually implement a stack you might aswell not bother because the built-in function stack will usually be faster

>coding 4 loops with 2 nested loops inside using recursive

Attached: 1522123495563.jpg (651x750, 53K)

Always prefer iteration unless the implementation is greatly simplified and is expressed more naturally using recursion.
The latter is one of those things everyone wanks over like crazy, yet it's just another, arguably uncommonly used, tool in the toolbox.
Iteration just avoids a lot of problems that would come with recursion, fact.

Also fuck G*ogle for three times of "kek you mistyped the captcha, or the captcha malfunctioned".

>mutable state
that's a yikes from me

enjoy ur buffer overflow m8

For me, it's maps, filters and folds.

"happened to write"
found the brainlet

Functional programming
*pshht* *crack*
*sip*
Now THAT's a programming paradigm. Kids these days will never know what it feels like to spend five hours replacing loops with functions, all of which you need to come up with a name for, and filling the stack with a bunch of crap.
*crush*
I'm an old man. I need program states out of my sight.

Attached: 1538358675581.jpg (1500x1378, 425K)

>all of which you need to come up with a name for
lol

>Anime avatar
>40% keyboard (it's got LAYERS) with pink key caps
>5 monitors
>Know Haskell
Where can I collect my $300k?

Attached: 1468882928057.png (439x392, 199K)

>all of which you need to come up with a name for
man you really have no idea what you're talking about

You cant

Most languages will support TCO in five years. All popular programming languages adopt features from Lisp (the ideal language) a few decades afterward. For example, garbage collection, lexical scoping, closures, first class functions, metaobject protocol, exceptions, multimethods. TCO is coming.

No they don't, you can always simulate a stack by hand.

But the question, is why the fuck would you do that? It's often easier to write a recursive function than a stack/for loop. You should let the compiler optimize your code.

>exceptions
I wish they'd only take the good features.

Recursive implementation generally are slower because of the time and space overhead associated with making a function call and that function getting placed into the stack. Retards think recursion is better because it often has fewer lines of code and is easier to read.

Attached: 1511299116721.jpg (320x320, 17K)

you are the dumbest motherfucker in the world. NO old people (except some academic types maybe) like functional programming. Old people complain about kids these days and their type safety and pure functions and recursion etc, and back in my day everything was hard but now we have abstractions so let's just use them and get everything done, fuck prettiness fuck theory just get it done use java use the swing library or if we're doing something on the web lets just abuse the fuck out of javascript typelessness just for the fuck of it

If your trees are balanced you're always in the clear, if you know the depth is always at most log(n) then on a 64-bit machine that means the max theoretical depth is probably some small factor of 64. If they're not balanced but you know otherwise max depth or n is small then once again you're fine. If not then you're going to need to use a stack allocated from dynamic memory and a function with a very complicated 'loop' instead of a recursive function.

Iteration is always more efficient when you need to store previously computed data. Like fibonacci.

>hurr what is memoization

Attached: bglisp.jpg (500x225, 42K)

when computing fibonacci, you store the last 2 fibonacci numbers. those 2 numbers are used to compute the new numbers.

The real question is, are near jumps faster than far ones in x86?

> falling for ANY microspenis meme

>mistyped the captcha
do you really believe that goy?

did babby learn his first recursive function today?

produce :: (a -> a) -> a -> List a
produce f x = (x:produce f (f x))

Fight me non-haskell faggots

What makes you think you can't just pass those between function applications?

>not Lisp
Grow up fag

This.
>To iterate is human, to recurse, divine.

that shit's unreadable. just use standard ml and be done.

>He uses recursion when he could've used a loop

Attached: 1534073831385.jpg (418x396, 75K)

Cute boy :3

IT'S ELEGANT CODE TOO

(define (produce f x) (cons-stream x (produce f (f x))))

where is your god now, faggot?

By the time you've convoluted your function enough to only use tail calls the code has become a lot more complicated than it would if you had just used loops.

Not really, conversion to and from iteration and recursive forms is so easy that you can do it with a macro.
And indeed that's how it's done. Most Lisps come with loop macros.

casually remembering that time i made an array element removal and resizing function that was recursive and it ran like shit

Attached: 1436983778142.jpg (900x900, 151K)