1.) Previous skills with Mako, SQLAlchemy, Paste, or any of the other libraries that Pylons or Turbogears is based upon.

2.) Previous code in one of the above libraries

3.) Functionality needs that Django cannot satisfy in at least a couple of the following areas: authentication, user models, multiple database support, template extensibility, deployment. I say "at least a couple" because if you just need one, you can import it like you would in any other framework. The price is that many existing Django add-ons won't be aware of your choice.

Bad reasons include:

1.) "Django's only for CMSes." Not true; it works just as well for anything that involves web apps, including AJAX apps.

2.) "It's not scalable enough." The Washington Post runs on Django; I doubt you're going to get more pageviews than them.

3.) "My data doesn't easily fit in the relational paradigm." That's what the import statement is for; you can hook any data source you want up to a Django view.

4.) "Django's templating language is too restrictive." That's what template tags are for.

5.) "I'm really doing a full-fledged AJAX app, not a website." You can output JSON or XML data from a Django view as easily as HTML, and you're not limited to any particular JavaScript library. (I actually think Django views are more convenient for this than Pylons controllers; there's less boilerplate.)

The most likely possibility is that there isn't one. Google is a company built by academics with Ph.D.s who were so successful, so fast, right out of school that they've concluded that the secret to life is being a Ph.D.-level academic. Believe me, that's a serious occupational hazard among those of us with that much education. It's the classic trap. You're constantly tempted to fall back on the fallacy that anything you spent so much of your time on must be intrinsically valuable.

So they've built a think tank. It's no better or worse than other think tanks, like the MIT Media Lab or Xerox PARC or Bell Labs or Agilent Labs or IBM's old labs. Like those institutions of yore, Google milks its enormous cash cow and uses the money to fund pie-in-the-sky projects. Some of those projects will eventually change the world... perhaps after their creators leave Google and found startups. Others of those projects will circle round and round forever. Still others don't amount to anything, but because their inventors are under very little pressure -- why fire them, when you can just ask the cash cow for another $2 million to keep them on staff? -- they persist.

I think it's a mistake to assume that most of the Googlers are working on "destructively taking market share from Paypal". Google's core assets work too well to be the product of a giant committee. I'm guessing that the technical portion of the SEO-fighting arm of Google is just a dozen people, with perhaps another two dozen assistants. Another huge group of people is sales reps and customer service and other things that don't scale well. Most of the rest of Google is a giant research organization, dedicated to searching all of known phase space for the next cash cow. If they find it before the current cow gives out, Google gets another 20 years of profits. If not, Google will eventually explode.

Sometimes that strategy works. From the outside, it really is eerily similar to the early days of Apple Computer. Apple was much crazier, in fact: In the early '80s they were rolling in cash and therefore had absolutely no incentive to impose fiscal discipline. They reportedly ran open-loop, without a budget, for several years. The company was a free-for-all collection of quasi-independent projects that sometimes contradicted each other. And that very nearly doomed them to be squashed by IBM... except that, whoops, one of those tiny one-person pie-in-the-sky research projects was the guy working on the Macintosh. Then Steve Jobs found that guy, seized the project, and it became 12 people working to ship the Macintosh. And eventually the Mac became the next cash cow that bought the company another 20 years.

But sometimes your think tank is Xerox PARC, and it becomes most famous as a place where brilliant engineers get all their training and practice before eventually quitting in disgust and founding the startups that actually make all the money. There's real danger that Google will follow that route. Caring and feeding for a think tank is a difficult job, one that Google's founders aren't necessarily cut out for. It's not like they're magically immune to the Peter Principle.

We shall see. But I wouldn't worry that the Googlers are wasting their time. History suggests that frustrated think-tank refugees can be incredibly productive startup founders. They have Things to Prove.

I can only speak for the East Coast, and in microeconomic terms, but Google has definitely put a hurt on the market here. They are worse than all of the banks put together. The cream of the crop here---people who are too smart to veg out in a bank---are more than willing to go to Google, when they would otherwise be furthering some smaller and more important project, be it a startup, or just something else useful and in real need of a bright, computer-oriented mind. They're all funneling into Google. Google got them all right out of college, and they're probably going to keep them.

You cannot argue that we are better off this way. Google certainly is, but as a whole we are going to lose out. Clumping all those people together is not going to improve technology. It's going to make it worse, because there's a huge opportunity cost in taking all these people and sticking them in a mill. That's just how software works. If they were out in little groups in a lot of different areas, they could be making a huge difference. Google doesn't need 10,000 engineers who know Bellman-Ford and Knuth-Morris-Pratt and Miller-Rabin. It's too much overlap. And Google certainly isn't providing offerings in a quantity great enough to justify the overlap. They've hired well---too well---and now they're going to be having a great number of these people performing well below where they would if they were arbitraged out to somewhere else. The benefit of adding just one of these engineers to a smaller shop is incalculably higher than the benefit of giving him to Google.

