Joel's latest essay on writing big enterprisey apps boils down to two pieces of advice:
The safe answer, for the Big Enterprisy Thing where you have no interest in being on the cutting edge, is C#, Java, PHP, or Python, since there's so much evidence that when it comes right down to it zillions of people are building huge business-critical things in those languages and while they may have problems, they're not life-threatening problems.
That, and anything other than those four choices for a platform are "unsafe". So pick whichever one you are most familiar with, and run with it. And, if you really want to try Ruby on Rails, do it in your dorm room, where it doesn't matter when you fail to scale up.
Of course, you know the drill by now. Insult Rails on a high profile blog, expect an immediate response from DHH pointing out exactly where your arguments are categorically wrong because, as we all know, Rails is the best thing ever done with a piece of software.
For my money, both Joel and DHH miss the point entirely. It's not about picking the popular tools that the corporate developer lemmings have blessed as safe. It's not about taking throwing PhD's into a room, giving them Lisp, and expecting great things. And it's not about the war between static and dynamic languages, dumb vs. crafty frameworks, or convention vs. configuration.
It's about understanding the problem, understanding the tools, and building an appropriate solution.
If you take Joel's argument at face value (and that's all it is, a philosophical statement devoid of data or a provable hypothesis), and look back 10-15 years ago, you'll find you have an argument in favor of the status quo: large, mission critical apps running on DOS/Win3.11 + Netware, written in dBase, FoxPro, Clipper, or their ilk. These tools were simply not up to the job, yet as demonstrated by countless unnamed "enterprise" projects, they were suitable for any big enterprisey project.
Yet these were the worst kinds of tools for these jobs. Or, rather, these weren't the tools you really wanted to solve these problems, but they were the best that was available for the slow, underpowered machines of the day. And they sucked. And everyone knew they sucked.
What was the answer? Move away from DOS, move towards Windows (3.x), and client/server programming environments. Brand new and obviously better solutions like SQLWindows, PowerBuilder, Visual Basic, and I forget what else. (Even Smalltalk was a contender for a small number of projects as well.) And if you didn't want to risk an unproven language, an unproven RDBMS, an unproven vendor on a big important project, there was always C and C++ on big iron Unix boxes working with CORBA ORBs. Or, if you were really daring, C++ on Windows with COM (soon to be new and improved, once 32-bit Windows stabilizes).
But were any of those choices the answer? No, not a one of them. (Except VB, which, when adopted widely, wasn't the same language or environment as the anemic offering available for Windows 3.x.)
The lesson here is that the solution blessed by masses of corporate lemmings, isn't always the right one, and the obviously better pitched by Vendors Who Know isn't necessarily the right solution either.
It turns out that the right solution here was the web. And it took a decade to discover, adopt, figure out how to write webapps, and wait for the browsers to be debugged enough. Once everything was in place, we all could move away from the slow, buggy, kludgy, enterprisey development projects that really weren't as solid as they needed to be, and start talking about more fundemental problems, like how to model your data properly.