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.""
The "only"? (Score:5, Informative)
sPh
Re:I'm curious about wheel reinvention (Score:5, Informative)
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.
Re:Wrong (Score:3, Informative)
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:Get real (Score:3, Informative)
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.
Bridges and Incremental improvement (Score:2, Informative)
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.
Gimme Perl poetry any time! (Score:2, Informative)
Re:Try building a bridge... (Score:4, Informative)
Some Observations (Score:2, Informative)
The thing is, they screw up their designs just as often as I do, they build things that don't work well the first time just as often as I do, and they release stuff that doesnt do what the customer wants just as often as I do. And the outside companies we work with are worse.
It's a complete falacy that more mature engineering disciplines are able to some how make things that work all the time, right up front. I heard this in school long ago, and with out any experience I took it as true. After just a few years of working with hardware engineers, I found it was complete crap.
The crux of the issue is this. Building hardware is complicated. Building software is complicated. Building anything with a couple of hundred thousands parts in it is very hard. To do it right takes talented and motivated people, lots of time, and lots of money. Things need to be well organized, well planned, and well executed.
I've seen a few people on this story post that many traditionally engineered things that people hold up as being examples of how to do it right, such as bridges, are much simpler than software. That is very true. Most circuts that our EE's build here, lets say they had 50000 things in them. thats quite a lot. but look at the things. the things that make up a circut are all very simple. one input, one output, performs a very simple operation. Its actually alot less complicated that a big piece of software. Write a program with 50000 addition, subtraction, and boolean logic statements in it, and you'll find youve got a very simple program. Take a look at an assembly dump for a simple hello world program, and your find that many thigns.
Invariably, when someone says that engineering works with less complicated things than software, someone always trots out a 747 or a space shuttle by way of a counter example. Its true, these things are well engineered, work right, and are insanely complicated.
They also took many (10-12?) years to go from idea to working tool, and took billions of dollars to make. Find me a software consumer willing to sit around for more than a year, and I'll be excited. Find me someone that doesnt think 600K for piece of software is insanly expensive and I'll be just as excited. The space shuttle software is often taken as an example of what could be done with good software enginnering, but they dont realize that the documentation budget for the space shuttle software is larger than many software companies entire revenue stream. The space shuttle's software teams customers are people that understand that if the software isnt done right, people and billions of dollars worth of stuff will be destroyed. You know what that means, they have the staff, budget, and time to do things right.
You cant compare things like the space shuttle to a 6mo project to make data entry program. Dont even bother. And dont think that the problems you have in a 6mo data entry project can in any way be solved by tools designed and proven to work on the space shuttle.
People have come to expect good software very quickly and for cheap. That comes with some problems, and its very hard to combat those problems. The programmers are often very poorly trained, the budget is tight, and the software is a moving target. I have yet to see a program I started to work on not change substantiatly from the time I started till the end. Spending 2 mo at the beginning designing things to the level of a 747 is stupid, because by the time the item gets out the door, it will have changed from a plane to a boat. that 2 mo was wasted.
Why is Peter Galbraith famous? (Score:2, Informative)
Strangely, IMHO, missed by the slashdot editors (on second thoughts, perhaps I am not so surprised) and the article itself was the paper for which Peter Galbraith is famous. The paper is Lisp: Good News, Bad News, How to Win Big [mit.edu], which includes the section "The Rise of Worse is Better" which he wrote while at Lucid.
Peter Galbraith was respected and quoted by JWZ (or lucid/xemacs and Netscape fame).
It was the ideas in Worse is Better that ESR rehashed and become the Cathederal and the Bazaar.
i.e. Linux was developed using the "New Jersey" approach and GNU was developed using the MIT approach: The folowing passage illustrates this:
i.e. Linus used the "Worse is Better" method and RMS (ahem...
I encourage you to read the whole of Good News, Bad News - it contains insightful material on things other than Lisp (I should declare an interest in that I am a scheme programmer).