The Poetry Of Programming 416
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.""
Get real (Score:2, Insightful)
The problems people face have barely changed in thousands of years. The problems that business (which uses 95% of the software out there) faces haven't changed in 200 years. The requirements are well-known. The solutions exist. The reason the software sucks isn't that you have a PHB, it's that you lack discipline to find and fix all your bugs.
I'm curious about wheel reinvention (Score:4, Insightful)
ISO9000 (Score:5, Insightful)
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.
Wrong (Score:5, Insightful)
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.
Re:Bridges do one thing only (Score:5, Insightful)
Software isn't as much like poetry as he suggests (Score:5, Insightful)
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.
That's what I love about programming (Score:4, Insightful)
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.
Re:Get real (Score:2, Insightful)
We need more geeks that are less geeky (Score:4, Insightful)
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.
Re:Wrong (Score:5, Insightful)
sPh
Re:Get real (Score:2, Insightful)
I agree (Score:3, Insightful)
Although I agreed with his basic premise, the paper is kinda dumb in parts. For instance he answers
> Wasn't object-oriented software supposed to take the labor out of programming?
As though it was a reasonable question. He should have stuck with his analogies... OO is one way of structuring a program, it doesnt provide a magic cure to anything. One may as well ask "why it is that a good Haiku is difficult to write, after all the structure of the poem is already defined, all one needs to do is fill in the words, doesn't this take the labour out of poetry".
A more interesting paper on programming is http://www.reciprocality.org/Reciprocality/r0/ind
Re:Wrong (Score:3, Insightful)
Sounds like the Golden Gate [pbs.org] to me. Or the Tacoma Narrows [pbs.org], which is as good an analogy to Microsoft server software as I can possibly imagine.
Re:Get real (Score:3, Insightful)
As a matter of fact, communication and information sharing and dispersal isn't anything new to business. Advertising and marketing are also nothing new to business. If the businesses hadn't spent so much time trying to make the internet "different" and instead applied the same rules and philosophies that have been known for hundreds of years to the internet, perhaps the dot com crash wouldn't have hurt as much? (I think it still would've happened, though)
Just because something appears new from the outside doesn't mean it is new. How long has the word "network" been in the english language, anyway? Anybody know?
I'm creative and you're not (Score:5, Insightful)
Half the problem with software engineers is that we are so damn "creative" on certain parts of the development cycle ("oooh, look at my pretty flow chart" or "oooh, look at my pretty implementation of a double linked list even though there's one in the STL" or "oooh, look, I can use function pointers"), but very underwhelmed by other parts of the development cycle. We're so "creative" we have to build everything ourselves.
We'd all like to think we're code poets. We want our jobs to be creative and exciting and spiritually fulfilling. We want to have jobs that stir our souls.
But we don't.
We work for *the man*. We brew his coffee and pick up his dry cleaning. We right code to integrate blah blah blah legacy garbage with the latest blah blah costs too much but has good buzz words blah blah. We right buggy code at work, and a bajillion IRC clients and POP email readers at home. Fifty years into the computing "revolution" and we are no closer to a true "science" of computing than when we started because the "state of the art" is still mostly hunt-peck-compile-crash-debug.
Call me a cynic, but as much as you'd like to think you're a unique, artistic nerd, we're all really just cogs in the wheel.
arts vs. programming (Score:4, Insightful)
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
Re:Wrong (Score:3, Insightful)
can great coders be "taught"? (Score:3, Insightful)
But can great coders be taught? I don't think so. A debate has been raging within the creative community for years about the value of MFAs. Many people see them as a cynical way for universities to bring in extra money by bilking minimally talented people who want to "learn" how to write.
Just like great writers, great coders seem to have an extra intuitive "something" that the rest of us don't. In my experience, the best software engineer I've worked with doesn't even have a college degree. He started coding and studying math & logic on his own at age twelve and simply evolved from there. He was a kind of computer science savant. His talent was very impressive but very mysterious, just like Faulkner's, or Eliot's, or Bishop's.
Re:ISO9000 (Score:4, Insightful)
The nature of programming hasen't changed because the way we attack the problem is no different than 40 years ago because it mimics how humans attack problems. Break it down into managable chunks and try to make the chunks work together nicely. Whether it be structured or OO, the pen and paper change but the mind behind the pen and the words produced have stayed the same (i.e. not improved).
Re:Get real (Score:2, Insightful)
Almost 500 years, according to Merriam Webster [m-w.com]. The first entry sets the date at 1560 AD.
Re:Get real (Score:2, Insightful)
I'm sorry, but there are other factors besides lack of discipline. One, in particular, is called: 'Get the fscking program out by this date or you're fired and we lose our market share'. That's one in which you have no particular control over. Its not a PHB, its the market itself.
Software... Engineering? (Score:4, Insightful)
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.
Re:can great coders be "taught"? (Score:4, Insightful)
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.
Re:Software isn't as much like poetry as he sugges (Score:5, Insightful)
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.
I would probably call you something else... (Score:3, Insightful)
Yeah, but the problem has not changed much. They are refining the solution. Software is different because if the problem has already been solved, there is little point solving it again. Sometimes people come up with better algorithms for the same problem, but often they need to solve better problems.
I have to ask, how long have you been writing software ? what great software have you produced ? Have you got proven success using this method or are you just talking out of your ass ?
> This means that one has to complete the design before one starts coding/building
This doesnt work. It was tried for many years, until people realised that its better to test assumptions along the way before committing to everything, hence waterfall model.
Part of the reason it does not work is that software *is* a design. It makes perfect sense for bridges or buildings to be designed completely first. One can have an unambiguous design which is in a different medium to the finished product, eg as a CAD model. Then you can model how it behaves more cheaply than seeing whether the bridge falls down. Try finding an analogy to that for software, er lets model the software on a computer...
The only totally unambiguous design for a piece of software is the software itself. If a design was unambiguous, one could define that as the programming language.
Re:Software... Engineering? (Score:5, Insightful)
Re:Wrong (Score:5, Insightful)
When they make a new airliner, they model the entire thing on a computer first. The CAD model is an unambiguous model of the plane. Important subsystems in it are modelled and analysed independently and in conjunction with the components around it.
So, if writing software was similar, we would first model the software on a computer. Oh, er, wait a moment. In an important sense, software is a design. The only unambiguous design is the actual software [otherwise we could make the design the programming language]. So, one could have a notion of starting with a fuzzy design and gradually making it clearer, but you can still end up with a bad design.
When someone designs a bad aircraft, the design is modelled, flaws are found and the design is improved. Nobody builds the thing until they feel pretty sure the design is right. However, software is often bad for the same reason that an initial design of anything else is bad. If it was equivalent to an airplane, windows 95 for instance, once designed, would never have been built. However, once the design for a piece of software is complete, one has created the software. All the development money has been spent, so the makers will try to get what they can for it. It's *all* design.
Learning to Peer Review (Critique) (Score:4, Insightful)
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.
Re:Wrong (Score:3, Insightful)
Write a couple of zero bytes at an arbitrary point in your favorite executable and run it. Chances are that it will fail catastrophically.
That's what the OP meant by tiny pieces that ALL have to work in order for the whole to work. A small subroutine for a little-used feature that isn't even critical to the function of the application can usually take down the software more easily than the equivalent in any physical object.
The reason is that the raw material of software is instructions to a machine. They are more abstract and therefore has less inherent resistance to damage than concrete or aluminum.
Re:bridges =?= software (Score:3, Insightful)
I think I've heard that a company that made titanium wrenches went broke because all of their customers bought one wrench and never needed to buy another one. Seriously, though, this just about summarizes the Achilles heel of the software industry. It is impossible to build a car that never breaks down because when moving parts rub against each other, they wear each other down, and eventually they will wear each other down so much that one or the other or both will fail. On the other hand, it is theoretically possible to write code that will never fail. (For example, there is no reason for properly written "Hello, World!" code to fail, ever) It is just that as the complexity of functionality grows, the complexity of the code to enforce proper functionality grows even faster, and people are lazy and prefer to focus on functionality rather than correctness.
Re:Lack of constraints (Score:2, Insightful)
I agree with your little theory
We are well on the way to building software by components -- for the most part we use COTS databases, operating systems, compilers, and some lower level components such as XML parsers and libraries. But to go farther we need interchangeable "software parts" (think 74xx TTL) that are fully spec'd and glue together easily (I think this latter part is going to require increased use of frameworks).
I should start reading up some more on frameworks that are out there. Perhaps look into creating some for the embedded systems I work on.
We know how to do software right (Score:5, Insightful)
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.
Re: reuse and OO (Score:3, Insightful)
What I see is that most "generic" tools become so generic, as to be completely useless. I think one of the reasons Extreme Programming is catching on, is that it does away with this concept and advocates building the simplest thing that will work.
Imagine trying to create a "generic bridge building toolkit". Certainly there are standard components from which bridges are built (i.e. bolts etc), but the idea of a generic bridge toolkit is silly.
aesthetic beauty (Score:5, Insightful)
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?
Writing Software Is Not Like Building Anything (Score:3, Insightful)
> software the way we build bridges?'
Writing software is like drawing up the plans for a bridge. The bridge gets built every time the program gets run.
Re:The "only"? (Score:3, Insightful)
I agree...not that I've met very many people like that, but I'm like that in a way myself. I don't have a degree, but I've taken as many English/Lit classes as computer science classes, and have seriously considered switching to an English major (from CompSci). And I speak 4 languages (well, two fluently, one at a conversational level, and I'm learning a 4th).
Quite frankly, I'd love to be in a program like the one described in the article. The way computer sciences is taught right now seems so cold, detached, relentlesss, uninspiring and often irrelevant. Maybe this works for people who simply want to get a degree, get a job, and earn big bucks. But for someone who's in it for the love of programming (and has no ambitions of making money off of it), it's dull as all hell. That's why I like to take literature courses...at least those are interesting, thought provoking and inspiring.
Re:Software... Engineering? (Score:1, Insightful)
Actually, this isn't true. In bridge building, the components - bolts, rivits, I-bars, rebar, concrete, etc - are the same for every bridge; it's usually just the way they're connected that changes. This is one of the reasons bridge building is so reproducible: they don't have to figure out how to build nails or how to most effectively join two pieces of steel every time they want to make a new bridge, they can concentrate on how to best connect preexisting components with known characteristics. Software is just starting to get to this point, with the concept of components and loosely coupled systems.
Ask yourself: how many list implementations have you written? I've lost count of the number I have. I bet most civil engineers have never had to make a bolt.