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.
I'm only getting a few things coming to mind if software were made similarly to the way bridges are made as this artical suggests.
Copyright infringment, DMCA, patent suits, ect...
__________________________________
Free your mind - Flush your toilet
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.
Also, this bit:
"every bridge is like some other bridge that's been built"
Is utterly, utterly wrong - unless you know nothing about bridges and go `yeah, i guess it sorta looks like that one`. In the same way that chinese and japanese looks the same when you don't know anything about either.
Sounds like you don't do much programming. Nor construction work, either.
I agree with you that the higher level conceptualizing is important and very creative. But there is tons of creativity involved in solving lower-level, everyday-occurance types of problems, be they in software development or construction.
Don't underestimate the importance in this. Creative, clever solutions to those seemingly unimportant (and often hidden) lower-level problems can go a long way towards getting the higher-level system concepts to work as designed. This is true for larger software systems and for building construction.
In the course of every project, it will become necessary to shoot the scientists and begin production.
And we've only been building transistors for 50 years and chips for 30? years, but most chips seem to turn out alright. And this with radical process changes every few years.
I don't think that software is any more difficult to design than anything else - it's just that we don't try to design it! Software is written, not designed/engineered. Stuff is so easy to change later that we neglect the design phase and skip directly to implementation. Things like bridges and chips and most other engineering projects have to be right first time because they are almost impossible to modify later. Imagine what a bridge would look like if it were built like software!
The only way to get round this is to apply sound engineering design principles to software. This means that one has to complete the design before one starts coding/building in the same way as other engineering projects.
If we designed software the way we design bridges we would have much better software (or worse bridges
Soapbox mode off...
This lack of constraints peculiar to software development implies a couple of things:
If you buy into my little pet theory, most of the problems associated with software development will likely remain with us for some time to come.
Roving Web-Teleoperated Robot
with respect, your post is complete bullshit. Bridge building is an art, and they are a hell of a lot more complex than your simple analogy implies.
You know what, most engineers (I'm talking civil/mech/etc, not programmers) would love to be able to design and build with hundreds and thousands of custom-fabricated parts that do the exact job they are designed for. But you know what else? There is that small factor called manufacturing cost that prohibits this - they have to use standard stock and account for this in their design, and still get the thing to work.
Your analogy is not a good one - you're comparing a program that could potentially have hundreds of applications with a bridge. Bridges are only one very small thing that civil engineers are involved with, so you should be comparing to a program that does a specific thing (for example, instant messaging), not to every program in existence.
"Because it's there." - George Mallory, when asked why he wanted to climb Mt Everest, March 18, 1923 (New York Times)
I agree with the guy. Maybe because I'm not a professional software engineer. I write code to do things I need done instead of doing them myself (I Am Lazy.)
In my first engineering job, before I had the creativity squeezed out of me by the brutal gears of corporate America, there was a whole department writing a CAD program using the engineering method: identify problems, solve problems, repeat. This program (meant to generate instructions to rewire circuits between design iterations) was thousands of lines long and worked about 75% of the time. The engineers had to go through the output and fix it by hand. The software people would say that each mistake was because there was a new wiring topology that the program hadn't seen before and then add code to do that particular change correctly. The program was like kudzu.
So, I sat down one lunchtime and wrote a simple, elegant program (in REXX!) that would do all wiring changes correctly. How? I thought about how all of the engineers did it in our own heads, when fixing the mistakes this program generated. It worked. The other program was scrapped.
When I left that job, two of my co-workers took over the program. They sat down and tried to decipher the program, where I used variables like "n" and "i", just like in BASIC class in high-school. They quizzed me as to meaning ("so, when n is 1, it means the pen is up?") and, quite frankly, I had absolutely no idea what it meant, it had come directly from my brain.
It was exactly like my college lit class dissecting a poem ("so, he's really talking about sex?") I always thought about my hacking as creative, not analytic. I guess professional programming is different.
Milo
Sort of like a skyscraper? Or a large jet airliner?
Skyscraper will not collapse if it was built a ton or two heavier than planned. Jet airliner can fly with half of its engines completely off.
In contrast, software has no redundancy. Throw a DLL out of project, and the rest of your code is useless.
Lisp is the Tengwar of programming languages.
I had a great professor who once said that writing code is more like writing an essay than like any other human activity. His point was that code ought to communicate to its reader exactly what it's doing. While I agreed with him on that point, I've always thought coding was more like writing poetry:
When you start doing either, you have a limited set of components to work with (words and grammar vs. commands, programming structures and such), and you put these together to form your work. A good programmer or poet tries to find the most appropriate of these components to use, and to arrange them optimally. Both require creativity, and the goal is (or at least should be) a work of elegance, beauty, and efficiency (the best poems don't waste a single word).
Love justice; desire mercy.
OO components are cool and all, but they are not necessary or sufficient to run a successful company writing software.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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.
IMHO, when comparing the two types of sciences people forget to continue with the analogy. Bridges tend to be fixed earth, lots of preanalysis work to build the foundation. In software development the ground keeps moving, you dig through one layer, and discover a whole different sediment layer.
Bridges have specific principles, gravity, tension, etc. Our correlation could be hardware and software environments. How much stuff is cross compatible 100% of the time? Everything has got to be tweaked a bit before it will work somewhere else.
To the best of my knowledge all bridges have been built on Earth. Let's see how well they would do on another planet. Same principles to start with, but a whole different factors to contend with. That's what its like in programming. We can write the if else, while loops, oop, sql whatever, but its not the same in different environments...
anywho... the caffeine rush is on... brain going way too fast now... can't hold thoughts...
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.