That efficient asset allocation, and the providing of liquidity, have been grossly exaggerated in terms of their benefit to society in order to justify the poaching Wall Street does each year, is a truth generally acknowledged. Trading makes a few people much richer, but it does not make us richer, not in equal part. In fact, if you want to get nasty about it, the latest round of bailouts is costing us a great deal...

Now we've traded the Wall Street problem for the Google problem. Do we really need the top sliver of our graduates working on destructively taking market share from PayPal? Or fighting black-hat SEO fueled and exacerbated by the search-monopoly problem they created? Or contributing to an advertising arms-race at a growth rate much higher than that of the underlying market?

What project are they pushing forward that could possibly justify sitting on all this talent? I feel like if it was anything suitable I would've already heard of it by now.

For the same reason that I'm willing to fly to any large airport without knowing for sure that there will be a taxi waiting. There almost always is. And there almost always is a way to make money out of anything a lot of people find useful.

1) SBCL working very well on the big three PC platforms. 2) Bindings + easy installation for popular libraries. 3) Education (pg's articles, everything on planet.lisp.org) 4) Solid debugging, perhaps with things like breakpoints.

There is much activity on all 4 problem items that I identified above, so Lisp IS getting more popular. I don't know if programming.reddit.com can be a scientific gauge of how popular Lisp is, but it seems to be mentioned increasingly often.

Of all the problems Lisp has, parens are much less than the problem that it takes a gigantic effort to use Lisp with any popular libraries, once you step outside of the way that the larger community is using it.

Just FYI, the Washington Post does not use Django for their main page. They only use it for small side projects.

At reddit we tried to use Django, but had to switch to Pylons because, lo and behold, it wasn't scalable. Specifically, it has a problem caching templates under high loads.

Satirising two large companies so comprehensively in one sentence is brilliant.

Git was the leading contender. Yes, Git rocks, but there's more to it than that. When your SCM of choice also hosts the Linux kernel (and, indeed, was developed for that very purpose), you know it will never be abandoned. No serious bug can last for long. That risk mitigation is worth a lot, and it's one of Git's biggest strengths.

I realized about three months ago that Git was going to win. I'm not sure what tipped it, but it made me happy: partially because I felt proud to have figured it out, but mostly because it meant I could stop agonizing about which SCM to use.

Viva Git!

b.) Don't worry about that - doing AJAX well depends a lot more on your JavaScript skills than on the server-side technology used, and for anything serious, you'll need to know real JavaScript. Pylons does have a nice shortcut in that they ported over all the Rails JavaScript helpers, so you can get simple things like pagination, reloading divs, and JavaScript buttons without actually using any JavaScript. But they implement this using Prototype, which is a library that I personally refuse to touch for the reasons in b.3)

b.2) There're actually like 5 different JSON libraries for Python, and you can mix & match them with web frameworks (they just output a string, and any decent web framework will let you send a string to the browser). I use simplejson (which comes in the standard library of Python 2.5 - no installation necessary) for flexibility and cjson for speed.

b.3) Stay away from any JavaScript library that messes with the prototypes of built-in object types or adds lots of functions to the global namespace. The bad list includes Prototype, Mootools, and 99% of random JavaScript snippets you'll find on the web. The good list includes JQuery, YUI, and any libraries built on them. The reason for this is compatibility: JavaScript has no native namespacing support, and so if you get 3rd-party libraries from two sources that don't pay attention to namespacing, they invariably end up stomping on each other's functions.

b.4) If you're serious about doing an AJAX app, take the time to really learn JavaScript well. My last employer thought they could paper over all the dark corners and browser incompatibilities with AJAX JSF components; they always ended up coming back to bite us in the end. Know what you're doing. The Rhino Book and John Resig's "Professional JavaScript" are good sources, as are the websites of Doug Crockford, John Resig, and Dean Edwards.

b.5) Start by doing non-AJAX apps with Django and only add AJAX when you absolutely need it to improve the user experience. Aside from flattening the learning curve, this also disciplines you into treating AJAX as an additional tool for the toolbox, not a buzzword. A lot of companies have gone AJAX-crazy (like my last employer) and are treating everything like a desktop app when they should start as a plain webapp and only add additional interactivity when necessary. The web succeeded for a reason; trying to recreate the desktop in a browser is a step backwards.