Slashdot Mirror
The Poetry Of Programming
Lumpish Scholar writes "Sun's Richard Gabriel (possibly the only person with both a Ph.D. in computer science and an MFA in poetry) talks about "the connections between creativity, software, and poetry": "People say, 'Well, how come we can't build software the way we build bridges?' The answer is that we've been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that's been built.... But in software ... we're rolling out -- if not the first -- at most the seventh or eighth version. We've only been building software for 50 years, and almost every time we're creating something new.""
Defy physics between two points. Software changes because what we do with it can change.
People say, 'Well, how come we can't build software the way we build bridges?'
Because they're not analogous. Bridges are designed to be used for decades, if not centuries, by hundreds and thousands of people and vehicles without anything more than routine maintenance. The closest equivalent in the technology industry would be the mainframe computer.
"Ordinary" software, the kind meant to be used by consumers on their current PC which will be constantly upgraded, routinely unsecured and replaced within five years at best, is more like a gravel-top driveway with grass growing underneath.
This is not real engineering.
I have done "real" engineering. I write (well, wrote) firmware, working very closely with EEs, and such tasks required quite a lot of careful planning. I "know" what "real" engineers do, and have done such in my own coding (though *only* as a requirement of ISO9000, which I consider useful primarily as six linear feet of kindling in case a major snowstorm traps me at work with no heat).
That said...
"Real" enineering, as applied to writing code, wastes time. A bunch of BS with no purpose other than to make management think they have a better grasp of how long it will take to finish a particular project. Every coding "paradigm" I've ever seen has the same purpose.
Note that nowhere above there did I say that such methods actually *do* lend any stability or outcome predictability to a coding project. They provide a perception, nothing more, and a false one at that.
I have written a LOT of code in my life. And I can say, quite honestly, that the "best" code I've written has felt more like writing poetry than any task of "engineering". Coding involves a creative, not analytic, effort. Anyone who claims otherwise may "get the job done" but will *NEVER* produce anything truly elegant.
Now, don't get me wrong, programming involves a lot of math, and a lot of careful forethought. But to code well, people need to have the math they use so totally ingrained that it flows without thought. From the idea to the implementation, without any (explicit) intermediate steps (except perhaps a nice detailed spec, which you either already have as the goal to code to, or have to create, in which case it flows as a natural consequence of the task at hand). If a programmer can't do that, they will take too long to produce too little, and the result will feel very underwhelming.
To make an analogy to actual literature, any two-bit hack can carefully follow the rules of grammar to string a series of words together and re-tell one of the classic plots. *Not* every writer can create the third age of Middle Earth and have the readers *believe* it.
When one is building a circuit, or a bridge, one can't simply make quick changes. Any changes are ltime consuming, expensive, and painful. Thus, REAL engineers actually plan stuff.
Complete and utter BS. When building a bridge, you use (as someone else pointed out) the 4000 years of "prototypes" available to decide what will work best. When building a circuit, you test it in any of a number of nice circuit analysis programs before building it, *then* build a few generations of proto boards, and only then commit to a release design. In the 10 years I worked closely with EEs, not once did I see any non-trivial board come out right on the first spin. They go through the same trial and error as programmers. "Oops, this line has too much noise on it, need a slightly lower-valued resistor" differs very little from "Oops, I forgot to check that call for failure since it should never fail anyway".
Yes, "real" engineering involves careful forethought. As does "real" programming. but the implementation (in *BOTH* realms) very much counts as an art. I get so sick of people trying to say we need to follow such-and-such a proceedure to produce "good" results. I used to know one guy who did a lot of analog circuit design. He'd do very little while actually at work, then go home, get REALLY high, and produce some of the best designs you've ever seen. Tell me "real" engineering makes any mention of *that* as a design strategy.
Coding, at its lowest level, involves nothing more than theorem proving. When you can propose a (terminating!) concrete algorithmic method for even something as "simple" as proving (or disproving) Fermat's last, then this discussion has some merit. Until then, we may as well argue about C++ vs Java, or tea vs coffee, or Shakespeare vs Spencer.