TITLE: Programming, Pictures, and Code
AUTHOR: Eugene Wallingford
DATE: September 29, 2008  4:22 PM
DESC: 
-----
BODY:
When I first came to UNI, a colleague and I talked a lot
about programming by novices, graphical programming,
programming by example, declarative programming, and the
like.  Many people saw ideas such as these as a way to
broaden participation by making it possible for people
to program without "programming".  Anyone can draw a
flowchart, right?  Or program by dragging and dropping
widgets, right?

No, said my colleague.  He was fond of saying that all
of those solutions were really just new kinds of programming
language in disguise; ultimately, you had to know how
to write a program.  That may not be an insanely difficult
task, but it is not a trivial task, either -- even if
pictures were the <EM>lingua franca</EM>.

Yet the world goes on, looking for its next way to bypass
the hard work of programming and make it disappear with
pretty pictures.  So I'm glad when people say out loud
in public what my colleague has always said in-house.
Here is
<A HREF="http://blog.objectmentor.com/articles/2008/08/28/there-will-be-code">
   Uncle Bob Martin</A>
sounding in on the latest,
<A HREF="http://en.wikipedia.org/wiki/Model-driven_architecture"> 
   model-driven architecture</A>:

<BLOCKQUOTE><EM>
Some folks have put a great deal of hope in technologies
like MDA.  I don't. The reason is that I don't see MDA as
anything more than a different kind of computer language.
To be effective it will still need 'if' and 'for' statements
of some kind.  And 'programmers' will still need to write
programs in that language, because details will still need
to be managed.  There is no language that can eliminate
the programming step, because the programming step is the
translation from requirements to systems irrespective of
language.  MDA does not change this.
</EM></BLOCKQUOTE>

Programming is the translation from requirements to systems,
whether we write it down in C, Java, or Ruby -- or an MDA
model.  There will be always be a program, and so there will
be always be programmers.  Making better programming tools
helps, but as Bob says we also need thinkers, practitioners
and academics alike, to figure out better what it means "to
program" and to help others learn how to do it.
-----