I am not sure what Steve Dekorte is saying...
A language that uses objects on the bottom can use them for everything, but a language with closures on the bottom needs other types or "atoms" for things like numbers, lists, etc and then scatter around functions for operating on those other types. If you care about simplicity, consistency and organization, this is a big difference.If you have objects, you still need compiler support for closures.
But if you have closures, you need no compiler support for objects.
Either way you need compiler support for other literals like numbers.
Unless you want to program numbers in the lambda calculus. And then too closures win.
7 comments:
Yes, you are right. I think Steve Dekorte don't know how closures works and what ever can do with this. If one using OO approach, can see object everywhere and is trying use object everywhere. Yes, OO approach can solve every problem, but there are some problems which are solved too much complicated with OO approach. If someone don't know anything else than OO, he can't see other and better solutions. If you have closures, you can code with OO approach and also other approaches. But if you have only OO support, you can use only OO. That is much worse.
Closures are more powerful but less user friendly.
User friendly wins :)
Maybe Steve meant that when you have closures you still need a facility to create custom types (for example, to dispatch on the type of an argument, or just so that printing one of your objects doesn't produce "#<function>".)
I find languages like R5RS Scheme, where there is no way to define new types cumbersome.
Paul Graham's type-tag-rep system is somewhat interesting, but I think new Lisp-family languages need to have a facility to define custom types (not necessarily the dreaded "objects".)
Re "Unless you want to program numbers in the lambda calculus. And then too closures win."
Actually it is not hard to define numbers and arithmetic using only objects. Just create an interface (or virtual superclass) Number with concrete subclasses Zero and Succcessor - everything else falls easily from then on.
The issue is not about composability (which isn't interesting as anything is composable from, say, assembly), but about simplicity and uniformity.
Bah. They're just duals of each other. The one you use depends on what you have and the semantic distance between what you want to do and what each is capable of easily.
John - How do you close over the lexical environment using "just objects"?
Post a Comment