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.
Process swiftly crash NULL pointers everywhere O -- Electric Fence!
Roving Web-Teleoperated Robot
Whenever I create software, it takes a lot out of me. Much like Picasso's painting, Michaelangelo's Sistene Chapel, ee cummings literary works (only I use more punctuation marks than she does), I am an artist. My work is meaningful and beautiful, and a part of me, which is why I release it under the GPL. For the GPL, itself, is also a work of art. It brings light to the darkness, it brings joy to the huddled masses of ones and seros yearning to be free.
Are we really creating something new each time, or creating things in parallel? I'm not an advanced programmer by any means but I've taken a few classes and noticed that the typical approach is to have students recreate solutions to common problems for the purposes of learning (e.g. The Towers of Hanoi to learn recursion), are we enculturating ourselves to go it alone rather than look at what others have done before us?
Try building a bridge:
a) with half the crew and materials required
b) in a quarter of the required time
c) that will be retrofitted to support train tracks and a second level
d) that will be backwards compatible with the previous bridge
e) that is better than your competitors bridge
Jason.
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.
I bet this guy owns that "Code Poet" shirt from Think Geek.
This message brought to you by the Council of People Who Are Sick of Seeing More People.
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.
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.
sPh
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.
Almost anybody can do something new. Not necessarily something awesome and groundbreaking like the O(1) scheduler, but pretty much anybody with some skill can make their little contribution in the form of a Perl module for example.
I also like that in programming it's fairly easy to reinvent things. For example I'm pretty sure a few people reinvented bubble sort or linked lists while playing with a programming language without having read anything but the manual for that language. Gives you a nice feeling to find that you were able to come up with useful things on your own.
Obvious reasons. Those foolish cavemen (or whoever) that built the first bridges didn't patent the design and copyright the plans. Then hide the bridge in big black boxes so nobody could try design something similar.
They also didn't have to worry about the greedy land owners at either side of the river charging them huge amounts (or just refusing them) to get information on ground they needed to build the bridge ends on.
$DEITY bless the software industry!
You Are Being Lied To.
Microsoft
You can have it fast, accurate, or pretty. Pick any 2.
possibly the only person with both a Ph.D. in computer science and an MFA in poetry)
That's wonderful! For some time now I've been thinking that perhaps a computer science degree is exactly what geeks don't need. Heck, they're already wrapped up in the tech world, and they'll spend the rest of their lives coding, so while not get well rounded early on. Get a degree in history or literature or creative writing, then get the computer science degree later.
The uber-geeks are often the most stubborn, the most prone to get into Slashdot arguments, the ones who have the narrowest views. The more interesting techies with wider views often tend to get out of technical fields later on, because mindless code monkeys who think C++ is The Way and develop software by working 12-14 hour days, well, they're just so mind numbing after a while.
In school I studied both computer science and fine arts, and I consider the two extremely different. The biggest, most obvious difference is that in programming, you have a very good sense of when you're done. If your specs (either from your client, or your programming assignment) are relatively clear, you can write your code and be more-or-less satisfied that you've met them. You can write automated regression tests if you want to really make sure. (These days I almost always write automated tests.)
...
... If everybody did programming the way artists do art, programming would be even more buggy and expensive, which doesn't do anything good for respect for the craft. The way to get more respect for programming is to figure out ways to make us all better programmers. Anything else is just a distraction.
But for art? Forget about it. I can't tell you how many hours I spent agonizing in front of a painting or sculpture or comic book page, wondering if it was finished, if it had enough marks or not
The two are very different. Not that one is necessarily better than the other, but they're very different.
I think comments like Gabriel's often stem for a desire to get more respect for programming. Gabriel probably compared the respect that artists get, vs. the respect that programmers get, and decided that the way to get more respect for programming is to try to convince everybody that's a sort of art.
His intentions are good, but you end up muddying the waters too much that way
Do domain names matter?
This is not real engineering.
This sad situation has come about because it's too easy to do develop this mentality in the software world, where making quick changes is as simple as hitting backspace a few times and typing some new code. ("I don't have to plan! I can get it sorta right, then fix it later! It's easy!")
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.
(Not that there's no room for kludges and "screwing around". I always have a "Let's mess around and do neat stuff" period at the beginning of projects. But once this is done, and we've come up with some fun and clever stuff, we roll up our sleeves and do real engineering to build a real product. And, Hey Presto!, we end up with solid and usable applications.
Well, you can teach the mechanics. You can teach poets and writers how the language works, why it works, what can be done that's gotten a certain effect. Similarly, you can teach people the mechanics of programming.
What you can't teach is that extra something. In writers it's the uncanny ability to take some small bit from the real world and build a story from it. In poets it's coming up with that single image that the poem turns on. In programming, it's figuring out what the program should look like to do it's job.
I suspect programming is close to something like bridge engineering. At an engineering firm there's probably dozens or even hundreds of engineers who can take the plans and specs and turn them into the detailed working drawings the construction people will need to actually build the bridge, but there's only a small handful of engineers who can take a blank piece of paper and a site and come up with the initial idea for a bridge that'll actually work and turn that into the specs and overall plans that everybody else works from.
The thing is, programming isn't like building a skyscraper. It's like designing and building a skyscraper. People who ignore one part or the other will always have problems with the result.
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
My initial reaction to this article was a bit different than those I've seen in the comments.
Way back when... there were only ~25 lines on the screen and we got 1 compile a day (none at the end of the month), we printed all our source on z-fold greenbar paper and desk checked it. When we had something that was beginning to work, we'd hang the code on the wall and step back. If the pattern of the black ink flowed well; the indents and breaks were orderly, the code always seemed to work well. Where we saw disorder, there was the problem. We coded in COBOL, PL/1, basic, db3/Clipper, and 360bal. This worked for all of them.
With the advent of X, we can now see 100 or more lines and modularity is much more popular. I haven't seen source printed with any regularity in years. Ah, practises change with the times and hardware.
Coincident but unrelated to the timing of this article, I found an old Panasonic dot matrix printer yesterday. I've been telling the youngsters here about this method so we're gonna hook this antique up and see if that practise can still work.
I received a bachelors in computer science in 1993 and have heard of these so-called "Peer Reviews" or "Code Reviews." However, not once was I taught that in school. It would have been extremely beneficial if computer science graduates had the skills of the peer review in the same way that recent fine arts graduates (theoretically) have the skills of the critique process.
The two very different disciplines share some important characteristics. Students are taught techniques and are given the opportunity to hone their expressive skills. In fine arts, the emphasis is on the expressive skills--it's better to create a work of art that is very expressive even if the techniques are poor. Computer science, on the other hand, emphasizes technique over expression--it's better to make a program that works poorly rather than an elegant algorithm that doesn't compile.
Unfortunately the computer science student is treated like an engineer and their creative skills are not taught, but left to the student to develop on their own, and, in part through attrition, functionally creative programmers leave college. Admittedly, a fine arts student isn't taught the way to express their creative ideas, but rather, given the opportunity to hone their implicit skills for expressing those ideas. Even better, through learning the process of the critique, they are given the skills necessary to continue to learn to improve on their own.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
Truly epic software is written in iambic pentameter. Portable utilities are written in sonnet form. Quick-n-dirty kludges are written as limericks. Haiku is for batch files.
~REZ~ #43301. Who'd fake being me anyway?
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.
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.
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
"Haiku is for batch files."
.
;)
Hehehe...
for each file in
do sed s slash leaf slash tree
on every line found; done
Okay, so that's a shell script... but it was just as fun to write.
Simpli - Your source for San Jose dedicated servers and colocation!