Perhaps you saw a study of the accuracy of non-programmers cargo culting the syntax of programs to write new programs. (For a good laugh, read an apologia for methodology problems in the study.)
Here's the problem with most attempts to teach non-programmers to program: programming is a creative process of solving problems, not an exercise in arranging atoms in the proper order.
It's as if we expected teach people to write great stories by giving them exhaustive grammar lessons such that they understand tense, mood (in the imperative, subjunctive, et cetera sense), and declension while neglecting study of plot, character, and theme.
Certainly we can and should discuss ways to make programming easier, to improve learning, and to prevent mistakes as far as possible, but suggesting that the primary mechanism of learning (by measuring it in apparent isolation) is mimicking syntax while ignoring the practical matter that solving a problem is the important part, while writing the program is a matter of implementation, misses the point.
A better study would have measured whether participants could describe their solution to the problem in a correct way regardless of syntax, or at least controlled away that variable.
I suspect the focus on syntax comes from the stranglehold of mathematics and computer science on programming. (In some ways, we haven't left the notation wars of Newton and Leibniz.) The irony to me is that mathematics is a world of creative problem solving.
While you can measure true differences between programming languages (at least along their theoretical axes), learning how to program at all is a skill that seems to be independent of notation. Teaching that is hard.
(I learned how to program on home computers in the early '80s, and I switched back and forth between several variants of BASIC and Logo a few times. Expressing my intention was more difficult than the particular abomination of BASIC I used. I suspect my experience is not so rare.)
This is why I like SICP as a programming learning book. It starts off on just the right tone, explaining the process of taking a problem and breaking it into smaller steps, with only a tiny detail about the syntax of Scheme used to express the program. A good 90% or so of the text is about the abstract ideas, not the concrete implementation of them.
I've sometimes wondered why nobody's bothered to rewrite SICP with other languages - almost any language would do and keep the structure of the text roughly the same.
I think that the hardest part of teaching non-programers is the forced reliance on linear thinking. The computer does not have a 'make it so' button that will read your thoughts, you have to think long and hard about all the steps from here to there, and then ask the computer to do them for you in a specific order. Once that is grasped, it's just a vocab issue.
MJD did this for Perl with Higher-Order Perl.