Actually I think this is a pretty interesting question, although I
think “novice programmers” and “mediocre programmers” is pretty
counter-productive terminology, especially when sometimes it’s you
yourself using your own code. I like the term “client programmer”
better.
I think really what you’re saying here is that metaprogramming should
be reserved for code internal to APIs. I’d like to flip that around
slightly, and say it’s a pretty good idea to wrap metaprogramming
in APIs.
Saying that code which contains metaprogramming is “polluted” with it,
I think that’s a bit too strident, but certainly, if you’ve got a
metaprogramming technique which might go over somebody else’s head, or
even your own a few days later, wrapping it up in something more
intuitive can be a good thing.
However – all that being said, I’m working on a project where the
other programmer is a business guy, and I’m giving him tons of
metaprogramming in Rails controllers which he then uses in Rails
views. I wouldn’t call him a mediocre programmer, but he’s certainly
much more about the business side than the programming side. He can
write code but I doubt he’d ever call himself a programmer. Probably
the type of guy you’re thinking about. The thing is, all that
metaprogramming doesn’t seem to be any kind of problem for him,
probably because I set it up in such a way that although there is some
arcane cleverness in there, the results are totally consistent and
therefore easy to use.
So the converse to all this is that if you use the ideas behind
good API design to code whatever you’re doing in a way that minimizes
stress for client programmers, that’s probably more important than the
literal separation. If the metaprogramming occurs in a sort of
non-disruptive way, a literal separation isn’t always necessary. I
think as a rule of thumb for design it’s a good idea, but at the same
time, I don’t think it’s such a big deal.
–
Giles B.
http://www.gilesgoatboy.org