I've found that the concept of anonymous functions is the biggest hurdle to get over -- closures seem to follow as a natural extension of that.
I explained this to someone recently in the context of event handlers in ActionScript/JavaScript, starting with the idea that when you do:
something.onclick = function(){...};
you're passing a function around just like it was any other value.
Then I moved to an artificial example of a 'magic function-making machine':
function giveMeAnAdder(baseNumber) {
return function (i) {
return baseNumber + i;
};
}
with a couple of examples of storing and using the functions that giveMeAnAdder returns.
Then I pointed out that, normally, local variables in a function disappear when the function returns, so how does my adder 'remember' what baseNumber is? And the answer is that the anonymous function is actually a bundle of a function body and the local context, and we call this a closure.
Can people please stop using the "make adder" examples? Can't you come up with something original and fresh? The triviality of what is acomplished in such case actually obscures the usefulness and power of the concept. As a result, the novice will interpret the end product as some useless, magical mambo jumbo that doesn't give him much. So who cares if I can get a function that adds a number to something. I have a "+" for that. Give me a use case that I can admire...
Why do you want me to appreciate a ferrari if all you do with it is go pick up some groceries...
I agree that for a novice a trivial example doesn't inspire them to learn more. But an experienced programmer who just wasn't familiar with this concept might appreciate more a stripped-down example like this that demonstrates the essentials of the idea. And in general, different people have different learning styles.
That's why I use a counter as a simple demo - you see state changing with each call and it's done without using a global or passing in some kind of context object. It's not a lot more powerful than the adder, but in my experience it more often generates a "what the hell..." kind of reaction to the uninitiated.
"Original and fresh" is generally not conducive to understanding. People are more likely to understand a new concept when that new concept is applied to concepts they already understand. It lets them filter out everything but that concept.
This is my approach as well. JavaScript provides a very natural syntax for it, and the use case of "make me an event handler with some stuff baked into it" is extremely obvious and prevalent.
I thought this a while ago with Basecamp. Although I'm sure they use it internally to manage their own projects, since they don't do client work anymore they're not using it for its primary use case, which is collaborating with clients.
It's not as huge a gap as with Haystack, to be sure, but anyone who's tried to get non-webhead clients to grok/use Basecamp will know what a struggle it can sometimes be. People have been asking for years for the app to have more help/guidance that's geared towards client end-users, rather than the agency account owner.
As for Haystack, I sort of see it as a (reverse) extension of their job boards, which seems to have been pretty successful for them despite not being something they themselves use very often.
We use Basecamp constantly. We have about 25 active projects running at any one time. We also use Backpack, Highrise, and Campfire all day and every day.
It's slang from Cambridge University (and maybe elsewhere, but that's where I encountered it) for a student studying mathematics. Related: 'NatSci' (pronounced natskee) for someone studying Natural Sciences (the course that covers all the traditional physical and biological sciences); 'CompSci' (pronounced compskee) for people studying Computer Science.
OAuth is great, but the app doesn't actually say what it's going to do with my Twitter account. Developers especially are wary of handing over access to their accounts (OAuth or not), so it might be good to summarise what your app will post before making the user authenticate.
