
Illustrative Programming - mbrubeck
http://martinfowler.com/bliki/IllustrativeProgramming.html
======
gruseom
The term "illustrative programming" seems a bit pretentious, plus misleadingly
suggestive of visual programming.

I agree that the spreadsheet is (1) a programming environment, and therefore
(2) the most widely used programming environment. Has there been any other
tool that put comparable programming power into the hands of non-programmers?

One thing that distinguishes the spreadsheet, which Fowler sort of butts up
against without mentioning, is that the user is never asked to formulate
abstractions. Spreadsheet formulas always go hand-in-hand with concrete data,
so the user can build a spreadsheet without ever having to think beyond their
particular example. I think this is one of the keys to the spreadsheet's
popularity. To put it another way, I think this is one of the things that
makes most programming inaccessible to most people: they have a low tolerance
for abstraction. If you asked a spreadsheet user to type in all the formulas
before instantiating them with data (and there have been attempts to "improve"
on spreadsheets which do just that), most users would recoil.

------
mixmax
Wouldn't the way to go be to have an illustrative IDE instead of an
illustrative programming language? That way you would have the full power of
the language, yet newbies would be able to get something done in it.

For instance the flow of the program could consist of a number of boxes
stacked on top of each other, illustrating the flow. Each box would have one
or more lines showing the input and output, and when clicked it would open up
showing either the boxes it contains (funtions, nethods, code snippets etc.)
or the raw code if you're at the lowest level. You can click the boxes-within-
boxes until you reach the raw code at the bottom.

The user would be able to drag boxes into his program, from simple ones that
just print something to the screen (Two lines: input text and output text) to
complex methods and functions.

The whole thing could probly be coded up in emacs.

Note that this is just a wild idea, and there are probably tons of things I
haven't thought of. It's pretty interesting though.

~~~
gruseom
Boxes-and-lines programming has been tried many times. It's enticing because
if you look at simple examples it seems like it ought to work. The problem is
that when applied to programs of any complexity the visual format quickly
becomes unwieldy. There's a reason why humans represent complex information
textually.

~~~
mixmax
You're probably right.

