|There's more than one way to do things|
Re^5: Real life uses for closures. (update: disambiguation)by LanX (Canon)
|on Feb 13, 2013 at 23:25 UTC||Need Help??|
> I was also quite happily solving my programming problems in languages that don't support them for 15+ years before I became acquainted with them.
I agree and as I said closures are somehow the other side of the OO coin in allowing encapsulated variables.
Just more elegantly done with less code in most languages.
It's like saying why do we need lexical variables, as long as we care about chosing the right package-namespaces we can achieve the same. True, but most of us don't wanna code Perl4 anymore!
> I've been reading a lot about constructing interpreters and VMs lately, and one thing that seems common to most new ones is the seemingly obligatory inclusion of closures;
I think it's also part of the feature competition. Like "What you have no App to shave your legs on your new smartphone"?
OTOH what I really like about JS is that it does FP (almost¹) excatly like Perl, while Ruby and Python suck at closure side-effects.
IMHO it's far easier to port FP-patterns than OO-patterns, and closures are indispensable for it.²
Saying this you might have noticed that some participants in this thread didn't really know what closure.
So yes you, can be a very efficient programmer w/o closures.
¹) well exactly if you have a dialect allowing to swap var with let.
²) And we have this "one package per file" paradigm, which forbids to just add another encapsulation on the fly. (No fun discussing the perl critic addicts)
IIRC correctly there was a nice thread where GrandFather solved a problem with an embedded mini-class where I used closures... If I can find it, I'll update.