Comment by ErotemeObelus | Hacker News Reader

Comment by ErotemeObelus | Hacker News Reader

Parent Full thread

Recursion is the worst way to do iteration because it requires cleverness (= harder to debug) and it's ridiculously easy to cause a stack overflow. A for-loop is not going to cause an integer overflow on a 64bit architecture.

Closures are basically global variables and inherit all of the problems with global variables.

Continuations are basically goto's or memcpy and inherit all of the problems with goto's and memcpy.

Functional programming is ALL of the bad programming practices of the '80s. But because it's more abstract and mathematical it gets a free pass. Nevermind the fact that computer science is not mathematics. And the benefits of mathematical abstraction DO NOT TRANSFER if they inherently violate the commandments of bad ideas like global variables and goto's.

There are solutions to ALL OF the object oriented problems--including the diamond problem, circle-ellipse problem, and overuse of type hierarchies. There are no solutions to the functional programming problems because they inherently incorporate bad ideas described in paragraphs 1, 2, & 3.

> Recursion is the worst way to do iteration because it requires cleverness

No, it doesn't; in fact, recursion is usually much easier to reason about, particularly in terms of termination.

> and it's ridiculously easy to cause a stack overflow.

It's ridiculously easy not to, just assure your recursive calls are in tail position and you are using a language that supports tail call optimization (which essentially every dedicated FP language and a number of others do.)

> Closures are basically global variables

No, they aren't even similar.

> Continuations are basically goto's

Not really. They are similar in that they are a more powerful (and, therefore, dangerous if used incorrectly) flow control concept than simple function calls, but they aren't equivalent to gotos.

> Functional programming is ALL of the bad programming practices of the '80s.

No, that's unstructured imperative programming (though some structured languages preserved some of them.)

Closures are as hard to reason about as global variables are. Anywhere the function with the closed variable is called, that is the same thing as invoking a global variable, because that function could be called anywhere in the entire program. The difference is that the garbage collector deletes it when no function is calling it any longer.

Continuations are equivalent to memcpy... which should almost never be used. And tail-optimized recursive functions are still difficult to reason about.

And tail-call optimization (making stack calls constant) is... kind of self-defeating... because the only advantage of recursion is that it has a stack built into the function call/return operations. Anything a recursive algorithm can do is equivalent just a for loop and a stack data structure. And if you're tail-call optimizing it so that it has a stack parameter... then you're just using a clever way to write a for-loop :D Except functional doesn't allow for you to mutate a preexisting stack so you're also wasting space recreating a new stack each function call.

Yeah. Abstract math almost rarely transfers directly to the computer world. There's a reason why the pure functional & concurrent language Erlang was only used in telecoms and languished in obscurity: because that was the only domain it worked well in.

Err, I meant setjmp, not memcpy. Quite the faux pas!

Holy shit. You're into something here. Hey, you should immediately send letters to companies like Wallmart, Apple, AT&T, etc. most of them are in Fortune 500 list. They all use functional programming languages. You could save them billions!

Computer science uses a completely different system of logic than mathematics or mathematics-inspired paradigms like functional.

Fortune 500 companies aren't attracted to functional. They're attracted to the TYPE systems of many functional languages. And type systems are good. But you can build e.g. a dialect of C or Pascal using those exact same type systems with no functional programming at all.

Oh yeah? How do you explain then proliferation of FP idioms and libraries in PLs like Javascript and Python? Or success of Clojure and Elixir?

Python tries to move away from functional idioms whenever the developers realize that the idiom can be severed from the paradigm. E.g. Python's switch from filter(list, p) to [x for x in list if p]. Guido van Rossum feels that the imperative way is easier to understand and so do I.

Functional programming languages have good ideas, like type systems or lazy evaluation. But many of these ideas are NOT INHERENT to the paradigm. Perl6 incorporates almost every functional programming idea but as an imperative language.

Reply on news.ycombinator.com