In language acquisition there is a hypothesis called the "Input Hypothesis". It states that *all* language acquisition comes from "comprehensible input". That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
(Bolding is mine)
Oh goodness gracious no! I've worked with such (usually self-) taught programmers (and been one myself before I got a degree). The difference between Computer Science and "speaking a language" is that one has the goal of being merely mutually comprehensible, and one has the goal of efficiently and meaningfully dealing with large amounts of data.
To give a more concrete idea: Being long winded or speaking only in one-syllable words can be annoying, and is simply corrected by example and further experience. Writing code that's O(2^n) or worse when there are O(log-n) solutions is not something one can learn by observing examples of code that's one or the other, unless one is the sort of naturally gifted mathematician that wouldn't have written the O(2^n) code in the first place.
I had to go look up the "Input Hypothesis" on Wikipedia, which happily led me into the associated "Monitor Hypothesis", which indicates that without conscious knowledge of the rules of a language, one cannot effectively self-correct; i.e., one cannot say why one says what one says and what one doesn't say.
It does sound a little like the "immersion" idea of language learning, which in my limited understanding is understood to be next-to-useless without a supporting framework of formal education, once you hit five and Chomsky's Language Acquisition Device switches off (or whatever the current theory on differences between adult and child language acquisition). I don't argue that immersion in good code is important, but it's not _sufficient_.
One other thing, we've here contrasted programming as a profession, with speaking a natural language. If you speak or write a natural language as a profession, then you really should be as consciously versed in the technical aspects of the language as a professional programmer should be. And vice versa, if you're just programming for fun, or relying on someone else to hand you pseudo-code to implement, then it's perfectly fine to simply produce code that works. But doing such won't make you more hirable.