Forgot your password?
typodupeerror
Programming IT Technology

The Poetry Of Programming 416

Posted by michael
from the coding-in-iambic-pentameter dept.
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.""
This discussion has been archived. No new comments can be posted.

The Poetry Of Programming

Comments Filter:
  • by Anonymous Coward on Thursday December 05, 2002 @10:45AM (#4818088)
    Defy physics between two points. Software changes because what we do with it can change.
    • by Anonymous Coward on Thursday December 05, 2002 @10:56AM (#4818152)
      Bridges don't defy physics in anyway. Just because you are ignorant of the physics behind them doesn't mean it doesn't exist.
    • aesthetic beauty (Score:5, Insightful)

      by ryochiji (453715) on Thursday December 05, 2002 @02:58PM (#4820071) Homepage
      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?
  • by Hayzeus (596826) on Thursday December 05, 2002 @10:46AM (#4818093) Homepage
    Process swiftly crash NULL pointers everywhere O -- Electric Fence!
  • Yes (Score:4, Funny)

    by Anonymous Coward on Thursday December 05, 2002 @10:47AM (#4818102)
    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.
    • Re:Yes (Score:5, Funny)

      by owenb (91248) on Thursday December 05, 2002 @10:57AM (#4818157)

      ee cummings literary works (only I use more punctuation marks than she does)

      Ah, yes, the great emily ermintrude cummings. Her work was far superior to that upstart edward estlin, wasn't it?

    • Re:Yes (Score:3, Funny)

      by Reziac (43301)
      Stop writing your code in blood, and you'll not feel so drained afterward!

      And what's this ear doing on my desktop??

  • Get real (Score:2, Insightful)

    by PhysicsGenius (565228)
    Something new every time? Then how come when I browse Freshmeat I see 18,000 IRC clients and a further 5,000 "aim workalikes"?

    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.

    • 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.
      Amen brother. Although I would question the 200 years a bit. I recently documented a bug in an ERP system that violated a fundamental rule of double-entry bookkeeping. Those rules were codifed by the Medici's in the 1500s!

      sPh

    • Re:Get real (Score:2, Insightful)

      by redfiche (621966)
      I agree. We don't need to train code poets, we need to train software engineers. The problem with software development is not too much engineering, it's too little.
    • Re:Get real (Score:2, Insightful)

      by SpaceRook (630389)
      This is completely true. I've been reading Peopleware [amazon.com] these past couple days. Besides the fact that the authors flat-out say that there are very few new problems in software-engineering (this was in 1987!!!), the real difficulties are often due to bad management and work environment. If you're creating something new "almost every time", you are doing something terribly wrong.
    • Re:Get real (Score:3, Informative)

      by Malc (1751)
      Self-discipline seems to be a key factor between good and bad developers. Especially when it comes to languages like C++.

      I've met people who are amazingly creative and churn out very innovative code... yet are incapable of testing it and making it production quality. Then I've met overly anal people who snuff out creativity in all the people around them, producing code that is late and uninspiring. The best developers are somewhere in between.

      I've noticed that many of the best developers were once or still are musicians... perhaps musical discipline is good training for being a software engineer. I also read an article in the National Post recently that published the results of a reasonably sized study: students educated in the arts including music also achieved higher and better results in maths and science.
    • Re:Get real (Score:2, Insightful)

      by digerata (516939)
      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 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.

    • by occamboy (583175) on Thursday December 05, 2002 @11:36AM (#4818400)
      A huge problem with crappy software development is that it is not approached as engineering. Rather, projects usually start as kludges [tuxedo.org] ("Hey, look at the cool thing I did this morning"), and develop into large or huge kludges.

      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.

      • by DevilM (191311) <devilm@nOSPam.devilm.com> on Thursday December 05, 2002 @12:00PM (#4818571) Homepage
        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.
      • Not at all. (Score:5, Interesting)

        by pla (258480) on Thursday December 05, 2002 @02:09PM (#4819615) Journal
        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.
  • by Anonymous Coward on Thursday December 05, 2002 @10:54AM (#4818141)
    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?
    • by Bodrius (191265) on Thursday December 05, 2002 @11:03AM (#4818193) Homepage
      The approach to studying physics is also replicating well-known experiments with shoddy equipment, no experience, and predicted results.

      This is not to educate scientist to repeat the same experiments over and over again. It's just that you cannot be expected to understand complex physics and create new experiments for new theories if you haven't seen and tried the building blocks first-hand.

      They don't teach you to solve the Towers of Hanoi because it's a "common problem". They teach you to use recursion to solve problems, and to recognize a "recursion problem" by its characteristics, by using Towers of Hanoi as a common example.

  • by gUmbi (95629) on Thursday December 05, 2002 @10:55AM (#4818143)
    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.
  • ISO9000 (Score:5, Insightful)

    by e8johan (605347) on Thursday December 05, 2002 @10:55AM (#4818145) Homepage Journal

    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 quote myself: "The reuse of software requires direction, thought and documentation".

        Microsoft may have good documentation in some aspects (compared to open source alternatives), but they lack direction in many senses; it seems as if they are driven by a wish to add more functionality instead of improving upon the problems they have since before. The backwards compatibility is also an issue, for example Word2k is pretty much Word97, with more features, instead of better features. The changes to the UI is suprisingly small, concidering the new functions that have been added.

        Also in the area of thinking Microsoft seems to have problems. For example OLE, OLE2, ActiveX, or DAO and ADO. Repetetive reinvention of the same functionality with an interface change as the direct consequence. Also the structure of Windows and for example the filesystems used have a history dating back to the eighties and the 8086.

        If they'd think about what they do, create more flexible solutions from the start and stop caring for software developed in 1984 (run it in a virtual machine, VirtualPC on a 1GHz P3 has more power than the computers used back in '84) they'd probably make better software.

        Do not get me started on all the little extras they've introduced in a (from the beginning) clean UI. Just the list of apps in the Win2k Add/Remove Software dialog makes me sick. Yet another area is their business practices, etcetera etcetera ad infinitum...

        To sum things up: I do not think that Microsoft has good reuse of components, nor good object orientation.

    • Re:ISO9000 (Score:4, Insightful)

      by binaryDigit (557647) on Thursday December 05, 2002 @11:26AM (#4818346)
      I worked in a company that received ISO9000 certification, and I can tell you that it doesn't mean squat. If you define what you are doing in a vague enough fashion, and document the crap you ended up writing, hey guess what, your ISO9000 compliant. It did not improve the software one bit. It's a lot like taking a test, when the test becomes the goal (vs what the test is supposed to achieve, measuring someones knowledge of a subject), then people have a tendency to focus on this new goal (passing the test) and actions become geared towards that goal vs the original. So all of a sudden it's not "hey lets improve our process and maybe we can achieve ISO9000", it becomes "hey lets change our process to achieve ISO9000".

      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:ISO9000 (Score:3, Interesting)

      by p3d0 (42270)
      I disagree. I have yet to work at a company that uses real object-oriented components "properly" and yet all these companies are successful (though I'd rather not name names of course). One company was small enough that it produced only a single product, and a single developer knew the whole product inside and out. Anther was so large that they can throw manpower at the product to wrestle it into submission regardless of any lack of OO componentry.

      OO components are cool and all, but they are not necessary or sufficient to run a successful company writing software.

  • i wonder (Score:5, Funny)

    by forkboy (8644) on Thursday December 05, 2002 @10:55AM (#4818148) Homepage
    I bet this guy owns that "Code Poet" shirt from Think Geek.

  • Wrong (Score:5, Insightful)

    by Reality Master 101 (179095) <`RealityMaster101' `at' `gmail.com'> on Thursday December 05, 2002 @10:55AM (#4818149) Homepage Journal

    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:Wrong (Score:3, Funny)

      by Mr_Dyqik (156524)
      So it's like NASA's approach to building a satelite then? If you follow one of the more heavily documented programming techniques, maybe.
    • Re:Wrong (Score:5, Insightful)

      by sphealey (2855) on Thursday December 05, 2002 @11:05AM (#4818208)
      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.
      Sort of like a skyscraper? Or a large jet airliner?

      sPh

      • Apples and organges (Score:2, Interesting)

        by varjag (415848)
        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.
      • Re:Wrong (Score:5, Insightful)

        by joss (1346) on Thursday December 05, 2002 @12:19PM (#4818693) Homepage
        Fair comment, but if you mean to suggest that software could be designed like an airliner, consider this:

        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.
      • Re:Wrong (Score:3, Insightful)

        by leshert (40509)
        Software is not at all like a skyscraper or a large jet airliner. Punch a few holes in the wall of a skyscraper, or put a few bullet through the skin of an airliner, and they'll both still probably work safely.

        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:Wrong (Score:3, Informative)

      by RazzleFrog (537054)
      I am guessing that you are an engineer. Bridges are extremely complex. Every bridge presents a new challenge. Watch a special on the building of the Brooklyn Bridge or the Tacoma Narrows. Read about the challenges of the proper Strait of Messina (Sicily) and Gibraltar bridges.

      As for telling whether you can tell if a bridge is right or not, The Koror-Babeldaob Bridge stood for 20 years before collapsing.
    • Re:Wrong (Score:3, Insightful)

      by mblase (200735)
      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.

      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:Wrong (Score:3, Insightful)

      by Malc (1751)
      So you don't re-use the C library, or STL, or Java classes. etc? Over time we are creating more and more reusable parts that avoid custom-fabrication. I don't have to parse configuration files anymore as there is an abundance of good XML parsers that are far more flexible, reliable and robust than something I would custom build in a reasonable length of time. We haven't been making these libraries for long, but we're getting there.
    • Re:Wrong (Score:3, Interesting)

      by simong_oz (321118)
      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.
  • bridges =?= software (Score:5, Interesting)

    by mblase (200735) on Thursday December 05, 2002 @10:56AM (#4818154)
    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 [slashdot.org].

    "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.
  • The "only"? (Score:5, Informative)

    by sphealey (2855) on Thursday December 05, 2002 @10:57AM (#4818158)
    I would have to seriously question the statement that Mr. Gabriel is "possibly the only person with a Ph.D in Computer Science and an MFA in poetry". Many computer people I have met have a lifelong fascination with language and literature. Particularly the academic types who pursue Ph.D's. I would guess that there are a fair number of people out there with that combination of degrees.

    sPh

    • I agree with your sentiment, sphealey. There are indeed a lot of people who seamlessly combine the intense analytical nature of science with the flowing creativity of "the arts." I'm one of these "types"--I have degrees in both computer science and English, but my sanity will only permit me to pursue a doctorate in the former. =) Additionally, I once had a professor in my CS curriculum who holds doctorates from UPenn in both CS and English. Aside from the sheer boggling and incredulity that some proponents of either discipline regard, there's a strong undercurrent of resentment akin to the whole too-much-science/technology versus too-much-hand-waving-and-superfluous-literary-theo ry. I've had professors call me out for simply being interested in either (which is by far the most ridiculous load of crock). Who cares? After all, simply pursuing an "advanced degree" requires a strictness and diligence that hints at a passion most people blithely overlook.

      I'm reminded of the greats: Feynman, etc. I would add a chemistry professor I had named Holden Thorpe, quite possibly the most brilliant chemist and pianist I've ever met. It's far too small a world to say anything conclusive about being "the only one."
    • Re:The "only"? (Score:3, Insightful)

      by ryochiji (453715)
      >Many computer people I have met have a lifelong fascination with language and literature

      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.

  • by tmark (230091) on Thursday December 05, 2002 @10:58AM (#4818166)
    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 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.

      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.

    • by Anonymous Custard (587661) on Thursday December 05, 2002 @11:39AM (#4818415) Homepage Journal
      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.
    • 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 ?

      I find whenever I am coding that it is a profoundly creative process, and while it may not always be poetry, it often is very akin to writing prose (as I have done [expressivefreedom.org]). Indeed, in at least one case code is literally poetry, in an inspired implimentation of DeCSS as haiku:


      How to decrypt a

      DVD: in haiku form.

      (Thanks, Prof. D. S. T.)


      see http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/wsj-04- 12-2001.html [cmu.edu] for the rest ... slashdot's asinine lameness filter won't let me include it here. It concludes...


      Have mercy on me,

      Lord, and lesser judges, and

      on Jon Johansen.


      You are correct in part: coding also has very substantive aspects of engineering to it. You are incorrect to differentiate it all too greatly from architecture IMHO. Coding is actually very, very similiar to architecture: a blending of art and engineering in the creation of an edifice that is expected to be both beautiful and functional.

      You are wrong to assert some sort of "universal" agreement on what is and is not good code. My experience (admittedly only 15 years or so) is that there are many disagreements amongst professionals on these very points. Indeed, just like architects and artists of one school or another do tend to agree on what is "good" and what is "not", so to with programmers, and so too are there different schools which disagree with one another's aesthetics and argue vehemently amongst themselves as to what does, and does not, constitute good code.
  • I have both a Ph.D. in computer science and an MFA in poetry.
  • by sporty (27564)
    Did he just compare Windows to FreeBSD to Linux?

    I never could understand art :)
  • by vadim_t (324782) on Thursday December 05, 2002 @11:00AM (#4818177) Homepage
    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.
  • by Chillblaine (586808) on Thursday December 05, 2002 @11:00AM (#4818178)
    'Well, how come we can't build software the way we build bridges?'

    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!

  • by Junks Jerzey (54586) on Thursday December 05, 2002 @11:05AM (#4818201)
    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.
  • So many posts later, and nobody has mentioned it, yet.

    Much software is built like the Tacoma Narrows bridge.

    Or, what I once heard about building bridges... Anyone can build a bridge that won't fall down. It takes an engineer to build a bridge that just barely won't fall down. Really a comment on making efficient use of materials.
  • I agree (Score:3, Insightful)

    by joss (1346) on Thursday December 05, 2002 @11:08AM (#4818221) Homepage
    Amazing that this can be treated as an innovative thought. It should be common sense. Naturally, there are forms of programming that are much more about engineering than creativity, where the bridge analogy works, but the fun and more worthwhile ones arent. Whenever someone says something like this, a lot of replies here run along the lines of "nonsense, hardly anybody writes anything innovative". All I can say to that is: "just because you're a brainless troll with a boring job, doesn't mean everybody is - it must suck to be you".

    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/inde x.html
  • by teamhasnoi (554944) <{moc.oohay} {ta} {ionsahmaet}> on Thursday December 05, 2002 @11:10AM (#4818230) Homepage Journal
    If software was like bridges, we'd be increasing the number of lanes to drive on by 75%, while going 25% as fast in cars that have a top speed that doubles every six months.

    Zen moment: If software is like bridges, what is Hoyles Bridge software like?

  • "You don't look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don't look at their design."

    this is a fundamental flaw with today's practice of software engineering. developers reinvent the wheel way too much - we are starting to reuse low-level abstractions routinely (i.e. java.util) and design patterns do help. but if we want to REALLY start developing increasingly complex systems we need to leverage more complex code that works. i guess general-purpose processors still aren't quick enough to nullify any performance degradation a high-level abstraction may cause, but we'll get there (or the state of the art won't really progress).
  • My degrees were actually in music, not programming. When I got into the professional programming world I found that many of the programmers (not all) whose work I respected the most also had some sort of arts background.

    I question though whether it is possible to teach this sort of creativity alongside computer skills in any meaningful way within the confines of a two-year master's program.
    • I'm willing to bet it is possible. I know a fair number of CS graduate students who delve pretty deeply into literary theory, Classics, etc. Of course we're not speaking of unmotivated folks by any means; one can't well be taught creativity--IMO that's something you yourself recognize and cultivate.
  • It's not strictly true that we can only incrementally improve bridges. Consider that steel was first used in a suspension bridge in the late 1800s. Before this, suspension bridges were fairly limited in span length, due to the strength of the materials. Then the Brooklyn Bridge was built (the paradigm) and in fewer than 50 years, the Golden Gate Bridge (and many others). So in only a few decades, the limits of bridge design were expanded by at least an order of magnitude. (That's not much in CPU terms, but in the world of big things like bridges, it's pretty impressive.)

    Anyone wanting a good read on the subject of bridges, I suggest "The Great Bridge" by McCullough, the story of the building of the Brooklyn Bridge. Most of it's about Washington Roebling (who took over when his father, John Roebling, the original designer of the bridge, died, before the bridge was actually started). It's a truly inspirational story for anyone that calls themselves an engineer.
  • by nadador (3747) on Thursday December 05, 2002 @11:15AM (#4818267)
    If Mr. Gabriel had a degree in Civil Engineering, I think his view would be very different. (Sidebar: mechanical engineers makes bombs, civil engineers make targets. But that's neither here nor there.) Building bridges is not a simple matter, and just because *you* don't understand it, you can't minimize the task.

    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.
  • Gabriel states that writing software should be treated as a creative activity, and gives us an analogy between a software developer and an artist. This is an interesting theory, but as a musician, I'd have to say that true musical genius and innovation belongs to a small set of individuals. The rest of us can enjoy making music, but when you come down to it, for every Monet and Mozart, there are thousands of painters and musicians, making a living by crafting paint and sound - coloursmiths and tunesmiths, if you will.

    The same is true of writing code - there are a lot of plodders out there, and few innovators. I'm sure that most of you would put yourself in the latter category, but let's be honest - how many of you have ever had a showing of your code at the Museum of Modern Art?

    The other thing problem I had with the article was that Gabriel claims that bridge designers "don't have to reinvent the wheel", while code developers are "creating something new" almost every time. What does that say about code re-use? I'd feel a hell of a lot better driving across a bridge that looks like a bridge, rather than one that has a funky, Escher-esque design quality (never mind that it would probably be a Moebius bridge). Developers don't need to excercise creativity ALL the time - even the best ones.

    On the whole, though, I do agree that one should code creatively. Which is just a fancy way of saying "think outside the box".
  • by Hasie (316698) on Thursday December 05, 2002 @11:16AM (#4818275)
    "We've only been building software for 50 years, and almost every time we're creating something new."


    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...

    • I'd agree. I'm in a Computer Science and Engineering program, and I think you'd be amused watching me build a circuit the way I'd write a program. Lay out a framework, make submodule stubs, implement them one by one, debug them individually before making them work together....

      Works fine for software, really, *really* sucks for hardware.
    • > And we've only been building transistors for 50 years and chips for 30? years

      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.
  • by fhwang (90412) on Thursday December 05, 2002 @11:17AM (#4818279) Homepage
    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.)

    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 ... 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.
  • Lack of constraints (Score:3, Interesting)

    by Hayzeus (596826) on Thursday December 05, 2002 @11:17AM (#4818280) Homepage
    The fundamental problem with software development is NOT that we're just new to it. The real problem is that the process itself imposes relatively few constraints on the developer. Put another way, there may be hundreds or even thousands of ways to solve a particular problem in software -- not all of them good, obviously, but workable nevertheless. Bridge-building (basically a metaphor for traditional engineering), on the other hand is constrained by basic laws of physics; there are a relatively few ways to build a bridge that will support a reasonable amount of weight.

    This lack of constraints peculiar to software development implies a couple of things:

    • Without the confining limits of real-world physics, software development tends toward increasing complexity since there is less to hold back the addition of new functionality over time (or even in the initial design). This is especially true for commercial software, where nifty features are a firm's bread-and-butter.
    • The lack of constraints makes it practically difficult to apply the traditional discipline associated with other branches of engineering. In a commercial environment especially, economic pressures tend to favor features and deadlines over stability. This is probably also true to some extent for personal or Open Source development.
    • Reuse of components can help -- the problem is that a component that doesn't behave EXACTLY the way a given developer wants it to is often discarded in favor of custom code. No electrical engineer would design their own timer circuit when a simple 555 might be adequate. But this kind of thing happens in software development all the time because it's relatively easy to do.

    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.

  • by lutzomania (139132) on Thursday December 05, 2002 @11:24AM (#4818327)
    I only have a minimal knowledge of coding, but I do know a bit about writing, and this guy's poetry (or at least the excerpt in the interview) is pretty bad. The rhythm is bad, there's no interesting, imagery, etc. But that's just my opinion (he said, knowing he was about to be flamed...).

    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.
    • by Todd Knarr (15451) on Thursday December 05, 2002 @11:37AM (#4818402) Homepage

      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.

  • Perl poetry [arminco.com]
  • by Thai-Pan (414112)
    Dev-C++ 5
    What does "no mo mo mo" mean?
    Screwed up errors suck.

    Dev-C++ 5
    What's wrong with the debugger?
    Who wrote this crap-pile?
  • Hacker/Poet (Score:3, Interesting)

    by milo_Gwalthny (203233) on Thursday December 05, 2002 @11:41AM (#4818432)
    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.
  • Or maybe Rapid Bridge Development (RBD) then i wouldnt drive over it, speed is our problem not the knowledge....
    Lets slow down and do it right in first place. If you make a very big mistake in a birdge and it collapses you will be held responsible now with software noone is responsible since the licence reads so.

    Think about it, when your car explodes due a mistake in the car design you can sue the car company, sertainly if they knew they sold a flawed unit, if they would rush car designs like they do software designs they would know that it would hold some flaws...

    Maybe not just the designs some designs are good i guess, but then the implementation stinks...in the end.

    Fix it Fix it Fix it! :)
    Wake up and smell the coffee...
  • I hope this doesn't sound like a flame, but Richard mentions:

    But the Java language is pretty successful, and folks write lots of apps in it.

    Can anyone point out uses of Java in popular mainstream products (that is - something the average /. reader would recognize).

    Mozilla, Windows, KDE, Gnome, X11, MS Office etc, etc. Aren't these all C/C++?

    The few Java apps I've tried, usually seem to be by amateur programmers and run rather slowly. Or am I missing the point and Java isn't really supposed to "compete" with C.... ?
  • by tony_gardner (533494) on Thursday December 05, 2002 @11:53AM (#4818520) Homepage
    One of the major strategies to get any complex project to work is to use off the shelf parts. For physical engineering, those parts are defined by standards, and their properties are well known _and_documented_. For instance if I want an M10*1.5 socket head cap screw of strength rating 8.8, the properties of that piece are very well documented.

    The problem with software engineering is roughly the same as if you made a bridge with every bolt individually hand made. It's a quality control problem.

    Physical engineering generally does the same thing as code building, use standard parts to build a variation on a theme. Creativity in the selection of standard parts will end up in an end product of unknown quality.

    It's not that creativity doesn't play a role, more that it shouldn't play as much of a role if quality product is to be made.
  • The constant comparison of software development to real world engineering is ridiculous. There is one very serious difference between the two concepts. Once a physical construct is created, it cannot be easily undone or changed. Software is infinitely malleable.

    This difference, though seemingly small, makes a huge difference when it comes to designing of a system. If software was going to be designed to do one specific thing, and never change, it would be much simpler to develop bug free software quickly. But that is never the case. Invariably things are constantly being redefined as the software is developed and even after it's "done", there are several iterations of improvements and changes.

    A bridge, but contrast, is designed, and then it is built, and when it's done, that's it until it starts falling apart, and then the same process happens again. The iterations are over periods of decades, centuies, or millenia, depending on how well you build the bridge in the first place.
  • Code Poetry (Score:3, Interesting)

    by strider( corinth ) (246023) on Thursday December 05, 2002 @12:11PM (#4818643) Homepage
    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).
  • wallpaper zen (Score:4, Interesting)

    by tamarik (1163) on Thursday December 05, 2002 @12:27PM (#4818799) Homepage
    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.
  • by jolshefsky (560014) on Thursday December 05, 2002 @12:31PM (#4818856) Homepage
    I thought the most important concept in the article was that of the artistic critique. From the beginning of an artists education, they are taught the methods of critique. The situation is relatively simple--put your work in front of a body of people and have them make critical comments about it. The presenter of the work leaves it to stand on its own and tries to remove their own personal involvement from it: attacking a work is not attacking the creator.

    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.

  • by Crash McBang (551190) on Thursday December 05, 2002 @01:09PM (#4819193)
    He came to me and said, It's gotta be narrow enough for a bicycle, but wide enough for a hummvee, It's gotta be recyclable and not harm a tree, It's gotta be password protected, Internet enabled, smaller than a table, and reuse is expected! UML and Visio for the design, we gotta have a prototype by next week, don't whine! Nobody can get hurt using this bridge, no time for testing, just do a smidge! We gotta release it soon, or the customer will swoon! Thank goodness that's done, now lets build another one! The next customer's needs are unique, let's use the same code and build it next week! So my Boss wanted me to build a bridge...
  • by Animats (122034) on Thursday December 05, 2002 @01:11PM (#4819217) Homepage
    If it really had to work, operating systems would be small microkernels that almost never change, like QNX, built into ROM. CPUs would have the fault-detection and redundancy of mainframe IBM CPUs. Fancy features would have an arm's length relationship with the important stuff, as with SQL databases. Crucial software components would have machine-checked proofs of correctness. Everything would be written in safe languages, like Ada or Modula for low-level stuff and Java for high-level stuff.

    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.

  • by John Hasler (414242) on Thursday December 05, 2002 @03:14PM (#4820249) Homepage
    > People say, 'Well, how come we can't build
    > 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.

Some programming languages manage to absorb change, but withstand progress. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982

Working...