>imperative programming is bad because of mutability >functional

>>61163729
>implying programming wasn't a mistake from the very beginning

Functional programming languages move stuff to the heap as needed, that's kinda important

>>61163759
Whey do you think you are? This is a product of a programming.

>>61163729
>>functional programming is bad because function application as recursion leads to stack overflow
>what is tail recursion optimization

>>61163729
>functional programming is bad because function application as recursion leads to stack overflow
*purses lips* WRONG

>>61164566
And you're implying that this is not a failure?

I think most people who come here, myself included, are failures, and that this just so happens to be where we commute.

Mutability is not bad, and stack overflow from recursion only happens with non-tail recursion or tail recursion with a bad compiler/interpreter.

File: 1496946648507.gif (3MB, 200x216px) Image search: [Google]

3MB, 200x216px

>>61163729
>>functional programming is bad because function application as recursion leads to stack overflow

>functional but inside the function you do loop instead of that recursion shit desu fampai wa

>>61163729
You just invented tail call elimination. Congrats. You're 40 years late.

File: 1498863625634.jpg (59KB, 1024x1024px) Image search: [Google]

59KB, 1024x1024px

>>61164532
>>61164594
>>61164604
>>61165129
>>61165104
nearly every language doesn't have these fancy recursion tricks built in

How can I expect to get that kind of optimization at a real job

answer: you can't

no answer: they'll totally let you use hasklel

>>61166839
>How can I expect to get that kind of optimization at a real job

Every JVM language but Java can do it automatically, using trampolines.

CLR supports it natively, C# and F# use it when possible.

BEAM supports it.

LLVM supports it (in limited fashion, sometimes you'll need support from the language frontend).

Modern JS engines support it.

... should I continue?

In any case, it doesn't fucking matter. Once you understand recursion properly it requires almost no effort to write a recursive algorithm in imperative form. TCO is only a must-have in languages that were designed from the ground up to depend on recursion and avoid mutability.

File: 1498863200010.jpg (98KB, 800x800px) Image search: [Google]

98KB, 800x800px

>>61166886
You act as if that's all enterprise languages but it's not. It's only a fraction.

Trampolining is not useful unless it is caked into the language. The whole point of recursion is to have a neat syntax for recursing easily so why even bother with function application at all.

All you need in order to get some real work done is to never mutate your variables or data structures. Only create and access but never edit.

A child can do it. I am really disappointed with all of you. I wish you could do better.

>>61163729

No, functional programming is bad because immutability leads to inefficiency.

The main reason to use imperative languages is for more efficient data structures.

>>61167335
Welcome to g where less than 10% actually have experience in the industry at a job that pays them for making something more than a simple web shit app/site

>muh tail recursion
>implying you even need recursion in cases where you can skate by with tail calls on constant memory (i.e. no stacks, queues, etc.)

File: pajeet_road.jpg (3KB, 300x57px) Image search: [Google]

3KB, 300x57px

>>61163729
>functional programming is bad because function application as recursion leads to stack overflow

Tail call optimization. Google it.

Captcha related.

>>61167367
>No, functional programming is bad because immutability leads to inefficiency

Immutable data leads to optimizations in tons of scenarios.