Your conversation with the compiler is actually the same conversation a client would have with you, as a software contractor. From the client's perspective, you play the role of the compiler, interrogating and formalizing their own murky desires for them, and then coughing up a build-artifact for them to evaluate. This conversation just occurs on an even higher level, because a human compiler is smarter, and has a much more expressive vocabulary, than a software compiler.
...but the "goal" of compiler and language design should be to make that distinction, between the "software compiler" and the "human compiler", less obvious, shouldn't it? The more intelligence we add to the compiler, and the more expressivity we add to the language, the more directly the programmer can translate the client's desires into code. Until, finally, one day--maybe only after we've got strong AI, but one day--the client themselves will be the one speaking to the compiler. Not because the client will be any better at knowing how to formalize what they want than they ever were (that's the dream that gave us the abominations of FORTRAN, SQL, and AppleScript) but because the compiler will be able to infer and clarify their murky thoughts into a real, useful design--just as we do now. Wouldn't that be nice?
---
† If you use a language-platform that includes garbage-collection, for example, then you're not targeting a machine with "limited resources" at all; garbage-collection is intended to simulate an Abstract Machine with unlimited memory. (http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047...)