Objects are a poor man's closures (2003)
people.csail.mit.edu
people.csail.mit.edu
Closures are wonderful, but when you have access to a high quality piece of software designed to make holding state easy, why not use it?
A: If you drive your car backwards you get better mileage.
B: Well, I tried that, but my field of view is pretty crappy in the mirror, and the controls are non intuitive.
A: Well, your shitty car design isn't my problem.
Look, whenever you're trying to change someone's behavior, you are engage in marketing. This is an important skill in the startup world.
If you told your customer "our solution is better" and he responds "your solution sets my house on fire", you DO NOT WIN POINTS by telling him that he should get a better house.
You just lost the sale.
Not only that, you made yourself look like an ass.
If you want to sell closures, and the fact that pretty much all debuggers don't make using closures easy, this is not the rest of the world's problem - it is a legitimate reason for folks NOT TO USE CLOSURES. You either have to solve it, work around it, or realize that you're not going to sell the "use closures" meme.
This is a perfectly valid response if this was LTU or comp.compilers, but here on hacker news only a small percentage of us are actually in a position to "fix our language implementation".
Know your audience! If you are talking to language users (not makers), this comment just... well,
>> made yourself look like an ass.
In a sense, each time we write a function or an object, we are language makers. Too bad we don't considers ourselves as such, because makers actually bend the languages to their needs, rather than the other way around. Users limit themselves to a limited, defined, approved set of techniques (like function and object definitions).
I think any programmer worth it's salt should try and consider himself a bit of a maker. Not to play the Sorcerer's Apprentice, but at the very least to have the idea to call an actual Sorcerer for help.
Point the first: You are making the implication (intentional or otherwise) that closures are backward and that objects are the correct way to structure a program.
In any language I have used that has supported closures, they are not backwards. Indeed, the languages that support both closures and objects, closures are a well supported and idiomatic tool that is often used (for reference: C# 3+, Python, JavaScript, F#)
Point the second: "...the fact that pretty much all debuggers don't make using closures easy...". Every language I have used that supports closures supports debugging closures with the exact same ease as any other function. If you can pause your program and introspect a function, you can also introspect a closure.
If your are claiming that you can't introspect it from a repl, well you can't introspect any other function from the repl without additional debugging tools or instrumenting the code either.
I have no idea why you are talking about cars. It is totally irrelevant.
Andy, GNU Guile maintainer.
[Edit: downmods? I thought this was hacker news?]
[Edit: the poster is actually Anton van Straaten, replying to Steele]
My summary of the difference has always been, "Objects make good nouns while closures make good verbs."
For things like loop bodies, conditionals passed to filters, comparisons passed to sorts, etc., closures work very well. But when you start using a closure to e.g. represent an I/O endpoint (e.g. () => string for reading, string => () for writing to / from a console), you'll also want to do things like flush buffers.
Seems a reasonable personal preference when put that way.
What's more, is that it works "well enough" to at least be seductive. In Smalltalk, I can edit a method in the debugger and throw away the top part of the stack and restart in the current context yet only rarely deal with side effects. Granted, this is probably not good enough for something like a VOIP sever process relying on shared nothing assumptions for a robust concurrent architecture, but this may be one of the reasons that many OO programmers aren't eager to make the leap.
(Similar to explaining the utility of unhampered closures to some Python programmers: you can do a whole lot even with Python's limited blocks. Why is more needed?)
The thing that frustrates Pythonistas is people mistaking syntax for capability. Far be it from me to claim that syntax doesn't matter, but far too many claim that things aren't possible in Python when in fact you're just spelling it wrong. (And there are some pros to the Python approach; naming even modestly large functions is still generally a good idea, and Python's approach to the problem is uniform vs. Ruby's "several different type of code references" approach, which IMHO has the Perl problem of being gloriously more complicated and tricking people into thinking these are great advantages from a local perspective when in fact if you back out to the global perspective it turns out Python still does the same things, only without the complication.)
"...as you rarely need deeply nested scopes in Python because of the other things it supports."
This encapsulates pretty well the relative philosophical differences between Scheme and Python, I think. Scheme focuses on giving you fairly simple yet powerful syntax and semantics as building blocks from which you can build the sophisticated structures and control flow you need. Python focuses on building sophisticated structures and control flow directly into the language, so you need not be as concerned about the building blocks of the language. [Example: list comprehensions]
Is that fair?
Most of them. Needing it in Python is still an enormous design smell, though. It is very unlikely that it is the correct solution to your problem.
"The other issue, if I recall correctly, is that multi-line anonymous function syntax doesn't work because of Python's significant whitespace."
The Pythonic objection would be that you are getting awfully tied up in the word "anonymous". Even though I no longer think of myself as a "Pythonista", and even though I'm getting ever closer to Haskell, I still just do not get people's obsession with the "anonymous" bit. If it's small, use lambda. If it doesn't fit in a lambda, give it a name; compared to the body of the function how large is it, anyhow? Anonymity is not the important thing, the closure is.
One might as well complain that I am forced to name the parameters of functions. After all, I don't need to in Perl, why should I have to in your language? But exactly the same rules apply; using $_[0] in a one-liner is one thing, but even as soon as a five-line function, give it a name.
"Python focuses on building sophisticated structures and control flow directly into the language, so you need not be as concerned about the building blocks of the language."
Close, but this does miss one critical aspect of Python, which is that most of the syntax can be easily and effectively overloaded. Dot and square bracket can be overloaded, "properties" are actually special-cases of a more general facility ("descriptors" if you want to Google it), and so on (for quite a while). It is deliberately a balance between a highly fungible language like Scheme and a closed language like C. One of the things I learned from Python is that the number of things in your language that can't be usefully overridden by the user is an important criterion by which you can judge your later frustration level. Does your language hard code the module import procedure? Then how would you implement the Python "zipfile" module in your language? Does your language hard code what binding means? Then how would you implement "property" in your language? As a special case? Then how am I supposed to override that when I want something else? Does your class system have no concept of metaclass? Then you can't add it on later with any degree of effectiveness.
Note by no means am I claiming Python is the only language with this characteristic, it's just where I learned this principle. It's really hard for a general-purpose language to be so incredibly right in every way that it can hard code any of these things without causing trouble later. Typically communities that don't have these features grow enormous blind spots around them over time.
(Incidentally, even very "dynamic" languages can still end up with hard-codings in places that you might not even think of until you see another language that does it differently. Python/Perl-style overriding of the package load module is one example. In the world of C it simply never even occurred to me that maybe #include was way too hard-coded. How different would our technical history be if C had been able to actually do useful logic at compile time with includes, instead of it all ending up in Makefiles and config scripts? I'm not saying it would be better, just that it would have been different.)
PS: why is deeply-nested scope in Python a design smell? Rather than creating a closure of such complexity, you probably should be creating a class that implements __call__. This has all the features a class has available to it, it's very easy for the "call" to be nothing but a dispatch out to a generator if that's what you want, while at the same time being everything a closure can be. Needing three or four layer deep closures is the Pythonic equivalent to nesting your loops three or four layers deep. It may be the best solution in other languages, but it's not in Python. I think not very many people realize that creating such a class is one method declaration away. If you're doing significant programming in Python and you never override any of the double-underscore methods you're probably doing it wrong. (I tend to stay away from the equality ones, but the rest are fair game. Do you have any __iter__ methods? You probably should.)