I am a programmer around long enough to literally hear bulldozers and
chain-link fences clinking around big holes in the ground at the sight of the
word "developer". (Insert more hallucinogenic curmudgeonly grumbling here.)
More on topic, I have no qualms admitting that "fast and easy" programming
"solutions" might indeed be so, but still can't help but wonder what else is
missing. What are the consequences of "fast and easy" programming?
Those words bring to mind news articles of car and train wrecks, where
speed is always an aggravating factor, and attaining that speed never seems
too difficult or too ambitious at the onset, prior to the accident.
A wreck is definitely not desirable if one aspires to Quality (in the ZAMM
--Pirsig sense), for a wreck completely removes the moment of perception from
the scene, by removing the perceiver (or more precisely, the motivating force
(perhaps in the gravest cases, the life) of the perceiver).
I think, rather than pushing "fast and easy", a better pair of adjectives
would be "strong and flexible" (like a rope, or a towel, say). The programming
languages, environments and mindsets based on these fundamental metaphors admit
guidance from a mentor (on the "other end" of the experience divide, pulling)
quite readily.
The consequences may in the end result in "fast and easy" development of
the program, of the programmer, of the mindset, anyway. It depends not only
on the budding programmer, but also on the relationship between the teacher
and the student (both of whom may be the same programmer, why not?).