Closures Considered Harmful

In the journey of ComputerScience a fork was made in the path. One path went upwards to abstraction, one path went downwards towards "the machine". The former developed closures, LISP, and GodClasses (see the PythonLanguage) which have created such excellent creations as Javascript and such, but has turned into a dead end, an AntiPattern.

Correction, lexical closures are fine. The problem is only with "magical" closures with Java code run without the local, client VirtualMachine.
What do you mean by "'magical' closures"? What do you mean by "running Java without the local, client VirtualMachine"? Do you mean GCJ?

Dead end? Really? How so?

One must now follow the OneTruePath.

What makes you think that is the one "true" path, as opposed to many others?

See also: ConfusedComputerScience.

The confusion, it seems, is not with ComputerScience. Time to look within, Glasshoppa.

"It seems", he said, substituting a slippery predicate for an actual statement.... I have looked within and to the end of your world. YOU, sir, have not understood.

Then I invite you to show how closures are harmful. Be sure to clearly define what you mean by "closure" and "harmful". Illustrate, if possible, with code.

There are no such "invitations" -- where I do the work for you. I have challenged you. Except for functions, closures are an AntiPattern.

Why do you think they are an AntiPattern?

To prove that closures are not harmful? The very fact that they exist, are being added to programming languages and are generally regarded as a GoodThing amongst developers, is evidence that they are at least not universally considered harmful. So far, yours is the unsubstantiated and rather strong claim. Strong claims require strong evidence. Rather than engage in ShiftingTheBurdenOfProof, can you present us with a thesis that demonstrates how closures are harmful? If not, we'll have to assume this page is nowt but spurious pot-stirring, with no evidential basis.

Show me how you implement a "closure" at the machine-level, in assembly, or in standard C without extensions.

Really?

Yes.

{A closure simply captures local variables. Trivial, that.}

It's not that trivial, when one has to maintain references to memory locations.

[It's no worse than anything else you put on the heap.]

You don't know what you're talking about.
Actually, he does.

Indeed. See, for example, http://www.hokstad.com/how-to-implement-closures

Thanks for that article. It shows how convoluted one has to get. He's dropping into assembly from C and pushing things onto a stack. I happen to know that it won't be stable, but will review that information....

Why do you think it won't be stable?

[The assembly and the convolutions are optimizations. They aren't necessary to implement the closures. All you need are the first three code snippets after "Indirection Hell" and the code snippet after "Fat Pointers".]

Having implemented closures in the RelProject, my experience is that they're straightforward to implement -- not particularly complex or difficult -- and they add to the expressiveness of the language. Whilst not currently exposed in the RelProject's TutorialDee implementation, closures are internally used extensively. Without them, the implementation would have been considerably more complex and difficult. So, for minimal implementation effort, a significant gain. I can't consider that "harmful".

Closures are harmful where garbage collection is unacceptable. See KernelMode?, HardRealTime, or any time OutOfMemory? must be handled gracefully.

Well, yes. But then it's not typical to find closures implemented in languages designed for such (generally) low-level contexts.