| 2007 10 16 |
Objects vs Closures
Simplicity
A language that uses objects as it's building block can use them for everything, but a language without them on the bottom needs other types or "atoms" for things like closures, numbers, lists, etc and scattered functions for operating on those other types - in other words, you can never have a "pure" language if you go that route. If you care about simplicity, consistency and organization, this is a big difference.
The Composibility Argument
It's often suggested that since closures can implement objects, the closures + atoms model is preferable to the everything-is-an-object model. Of course, one can also implement anything in assembly... Composability isn't interesting - it's simplicity and uniformity that are of value.
Power
What people often refer to as "functional programming" is the ability to pass references to executable code (map/reduce/select/filter, etc), which isn't truly functional programming as it can be done without referential transparency, and for that matter, without functions (via references to expressions). With objects, we can have all the power of such techniques and without the complexity of piles of atoms and scattered functions and multiple inconsistent semantic levels.
|