That would be Jeff Atwood's blog CodingHorror. I remember the article.
I don't terribly much care for the tools/toolbox/workmen analogies very much. A programming language is like a programming language.
Saying a programming language is like a toolbox implies it has spatial boundaries like a toolbox, that it could get rusty if exposed to the weather like a toolbox, that you have to keep the tools organized in the toolbox yourself or nothing will fit properly. There's just any number of absurdities that comes from trying to think of a programming language as a toolbox, and tutoring programming has taught me that beginners *will* make those absurd assumptions and hold them dear if you don't keep them out of their filthy little hands.
Programming languages are like condoms: you don't really want to have it, but at least you like what you're doing while you're using it, but holy hell is it gross after you've been done with it for a while. See, you can make any analogy you want. Analogies are bad.
There isn't any upper limit on what a particular language can be designed to do. There is no particular reason why functional or declarative or aspect oriented or procedural or object oriented programming should or should not mix with <refer to previous list, shifted one over>. And there is no reason why having them all available should inhibit your ability to learn the language. Is Ruby a DSL mess? Yes. Was Ruby designed by stellar programmers? Global Interpreter Lock says no. Going on twenty years old now and still only a half-assed attempt at Unicode support.
Because really, having *more* features, *more* expressiveness, makes any language easier to learn. Just imagine if we were all still programming in assembly. Just imagine if we were still trying to talk with nothing but grunts and whistles.