Were you doing Windows development, about 10 years or so ago? If so, then I'm pretty sure you'll recognize the following.
The hard stuff, or more accurately, all the performance-critical stuff and the core components of your product would be written in C++. The functionality in the libraries you and your team created was then composed into COM components, and you designed interfaces, wrote IDL and created type libraries which exposed the component functionality to the outside world.
Lesser mortals could then use COM-aware languages and tools, like Visual Basic (VB), to create sophisticated applications to exploit the power of those components. Component-oriented software development was a reality. UI designers, the subject-matter experts and the VB programmers could get together and build something using your C++ classes, all without having to know about vtables, pointer arithmetic, or what a pure virtual function is.
It wasn't perfect. The COM abstraction was somewhat leaky because even when using 'scripting languages' like VB to combine COM components, you still needed to understand COM's reference counting semantics, and marshaling of data across the COM boundary wasn't always straightforward. But the benefits manifestly outweighed any of the technical difficulties.
With Java and especially .NET we moved away from the idea that we'd build lower-level functionality in one language and use a less formal or type-safe language to 'script' applications on top of it. Microsoft have always claimed that mixed-language development is a cornerstone of .NET and the CLR. It's certainly true that the CLI does explicitly set out to enable multiple languages to target the infrastructure, but this misses the real point, which is that relatively few projects appear to have exploited this. Most .NET solutions are developed in just one language, either C# or VB.Net, the choice usually made early, based more on team culture than on technical grounds.
I haven't heard anyone saying "Well, we used C# for the hairy low-level components, but we built the application itself in VB.Net because it's so much quicker to prototype". Does this happen now? I don't think so, yet back in the C++ / VB world, it really did.
I believe we are in a roughly similar position now, with respect to building complete solutions, as we were when VB and C++ were joined at the hip via COM. We want the big languages and frameworks for building powerful libraries, for high performance and for when we need (or get real benefit from) strong, static typing. But we all want to use these lovely new dynamically-types languages like Ruby, Python or Groovy because they're concise, powerful and fun. Look what I can do in 5 lines of Ruby! It would take 50 lines of Java to do that! And just look at the clever metaprogramming stuff! Wait! These languages are great! Why don't we write everything this way!
Now think back to VB ... who remembers this book ? This was one of those landmark books you recall long past the time you stop consulting it. Part of the charm of this book was the writing of Bruce McKinney, who managed to combine a determination to wring the very most out of VB with an iconoclastic view of Microsoft, the very people who both developed VB and published his book! I liked the book, and I loved the writing. Plus, it really was hardcore: if you paid attention to the book and practised what it preached, you became a better (or at least, more capable) VB developer.
Now, I'm not trying to suggest that Ruby (or Python, or ... etc.) is/are no better than VB6, because that's clearly nonsense. But I am suggesting there are strong parallels between the two situations. With the dynamic, interpreted languages like Ruby and Python we have flexibility, speed (of development) and agility, and we can get something running without all the troublesome attention to detail required by C# or Java. Just as we liked the VARIANT type, we like dynamic (and 'duck') typing, and we like the syntactic economy of not having to use type names everywhere.
So we have a similar situation now to that which existed when VB was at its hardcore height: the evangelists and enthusiasts want to build absolutely everything in Ruby (or Groovy, or Python, or etc...), whether it makes sense to or not. The problem is the 'evangelists'. Or fundamentalists - you decide which term you prefer. Their enthusiasm for their favourite language unfortunately causes them to stray into deeper academic debates concerning type systems. They are so anxious to promote their chosen path, they want to convince the rest of the world that you really don't need static typing, even that static typing cannot save you from anything, so why bother with it? Do everything in <someDynamicLanguage>. Hardcore! I'm not going to wade in to the silly static typing versus unit testing squabble. The essential point is that serious issues are often hijacked, trivialised and misrepresented to serve as ammunition in some language or platform flame-war. Here is an excellent, sane post, as an antidote, discovered as a link in this piece by the equally excellent Tim Bray.
The analogy I'm trying to use is a little strained, I will admit: VB was a fundamentally weak language (see Bruce McKinney's departing missive), whereas Ruby is not. The difference between then and now is that there is no need for a 'Hardcore Ruby' book because you don't need to strain at the boundaries of the language to do powerful things. The similarity rests on the fact that with technologies like JRuby (and IronPython) we have the ability to use a variety of languages and approaches to attack the different layers in our solutions.