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.""
Using ISO9000 (define what to do, do it and document it), proper object orientation software is (should) built like bridges.
Any major software company not reusing components and controlling the design/implementation process will fail. The reuse of components not only benefits the developers, but also the users (just look at KDE or Adobe's software, dialogs and tools are easily reused).
The reuse of software requires direction, thought and documentation. You must know what it is that you try to do, break it down into sections (objects) and define the interfaces and interactions before you sit down and write any code. This is the most common mistake when coding and the biggest problem in open source projects that begin as small personal pets of the project initiator and quickly grows out of hand.
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.
I hear this theory every now and then, and it's just dead wrong. The fundamental problem is that a program is thousands of times more complex than a bridge. Imagine constructing a bridge out of hundreds of thousands, if not millions, of custom-fabricated tiny parts that have to fit together exactly right or the whole thing collapses. That's the correct analogy.
When you also combine that with the fact that you can look at the totality of a bridge and get a "sense" of whether it's done right or not, at best you can only look at a few hundred lines of code at a time.
Sometimes it's best to just let stupid people be stupid.
Bridges don't defy physics in anyway. Just because you are ignorant of the physics behind them doesn't mean it doesn't exist.
Sure, there's a creative aspect. But there's a creative aspect to the bridge-building example he describes. And while maybe on any given program you're working on only the 7th or 8th generation at most, almost any programming task that people deal with has been worked umpteen times - maybe not by them, but by someone. Let's face it, most programming is mundane, whether you work for Bank of America or Playboy, and involves working mostly the same old strategies and structures for slightly different ends. How creative can you get with bubble-sort or linked-lists, or which you've probably used tons of times before ?
The designers of the program - i.e., usually the project managers (*ducks*) or system architects do most of the creative work of conceptualizings how things will work and how they will meet the constraints of the particular problem. The programmers, most of the time, are brick-layers, carpenters and plumbers. Not that there is anything less noble about this latter work, but it's hard to call it creative.
Most of the creativity in software comes from newly emerging fields like, say, robotics, AI, or computational biology, but usually this creativity comes from the algorithms which get hashed out and proven by theoreticians, not rank-and-file programmers.
The closest thing to a proof that programming is mostly not art, that I can come up with, is this: bad programming is mostly identifiable by almost every programmer. But there is nothing close to a consensus as to what defines bad art, or bad poetry, or bad architecture. The latter judgements are far more subjective.
The mathematics behind many clever algorithms is simply astounding to me. The beauty of recursion is something as natural and poetic as music to me.
But that's to me.
Also, for me, most abstract art and whatever they call those paintings that are just a big red circle, is garbage. I think it's a waste of paint and is only meaningful to the creator. But millions of people believe this type of painting is artistic, even poetic.
Until you get to professional levels, anyone can tell a lousy poem or an ugly painting. In professional levels, it becomes more subjective. Many people are employed as painters although they aren't good at making good art. $5 paintings sold at Sears have to be painted by someone. Similarly, there are a whole lot of mediocre programmers out there, employed as programmers in a low level job. Most programmers or even logical thinkers who aren't programmers can identify bad programming, just as most people who are even casually interested in art can tell when an unskilled and untrained hand has done the painting.
But when a programmer sees a great algorithm for the first time, whether in a textbook or on a napkin, there's a certain beauty to it, a certain mathematical/locical poetry to it. The artistic pleasure comes from realizing what the artist was thinking when the made the art, whether it's an ingeniously simple technique for a peer to peer system, or a woman both in the distance and in the foreground at the same time in a Salvador Dali painting.
$8.95/mo web hosting
The fact that software is so easy to change is exactly why we shouldn't treat software development like bridge engineering. While the software fail rate may be high and the software development industry may be in need of better practices, you simply can't apply bridge engineering to software development or you will lose a significant amount of cost savings.
It would have been hard to get to where we are now doing things this way. But now that we have the CPU power, it's time to start going in that direction.
Cars went through the same evolution. By the 1960s, almost everybody in the US had a car, but the cars worked well for a year or two at best. It took Ralph Nader, Congress, and Japanese competition to bring cars to the point where they worked reliably. This happened over the objections of the auto industry; not until the 1980s did the auto industry finally accept that they'd been forced to do the right thing. Read Lee Iacocca's books.
Bridges have functional purposes, and some bridges are boring bridges that get you from point A to point B (or side A to side B, as the case may be). But many bridges also have an aesthetic (artistic) aspect, and I think that's what's being referred to.
Personally, I think it's the same with code. Given the same specs, anyone can write functional programs that do the same thing, but when you get down and look at the source, some will have a sense of beauty that go beyond pure functionality. Or it's like that warm fuzzy feeling you get when you see a really cool algorithm, solution, or design.
Or am I the only person who gets warm fuzzy feelings from code?
---
Open Source Shirts