Programming Unglued

Some who started their careers in the days of punch cards, think of programs and data as one stack of cards, data after program, all queuing as jobs for the CPU, printed output to follow. That was their paradigm, for then and for now.

Then came the command line or shell, interactive dialog. Workbench and toolbox metaphors predominated. UNIX a smash, ran for cash, until GNU gave us all free bash.

These alternative conceptions of "programming" (queuing lengthy "self sufficient" programs vs. enriching a namespace with tools) come to bear as we move on from just calculators, and really start using technology in the classroom, for real this time, not just Zoombinis (cool games).

In math world, we're used to little snippets, dense thickets, all floating in a haze of discursive prose. Functions abutt sigma notation. Diagrams obtrude (graphics). The vista is fragmented.

MathCad and Mathematica have done wonders to acclimate pro math users to the interactive and/or spreadsheet environment. On the other hand, both of these successful commercial products are themselves "big code" in the sense of reams of source all glued together by a mouse-and-keyboard event driven framework.

The user is "in" a game-like environment, just like "in" a Python shell (i.e. something is running, an interpreter we call it).

Python's modular format brings both worlds together: big iron executables; a more loose fitting, seat of your pants, command line experience. Programming is like typing, like novelists and journalists experience. Except your machine talks back to you, and you're allowed to actually tell people that it does.

Functions are like fish in the tank, with mouth-like parenthetical syntax, just waiting for arguments. Python's own math module is a great example: the trig functions just sit there, waiting to be fed. And you feed them through parentheses, even if there's a GUI at some desktop level.

( click for larger view )

Big code runs in the background, but you also want that responsive interface in the foreground, a sense of driving, even if the steering wheel isn't connected to anything, that Fisher-Price like experience, kinda Stephen King like in some contexts (disconcerting).

In Python, that need for "glue" to bring it all together is typically expressed in the form of a testing regimen at the end of the module. If this code is actually being run as a main process (if __name__ == '__main__'), versus imported for random accessing from outside, then fire up a whole lot of tests, giving every feature of this module a miniature workout. Show what it'll do.

In sum, the in vogue eXtreme Programming "test as you go" techniques -- already satisfying to mathematicians because like proving up from axioms -- fit well with the more interactive, unglued aesthetic, wherein you don't necessarily want an obtrusive framework, making you pick from menus for everything, pestering you with questions, prompts or whatever.

Sometimes entering "just do it" is the most direct way.